MBSE is the future, but today's tools suck: Insights into MBSE by Pari Singh (Part 2)
Interview Part 1 | Part 2
Last week, I published the first part of the interview with Pari Singh here, which dealt with the criticism of current development tools in systems engineering and the need for a paradigm shift towards more agile and iterative methods.
Here is the sequel, in which Pari comments on the importance of modeling, SysML and the suitability of the tools in use.
In Part 1 you can also find the video of the entire interview. Enjoy reading!
I would like to shift the focus to a more technical topic. Do you think modeling plays a role in this change, and if so, are we going in the right direction? Do you have an opinion on SysML v2? Are we at an impasse? Are we on the right track? Is it a catalyst? What do you think of the idea of making our development artifacts more digital through modeling?
I have a very strong opinion on this subject. I will probably make a lot of people very angry. I was at an INCOSE conference a few years ago and I withheld my opinion. The first point here is that MBSE is the future. And in my opinion, there are two big parts to MBSE:
There is the model-based definition: a model-based view of a system and then the use of digital models, analysis tools and numerical models to complement these and make the model richer and more vivid. So on paper, moving from a document-centric view to a model-centric view is clearly the future. That being said, we believe that MBSE tools completely miss the point, we think MBSE tools suck. And if you show SysML v1 or v2 to anyone in any other industry and say it's the future of engineering, they'll laugh at you. The reason it's so disastrously wrong is because the core purpose of MBSE is to create a unified model that everyone across the organization can use as a source of truth. That is the main goal of MBSE.
MBSE was developed to create a unified model that everyone can use as a source of truth. It is designed to help mechanical, electrical and software engineers all take the same view.
Pari Singh
For this reason, MBSE was developed to create a unified model that everyone can use as a source of truth. SysML and MBSE tools are so difficult to use that users need a lot of training, they need to think about the ontology and the structure. And the only people who know how to use this tool are a few very well trained systems engineers who then enter all the information into SysML v2. They sit in a corner and export documents that they send to the rest of the team, which means that the rest of the team only uses documents, which means that the whole point of MBSE is useless! So for MBSE to be successful, it needs to democratize systems engineering.
MBSE must enable non-systems engineers to have the same view as systems engineers, and it must enable systems engineers to move from documentation work to a more holistic view of the system and help mechanical, electrical and software engineers to have the same view. So the biggest shortcoming of SysML and MBSE tools is user-friendliness. We need to make these tools appealing and usable for non-systems engineers as well.
Engineers who are not systems engineers should be able to pick up an MBSE tool and just say, "Oh, hey, I understand stage one and stage two and the insides of stage two. I live on the engine team. So I click into the engine team and then I see the three or four interfaces to the other systems that I need to communicate with and see the latest versions of those interface requirements with the interface values," and become a unified model for the entire team. The people I see in the systems engineering community who are the most advanced with MBSE usually have a huge wall, print out a model and hang it on the wall for everyone to use.
We need to make MBSE tools appealing and usable for non-systems engineers.
Pari Singh
Printing out a Miro or draw.io diagram and hanging it on the wall is actually more suitable for an MBSE than some of the existing tools or SysML v2. I think the intent behind these tools is impressive, but I don't think the tools are suitable for non-systems engineers.
The tools are certainly one issue, but the modeling language is another. The proponents of SysML v2 say that the simplification, the text notation and the API make the language much better suited to the vision you describe. What about the modeling language? And is SysML v2 the future or is it another dead end?
I don't have a strong opinion on the actual modeling language itself. I think all tools have strengths and weaknesses, but I have found that many systems engineers put too much emphasis on ontology. Ontology is really, really important, and it excites me because I can start to think in layers and philosophies and create structures. I can start creating objects and classes.
But I think that's probably the wrong approach to start with. Of course, we have to get there at some point. But if you start with that, it puts a lot of people off, and it creates structure and imposes structure where you don't necessarily need it. And that's the crux of the matter. If I had to point out one thing I wish our community was better at, it would be understanding the difference between a good process and actually delivering a product.
Many systems engineers, especially young systems engineers, read the NASA Systems Engineering Handbook and the INCOSE Handbook. And they say, if I just follow all thousand of these steps to the letter on 200 of these pages, I'm guaranteed to get a good product. And then, ten years later, they follow every single step and every single guideline, and they write empty statements and unfortunately don't create a good product.
If I had to point out one thing I wish our community had a better handle on, it would be understanding the difference between a good process and actually delivering a product.
Pari Singh
What we have seen in other areas is perhaps too extreme an approach, i.e. simply building and delivering something without a process, without steps, without requirements. And this approach actually delivers a great product, but is it also safe and reliable? We need to find a happy medium. So we need to find a middle ground where we empower non-systems engineers to develop a systems mindset by helping people get into the requirements process and into the MBSE process. And we turn a silo into something that sits at the heart of the team and is a living model. To do that, a Systems Engineer needs to be able to give up some control of their team so that the teams that are not made up of Systems Engineers can work better with them.
I come from the early days of software development. I remember in the 90s there was a lot of discussion about software components and reusability. It seems to me that we are repeating what happened back then, because today we have that. You just have to pick the right architecture for a software project and all the pieces fall into place and you can start creating productively working software.
This is an important point. UML was rejected by the software development industry, wasn't it? They tried it, it was a great idea, but they didn't find it useful and it was rejected. And then we cloned the approach: we converted UML to SysML, we added some features and we think it could work for our use case. I agree with the philosophy and the intention behind MBSE, but I think we might have missed the mark in the actual implementation.
What role does traceability play in this transformation, and can you also say something about flow engineering and how you intend to solve this system engineering problem in your company?
Gladly. First of all, the Traceability one of the most important things a systems engineering team needs to get right. It is the reason for the existence of systems engineering. It's to help tie all these different functions together to understand when a change happens in one place, what the impact of that change is, and to make sure that we have a really good process to deal with it. Traditional systems engineering only tracks the requirements, and only at the mission system level and maybe the subsystems, but that's about it. So two really important parts of traceability are lost. The first part is the requirements at the deeper level of domain engineering.
So how do we break down a system or subsystem requirement into specific low-level requirements that an engineer can deliver in their V&V? And secondly, traceability to design is lost in the process. So we have all these great requirements that say here's what we need to do. Then we have no traceability whatsoever, except that we link to it, for example, with a video or a photo of the airplane to prove that it actually works. And we're finding that there's a real need for more detailed traceability as our systems become more complex and cross-functional.
And this is also reflected in the quality control standards that exist. One example that I know very well is nuclear technology. In the nuclear industry, new regulations such as NQA-1 now full traceability, not just to requirements, but to specific design assumptions and specific design parameters that drive the various elements of the system. We think traceability is great, but if you only trace at the system mission and subsystem level, you lose 80 % of design and 80 % of value that comes from traceability. So we need more traceability, that's my conclusion.
Conventional systems engineering only tracks the requirements, and only at the level of the mission system and perhaps the subsystems, but that's it. So we need more traceability.
Pari Singh
How does Flow Engineering fit into this concept? Flow is developing a modern, agile, next-generation requirements tool. We are building the platform that systems engineers have always dreamed of. I would say it's the first modern systems engineering tool that looks like it was developed in the 2020s and not the 1990s. Our key point is that we help Systems Engineers break down requirements from the mission down to the component level and then enable live traceability and live integration with non-systems engineering teams.
The other major philosophy in systems engineering that has been propagated for some time is continuous integration and continuous testing. This philosophy has been adopted by the software industry and has proven its worth: We have requirements that are actually tests. Can we link these tests to our design? And the moment a design change is made in one team that affects another team, that affects a third team, my requirement is invalidated. Instead of waiting three or four months to find out this information, I can find it out immediately. And instead of losing the thread, I can use the computer to automate all the V&V work and get information faster about which requirements are there and which are not.
That's what Flow does. Flow is developing a next-generation requirements tool that links systems engineering and requirements to design, enabling continuous integration and verification across the entire team, not just one team. We are now working with some of the best engineering companies in the world.
We work with some of the biggest and most demanding aerospace companies, but also with companies from the automotive industry, the nuclear industry, medical technology. And we probably work with the fastest and best teams out there. I would say we are the market leader in the advanced requirements tools space, which is fast becoming a highly competitive market. But we're probably ahead in every single dimension, and our magic is our product. If you want to find out more flowengineering.com and quickly get an idea of our MBSE capabilities or our requirements and integration capabilities.
