When I mostly dislodged myself from aerospace a while back and became mostly embedded in Silicon Valley, I was surprised by the undisciplined use of the term “Systems Engineer.”
To me, Systems Engineering was a fairly concise term for an interdisciplinary approach to design and construct successful systems. Systems Engineering – as seen by INCOSE, the International Council on Systems Engineering – involves translating customer needs into requirements, then proceeding with design synthesis. This process integrates many disciplines and specialty groups into a team effort to transform concept into design, production and operation. Systems Engineering accommodates business, technical and regulatory needs and requirements toward the goal of providing a quality product that makes investors, customers, regulators and insurers happy. It’s a methodical, top-down, big-picture approach.
In Silicon Valley, “systems engineering” is usually short for “embedded–systems engineering,” i.e., the engineering of embedded systems. An embedded system is usually a computer system that performs specific control functions, often within a larger system – like those designed by systems engineers as described above. Embedded systems get their name by being completely contained within a physical (hardware) device. Embedded systems typically contain microcontrollers or digital signal processors for a particular task within the device. A common form of embedded system is the firmware that provides the logic for your smart phone.
There is often overlap. Aircraft, hospitals and irrigation management networks are all proper systems. And they contain many devices with embedded systems. Systems engineers need to have a cursory knowledge of what embedded-systems engineers do, and often detailed knowledge of the requirements for embedded systems. It’s a rare Systems Engineer who also does well at detailed design of embedded systems (Ron Bax at Crane Hydro-Aire take a bow). And vice versa. Designers of embedded systems usually only deal with a subset of the fundamentals of systems engineering – business problem statement, formulation of alternatives (trade studies), system modeling, integration, prototyping, performance assessment, reevaluation and iteration on these steps.
Because there are a lot more embedded-systems engineers than systems engineers in Silicon Valley, its residents are happy with dropping the “embedded” part, probably not realizing that doing so would make it hard for a systems engineer to find consulting work. Or perhaps “embedded” seems superfluous if you don’t know about the discipline of systems engineering at all. This is a shame, since a lot of firms who make things with embedded systems could use a bit – perhaps quite a bit – of systems engineering perspective.
This is an appeal for more discipline in the semantics of engineering (call me a pedantic windbag – my wife does) and for awareness of the discipline of Systems Engineering. Systems Engineering is a thing and the world could use more of it. Silicon Valley firms would benefit from the methodical, big-picture perspective of Systems Engineering by better transforming concept to design and design to product. Their investors would like it too.
In my work as a software engineer – not of the embedded sort – I’ve spent some time with various aspects of semantics and linguistics – forensic linguistics being the most fun. “Embedded” in linguistics refers to a phrase contained in a phrase of the same type. This makes for very difficult machine – and often human – parsing. Humans have little trouble with single embedding but struggle with double embedding. Triple embedding, though it appeared in ancient writing, sends modern humans running for the reboot switch. The ancient Romans were far more adept at parsing such sentences than we are today, though their language was more suited to it.
The child the dog bit got rabies shots. The child the dog the man shot bit got rabies shots. The child the dog the man the owner sued shot bit got rabies shots.
My wife is probably right.