Is SysML Right for SE?

11-20-20Mark Simons

by Mark Simons

It is fair to say that System Modeling Language (SysML) has had, at best, uneven success in system development. SysML has undergone three updates since first becoming an Object Management Group (OMG) standard in 2007 and is being prepared for its first major revision in 2021. Will the OMG get it right this time, or will SysML fail again as a reliable tool for systems engineering?

From the beginning, the goal of SysML was to use the Unified Modeling Language (UML) to create a graphical language for systems engineering. OMG updated the UML metamodel for SysML and the result was a very verbose language, familiar to software engineers but too often rejected by other engineering disciplines, and completely incomprehensible to the average system stakeholder. While the software engineering community has, in part, moved on from UML towards more Agile methods for software development, the essentials of UML live on in SysML.

Complicating matters even more are wide variations in “modeling” implementation that negate the SysML promise of interoperability and consistent communication. Variations in modeling style, philosophy, and even expertise, combine to offset any benefit of a standardized notation. So, despite being standardized, an organization using SysML cannot guarantee consistency of systems engineering practice, and still struggles for credibility within a community of stakeholders and engineering disciplines.

What is the root cause for this disparity? All things being equal, shouldn’t systems engineers arrive at the same destination? Is SysML helping or hurting the discipline of systems engineering?  Has it morphed into mere diagram-based engineering? Will SysML v2 be easier on the eyes so as not to overwhelm an audience? Will the language be simplified to be more comprehensible to system stakeholders? SysML is trying to meet many competing objectives: consistency with other OMG standards like Business Process Modeling Notation (BPMN) and Common Object Request Broker Architecture (CORBA), support for software engineering, details of MBSE tool design, and even a quest to evolve SysML from a semi-formal language to a complete formal language. It appears that systems engineering may be getting lost in the shuffle. Without experienced systems engineering providing thought leadership, will these SysML modeling tools just become data repositories? Can MBSE tools even be called SE tools, if their primary purpose devolves to simple modeling over systems engineering?

While I’ve seen some very homogeneous organizations of software engineers with a small set of system stakeholders get by with SysML, I’ve also seen organizations with more diversity of thought, backgrounds, and engineering disciplines waste an excess of time and money devoting energy to applying SysML. If SysML v2 cannot succeed in facilitating communication, creating consistency of practice, and tackling complexity, we may be better served with traditional approaches and tools that have stood the test of time. In a world becoming increasingly more complex, do we need tools that replicate that complexity, or tools that help us make the complexity more comprehensible? How do we quantify return on investment with SysML? What is the true cost of using a UML-based tool with an immature standard that is failing organizations?

With SysML v2, OMG must deliver true value to the systems engineering community. SysML must provide more latitude to tool vendors to be more innovative, enabling them to provide modernized user interfaces for users. An option for vendors to offer a more simplified version of the language would help communicate important concepts to a broad range of stakeholders, especially early in the systems lifecycle during concept development. Providing a means for modelers to work in the definition space without the need to model usage would help groups where reuse is not a major concern. Fundamentally though, OMG needs to streamline and extend the SysML metamodel to be more semantically precise. The SysML Block should be aligned to physical elements of a system design. The Block Definition Diagram should only show Blocks and not other stereotypes. Add an Activity Definition Diagram and similar diagrams for other stereotypes. Relationships should serve specific purposes and have semantic meaning. Essentially, the language needs to facilitate communication among a broad range of stakeholders rather than within a very narrow set of experts.

At Arena Technologies we understand the appropriate uses of SysML as well as its risks. Thinking outside the box, we emphasize using sound systems engineering practice to guide MBSE efforts for our customers when MBSE makes sense. We ensure that systems engineering is not neglected as a team focuses on modeling. Furthermore, we understand the semantic weaknesses and confusing terminology of SysML and can help teams communicate and function collaboratively. In the meantime, we observe that SysML must further adapt to the needs of systems engineering and incorporate those needs more thoroughly into the modeling language.

Leave a Reply

Your email address will not be published. Required fields are marked *