MBSE: Alive & Well

This blog is in response to a Reddit post by Rhedogian, “Change My View: Model-Based Systems Engineering in 2024 is at best overhyped, or is at worst actively dying.

Reddit user, Rhedogian, authored a post that has been a topic of great concern for me for many years. He states, “My breaking point with letting go of MBSE has come pretty recently, and I've done my best to remain hopeful in the concept despite my doubts, but at this point, I'm no longer confident in MBSE's ability to be a transformational force in system design as it's been sold.”

The Issues

 His solution is to have two things change:

1. “Integrations with Cameo need to be less sh*ty. All of the current options are expensive, finicky, or just straight up don't work. How can I expect engineers to use or care about the model if everything they put into Cameo ends up being a duplication of work they've already done elsewhere?”
2. “SysML is hard, and the UI of Cameo makes it no easier. This learning curve HAS to go down. I have only a small contingent of engineers who are actually willing to use Cameo for some of their work, and the content they produce is limited and basic because they don't have the time or willingness to learn the modeling language (they're too busy doing value-added work).”

SysML

SysML was introduced in 2007 at the same time as INCOSE defined Model-Based Systems Engineering (MBSE). Intentionally or not, SysML rapidly became equated to MBSE. More recently, MagicDraw (Cameo) has been equated to SysML, as if no other tool can do SysML as well.

The underlying problem is that SysML and modeling in general can only address certain portions of the systems engineering process and lifecycle. And given the close relationship between systems engineering and program management, SysML fails to address either discipline’s programmatic factors, such as cost, schedule, and risk.

Part of the problem is SysML comes at systems engineering from a software development perspective (it is a profile on UML!). It is not a systems engineering language, in that it does not easily address the real world of systems engineering.

As someone who has written code since 1971 and has been a systems engineer for over 35 years, I know that the two disciplines are very different. The languages and the tools for one will likely not work well for the other.

Systems engineering is all about requirements. And we don't have any real system that has only a few requirements, where you could use the SysML Requirement Diagram effectively. Most real systems have tens of thousands of requirements. Systems engineers have performed modeling to derive and verify functional and performance requirements. That is the primary purpose of modeling in system engineering.

A group of systems engineers realized this problem many years ago. Together, we developed the Lifecycle Modeling Language (LML) to address the deficiencies of SysML. LML is primarily an ontology with limited diagrams as a baseline. It was designed to provide an “80% solution” to the language needs of systems engineering and program management.

It is a true language in that it provides entity classes (nouns), relationships (verbs), attributes for the entities (adjectives), and attributes (adverbs). LML version 1.1 was enhanced to provide an ontology that included a few SysML-specific classes and relationships.

Tools

The tools problem is another story. The reason Cameo looks like it is from the 1990s is that was when the user interface was defined, and it has never been re-architected to the cloud computing environment (note: using the cloud for file exchange with desktop tools is not cloud native!).

SPEC Innovations realized this problem and began the development of Innoslate in 2011. Innoslate was the first full-lifecycle, cloud-native, systems engineering and program management tool.

The JavaScript user interface and Java backend have been re-architected three times since its first release in 2013. It embraced LML and has been used as a research tool for the language enabling LML to evolve as well to the current v1.4 with v1.5 and v2.0 on the horizon. Innoslate also embraced AI/NLP technologies early on and now has ChatGPT integrated with it, if desired.

Other seamless integrations with GitHub and Selenium link the systems engineering with the software engineer appropriately, enabling harmony between the two disciplines. MATLAB/Simulink and STK integrations with Innoslate’s discrete event simulator provide co-simulation capabilities needed for Mission Engineering.

If you are feeling the same as Rhedogian and looking for a modern MBSE tool, try Innoslate. If you want to join the dialogue on LML, visit the Lifecycle Modeling Organization’s website. Innoslate and LML could be the pain relievers I think you need. Doctor's orders!