Many of us remember the 1999 loss of the Mars Climate Orbiter—a $326 million total cost with a lot of scientific promise. The culprit turned out to be an assumption of what units were used on a parameter exchanged between the orbiter and mission control during the orbiter’s entry into Mars’ orbit. The orbiter’s software used SI units of newton-seconds (N·s) while the ground-based computer software used non-SI units of pound-force seconds (lbf·s). In case you’re wondering—yes, the related requirements were properly documented in the specifications document.
Fig 1. – Artist's conception of the Mars Climate Orbiter
Today we design much more complex system-of-systems and many of them are intended for everyday use, where an error in a critical parameter will cost lives. Self-driving and connected cars are one example. Tele-medicine is another. To manage that complexity, we increasingly rely on the practical applications of Systems Thinking principals—a holistic view of the entire system’s functionality, architecture and behavior. This includes embracing new technologies like SysML languages for system modeling or Digital Thread for pervasive traceability. It also includes evolving existing technologies, like simulation at every stage of the design, or fundamentally rethinking the approach to the data, process, and lifecycle management platforms like PLM. All of this requires traceability of not only data model elements but also of the associated parameters. But there is a fundamental issue that prevents an effective exchange and traceability of the parameters: text-based requirements in a document!
A requirement expressed with a natural language can’t authoritatively and uniformly communicate all aspects of an associated parameter such as type, resolution, tolerance, range, units to name a few. That means that every time a text-based requirement is being referenced—during simulation, detailed design or testing—there is an inherent danger of a disastrous human error when communicating between tools and teams. In fact, it can be argued that the root cause of the Mars Climate Orbiter failure was the lack of machine-readable definition of the parameter and not the human misinterpretation of the units.
This is something that a lot of organizations are trying to figure out, often in very innovative ways. A good example is this Thales’ INCOSE IS2019 paper titled “Augmenting Requirements with Models." The paper argues that system model elements should be used as de facto requirements. Thales makes a very compelling argument how this approach streamlines testing of design implementations and eliminates any chance of human error in interpretation of the requirements. I recently had a similar conversation with Michael Vinarcik from SAIC, University of Detroit Mercy, about how he guides his students to focus more on system model functional and logical elements as superior to text-based requirements. These trends are very good news because they indicate that the industry is trying to shift away from text-based requirements (wherever it makes sense) and move towards a more computer readable form of it—and that includes modeling of the parameters associated with the requirements.
There are many examples of how computer readable requirements with parameters can help to speed and scale design activities. Embedded software transitioning from a software-in-the-loop (SIL) testing to the hardware-in-the-loop (HIL) testing benefits from using the same system model definitions. Simulation granularity where the increasingly detailed design representations (and therefore simulation models) allow for the reuse of the same simulation studies with the same requirement parameters. This applies to every design representation along lifecycle: from design space exploration to the interpretation of IoT feedback from assets in the field. Considering the exploding complexities of today’s and tomorrow’s systems, just think of how this would result in increasing engineering efficiency and the scalability of the underlying processes.
Naturally, there is a whole class of requirements that will continue to be expressed in a natural language and not all requirements will have a corresponding element in a system model. But that does not mean that the requirements must be structured as paragraphs in a document. While that paradigm of a document is very important to preserve as one way of viewing requirements, this does not mean that text is the only appropriate underlying data model. Requirements data models must shift away from a natural language structure. This is key to expressing complex parameters as part of a requirement.
Do you agree? Disagree? Please share your thoughts.
Meanwhile I invite you to listen to an Aras point of view on this subject, using a real-life use case implemented on the Aras' enterprise low code platform. It shows, among other things, how requirement parameters can be modeled using today’s technologies and how these parameters can be automatically communicated between different tools and design representations using a custom definition of a Digital Thread.
Now, on a personal and lighter side of things, it is amazing how long unit issues linger for an immigrant, like me. You should see how my children still roll their eyes every time I say something like: “Oh look, its 32 on the thermometer so it must be 0 outside.”
For more information on Systems Thinking, visit our website.