The Art of Simplifying Without Dumbing It Down
The functional complexity and pervasive connectivity of today’s products is forcing OEMs to rethink their approach to design methodologies. One of the resulting changes involves embracing systems engineering as key to managing system interdependencies and minimizing design risks. That in turn leads to adapting various model-based system engineering (MBSE) methodologies and tools to define system models. Sounds good so far, but there is a problem: the complexity of the resulting system models.
Consider the famous letter, “Go to Statement Considered Harmful” sent by Edsger W. Dijkstra to the Association for Computing Machinery (ACM) back in the 1968. There is a nice discussion of it here and it is an absolute treat to read. Here is the central concept: “[…] we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.” Dijkstra’s argument was that programmers must worry about making their code understandable by others. The rest is history.
Let me editorialize a bit (changes in bold): “We should do (as wise systems engineers aware of our limitations) our utmost to shorten the conceptual gap between the static SysML diagrams and the subsequent detailed product design processes, to make the correspondence between the diagrams (spread out in 2D space) and the desired product behavior (spread out in time and across a multiplicity of domain-specific implementations) as trivial as possible.” With these small changes, Dijkstra’s observations can be directly applied to the problematic misuse of system modeling languages.
When the use of a system modeling language (e.g., SysML and its diagrams) does not consider how the model will be used by others, it results in unnecessarily complex system models. The intent of the system model is lost in the resulting 2D diagrams. This decreases the effectiveness of collaboration across various engineering domains since these diagrams are the primary means of communicating the system model to non-systems engineers. As a result, the primary goals of MBSE are defeated: to better manage system complexities and minimize risks by enabling cross-discipline collaboration across engineering domains.
System models, like any model, are an imprecise view of a target. Trying to make the model less complex by dumbing it down is not a good solution because it makes the model that much less precise. And that in turn diminishes its usefulness. The solution is in capturing the essence of the complexity in a way that makes communicating its meaning to the rest of the organization as simple—or trivial using Dijkstra’s terminology—as possible. That can’t happen automatically. It must be the result of a deliberate modeling methodology driven by the needs of the target audience: detail design (mechanical, electronic, electrical, software), testing, quality, documentation, manufacturing, maintenance, repair, etc. I had a recent opportunity to discuss this very point with Enrique Krajmalnik, CEO of Vitech, and we were in total agreement on its importance. Ultimately, most system models tend to be unnecessarily complex because the authors fail to consider audiences besides themselves.
Today efforts to share the meaning of a system model with others (e.g., non- systems engineers) center around the traceability that exists between model elements and elements of other design abstractions and domains—a digital thread. The assumption is that traceability enables understanding. Unfortunately, that is not the case. Traceability with too many links to too many things, and without well-defined semantics for the elements of those links, is similar to the random navigation of web content using hyperlinks. After the fifth click one begins to get confused about the starting point. In addition, traceability without context (e.g., a specific set of requirements, design projects, approved variants, relevant simulation studies, etc.), and without configuration management (lifecycles, revisions, and ECOs) further diminishes the value of this type of unbounded traceability.
Aras has participated in numerous PLM platform deployments of Aras Innovator to address this problem. Aras Innovator is a low-code, end-to-end PLM platform capable of incorporating emerging design abstractions like MBSE system models in context. These deployments succeeded by focusing on how system models should be authored so that others can better understand them, as well as the degree of granularity the model must expose to the rest of the organization to enable cross-domain collaboration. The key was reducing the complexity of the relationships (traceability) without dumbing down the model itself. Note that this also involves uniformity of modeling methodologies.
A good example is Toyota Motor Europe (TME). TME knew exactly what their 150% architecture model is (the mechanical car platform) but had an issue with capturing and managing the accuracy of the related and evolving engineering representations in the context of that model. These additional engineering representations included variants and their simulations. Traceability and revision control was also a real challenge since Excel was the legacy tool used for capturing this data. Working with Aras, TME realized the issue was not the way the architectural model was created, but the way it was siloed. Using the incremental Agile methodology, TME was able to determine the optimum data granularity and traceability across the entire data set. A rapid implementation of this solution was possible because of the modeling flexibility of the Aras low-code platform and the hands-on collaboration between Aras and TME experts. The Excel spreadsheets have been replaced by a single digital thread in Aras Innovator where semantically rich MBSE<>variant<>design<>simulation relationships (the key aspect of the solution) are managed, regardless of where the system and design details are developed. The engineering community can now focus on creation, review, and editing the data. No more wasting time on data management details and worrying about loss of knowledge gained. With clear evidence of the benefits, the engineers more readily warm up to PLM – quite a deviation from past behavior!
The next phase is to start moving these solutions to Aras Enterprise SaaS since it is 100% compatible with the functionality of the server-based Aras platform. This is in step with the increasing adaptation of PLM platforms in the cloud.
MBSE system model complexity does not need to be dumbed down for the rest of the engineering organization to benefit from it. It just needs to be simplified in the context of the cross-domain collaboration by avoiding unnecessary complexity—just like the complexity caused by the GOTO statement mentioned above. The key is to think it through in advance, taking into consideration all possible consumers of that model, including suppliers.
To end on a lighter note here is a great example of how to explain highly complex scientific concepts with one thousand most commonly used words in the English language (e.g., without systems engineering buzzwords). Note that the narrator says “ten hundred words” instead of “one thousand words” at the beginning of the video. That’s because “thousand” is not one of the most commonly used English words. The opportunities to miscommunicate when over-simplifying abound! Enjoy the video.
Visit us on the web to find out more about Aras Innovator’s low-code platform and Aras Enterprise SaaS.