Posts Tagged INCOSE
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.
- Fashionable Pessimism: Confidence Gap Revisited
- Despising Derrida, Postmodern Scapegoat
- Smart Folk Often Full of Crap, Study Finds
- Risk Neutrality and Corporate Risk Frameworks
- The Dose Makes the Poison
- The Prosecutor’s Fallacy Illustrated
- Innumeracy and Overconfidence in Medical Training
- 55 Saves Lives
- The Covid Megatilt
- Intertemporal Choice, Delayed Gratification and Empty Marshmallow Promises
- The Naming and Numbering of Parts
- The Trouble with Doomsday
- The Trouble with Probability
- Actively Disengaged?
- A short introduction to small data
- Countable Infinity – Math or Metaphysics?
- Paul Feyerabend, The Worst Enemy of Science
- Use and Abuse of Failure Mode & Effects Analysis in Business
- Alternative Energy News Oct 2019
- What is a climate denier?
- Yes, Greta, let’s listen to the scientists
- Daniel Kahneman’s Bias Bias
- Let’s just fix the trolley
- Physics for Environmentalists
- Physics for Venture Capitalists
- A Bayesian folly of J Richard Gott
- Physics for Frisco motorheads
- Representative Omar’s arithmetic
- Which Is To Be Master? – Humpty Dumpty’s Research Agenda
- adverse selection aerospace big data clean energy climate change crowdsourcing crowd wisdom data visualization Decision analysis Design Thinking engineering History of Science holism ideation innovation interdisciplinary Management Science multidisciplinary Philosophy Philosophy of Science physics pluralism postmodernism probability and statistics reductionism Risk management science semantic analysis Six Sigma social influence Statistical Process Control statistical stylometry Strategic Initiatives system System Dynamics System Safety Systems Engineering Systems Thinking Thomas Kuhn TQMS
- My other blog: Rome101.com
Error: Twitter did not respond. Please wait a few minutes and refresh this page.