More efficient safety management with MBSE

April 25, 2023 – Reading time: 7 minutes

“Breaking down silos leads to true teamwork, removing obstacles and tuning efforts yields reduced error costs“ – In this expert talk, Jan Zutter, Head of Systems Engineering at INVENSITY, and Christian Dahm, Systems Engineering Consultant at INVENSITY, discuss the advantages and potential risks of switching to and using MBSE in development. They explore the question of how safety management can benefit from a model-based development approach.

 

Jan Zutter: The switch from requirements-driven to model-based development (MBSE) is one of the most controversial topics discussed in systems engineering. Christian, you have been working intensely with MBSE for quite some time now. You emphasize that one of the main advantages is the connection of individual departments or the breaking down of “silos”. How did you arrive at this evaluation?

Christian Dahm: That’s right. The breakup and connection of existing “silos”, meaning  structures of development departments that operate independently without sharing information, is in my view, a game changer in the positive sense.

To explain this topic, let’s take a step back and first look at “classic” development. Here, along with the V-Model, specifications are created in the form of textual documents after the completion of the work packages, be it requirements or architecture. This approach is still relatively transparent at the system level since only one discipline is involved. However, if the specification documents are passed on to the departments working in parallel (hardware, software, mechanics, safety) along the development process in the V-Model, it becomes increasingly difficult for the information to be transparent and complete.

In every development department, there are interfaces and topics that should also be processed across departments. Unfortunately, because of silo thinking and the massively parallel work in the V-Model, a lot of redundant information is inevitably generated. In my opinion, this can be broken down through the implementation of MBSE, which allows for transparent and consistent linking of safety analyses, such as an FMEA (Failure Mode and Effects Analysis), with the architecture and requirements.

Jan Zutter: Let’s focus on the topic of safety management. In this context, you investigated the extent to which the modeling language SysML is suitable for representing FMEAs. Aren’t FMEAs long-established and their procedures coordinated?

Christian Dahm: Yes, you are correct. Within the departments or the safety silo, the procedure for performing safety analyses like FMEA have been consistently done for years. This is exactly where I see the opportunity to stillimprove the situation with Model Based Systems Engineering.

We already saw at some customers that safety managers build the system architecture themselves since they need function- and structure-trees to create the FMEA. On one hand, this is not the job of the safety department. On the other hand, it subsequently requires effort for the architect to understand the architecture, incorporate it into the overall architecture, and identify and implement opportunities for improvement.

Jan Zutter: I see. So, your main concern is making FMEAs and their basis in architectures more transparent to the entire development team?

Christian Dahm: Transparency is the key word here. The massive change brought with MBSE is the way from document-centric development to decentralized work by all departments and disciplines in a central system model.

Silo thinking should be broken down since departments like safety and architecture operate in this system model at the same time. This means that relevant information is available to every stakeholder and duplicated work is avoided. To ensure this, processes and their sequence must, of course, be followed. For the time being, it is not important who creates and models the necessary structures in the architecture, be it the architect or the FMEA analyst.

For this approach to work, it is fundamental that the tools used, starting with the requirements and ending with testing, are linked to each other and can represent a system model.

This system model is then the “single-source-of-truth”, eliminating the need for hundreds of specification documents that previously served as a database. With the old system, information was hidden deep in the texts and was not visible at first glance. Furthermore, the large number of documents made it complicated to accomplish completeness, consistency and traceability of decisions and relationships between the documents and their contents. In MBSE, only the system model serves as a source of information. Documents can still serve as output if desired but never as as input.

Jan Zutter: What benefits do you expect from this approach for companies? Why is it better than using dedicated tools?

Christian Dahm: If the dedicated tools used can be linked to each other, there is no need to invest in new tool platforms. The only premise to continue using them is that these tools can be interconnected. Ideally, some kind of gateway tool can be utilized to access the content of all linked tools and represent them as an entire model and single-source-of-truth.

In addition, I can say that it is advantageous if a consistent modeling language is used throughout the entire development phase – in my case, the System Modeling Language (SysML) Version 2.

Jan Zutter: Now that we’re talking about modeling languages, how do you currently rate the possibility of mapping FMEAs in SysML?

Christian Dahm: I explored the possibilities of representing an FMEA in a model and linking this model with the system architecture. Focusing primarily on the beta version of SysML Version 2 showed that it is possible to create an FMEA model and link it to an architecture in a traceable way, something which the SysML V1.X cannot offer.

Jan Zutter: If I understand correctly, is linking an FMEA and architecture models in SysML V1.X not possible at all? Is it worth considering changing SysML to better represent FMEAs? 

Christian Dahm: I would like to answer this question with a clear yes – and this change or adaptation has already been made or is possible. In detail, the RAAML (Risk Analysis and Assessment Modeling Language) specification provides an extension to the system modeling language SysML V1.X, which is used to support safety and reliability analyses. SysML alone provides a good foundation for representing the fundamentals of a (system) architecture. However, no models are available to capture safety and reliability information in the system model. The RAAML specification thus demonstrates the possibility of an approach for the automated implementation of various safety and reliability analyses. It builds on existing SysML V1 functionality to ensure that the profiles and libraries can be used with tools already on the market – creating a kind of template for performing model-based safety analyses (FMEA) in SysML V1.

Jan Zutter: That sounds promising. To which companies would you recommend migrating from existing tools? What requirements should they meet and where do you see the greatest benefit?

Christian Dahm: The shift towards model-based systems engineering in the systems engineering discipline is based on the increase in complexity.

What exactly do I mean by complexity? As the complexity of the systems continues to rapidly increase, the complexity of the development processes should be as low as possible. From my point of view, introducing MBSE can greatly reduce the resulting loss of efficiency for companies with complex systems, multiple hierarchies and departments, and high efforts in coordination and alignment.

Jan Zutter: Do you see any risks in switching from the established approach to a representation in SysML?

Christian Dahm: I don’t see any risks in switching but it will require a significant amount of effort until a model based FMEA matches the efficiency of an FMEA performed in Excel, for example. Excel is a widely used tool, and companies can stick with the FMEA form they developed and are familiar with. However, if companies want to move away from an Excel-performed FMEA and establish MBSE, an FMEA tool must be purchased and set up. Trainings must be held, and employees need a learning period until they can operate the new tool. Lastly, the FMEA tool must be linked to at least the architecture tool and connections must be created. Otherwise, the added value of this effort would not be there.

Jan Zutter: At first, this seems costly and daunting. However, you are convinced that the investment is worth it. What specific advantages do you see in a model-based environment compared to the classic requirements-driven approach?

Christian Dahm: I believe that the model-based approach offers teams higher quality results. Safety management analyses could be performed more easily and more efficient, as the architecture would be directly linked to product and functional structure, reducing waiting times between the silos. A decentralized approach like this allows work on the central system model to be done in parallel, leading to enormous savings by eliminating high coordination and alignment efforts known from requirements-driven development. Additionally, error costs are much lower with MBSE.

Authors

Resources