MBSE Summit 2024

The Impact of SysML v2

The next-generation modeling language, SysML v2, is about to be officially born this year. So people are wondering what impact does it have for me, for us, for my organization, for the community or for the world.

Of course, the talk will also highlight the motivation and main features of SysML v2, but we’re not going to go through the dictionary element by element. I can promise you that there will be books that do this better than a keynote.

We will focus on the impact of SysML v2 on different time horizons and dimensions. What impact will it have if I implement it today, in 2 – 3 years, or even further in the future? We will touch on very concrete practical modeling questions but also visionary scenarios. To do this, we will naturally look at aspects of SysML v2. For example, the API, which is technically simple but has game-changing potential. Or the textual notation, which will have a major impact, including opening the door for large language models.

You will learn a lot about SysML v2 and get plenty of food for thought. A good basis for further discussions with the participants at the conference.

The beauty of MBSE – reducing efforts by extending the scope

Model-based system and software engineering targets on providing a single source of truth for ourengineers. The goal is to provide orientation, support with the alignment of interfaces between partners and between disciplines. By for- malizing information in models, it becomes machine-readable and persistent. If we look into the real world, in many cases MBSE is not seen as a support but a hurdle by the development team. “Why should I spend the effort to document this in this tool, I anyhow don’t search there”, “My component has too many different users, I just care about my part. That MBSE introduction often comes with “big-upfront” ideas driven by architects in a central department is for sure no support factor in the innovation process.

We provide an example, where extending the scope shows a clear benefit for the development teamwithout big-upfront or top-down roll-outs. For safety-rel- evant products according to IEC 61508 or industry-specific derivates of this norm we nowadays have some kind of standard. Systemarchitecture in SysML, software architecture in UML or tool supporting code generation and cross- functional teams working on the safety analysis in FMEA and FTA.

When target to faster release cycle and shorter time-to-market, the benefits of a single source and alignment between the disciplines become evident. Com- bined with change-based reviews and automation support for consistency checks, the workload can be shifted from large post-development analysis workshops into the development teams.

We assume, that a basic architecture model showing the decomposition struc- ture, data flows and control sequences is created anyhow in the architecture team. By extending this standard modelwith one meta-element “FailureMode”, which is used to model cause-effect chains from the bottom-layer up to the vi- olation of a safety requirement and relations to mitigation measures for prevent- ing and controlling the failure modes, the safety analysis can be performed by the development team.

The approach is simple and easy to learn. Of course, you need coaches to bring the safety background into the teams, but you replace large meetings late in the development process with technical discussions in the product definition phase.

By extending the scope, we get more competence in the team, reduced efforts and a better riskmitigation. What do we learn for innovation topics, and MBSE introduction is for sure an innovationfor an organization, from this? Identify the pain of the team (here: longly FMEA sessions) and provide a solution for the pain (Safety Analysis integrated in the architecture). This reducesopposition as the gain (here: self-control of time) is greater than what must be given up (per- sonal favorite text-based documentation style). That’s the beauty of MBSE: You extend the scope a little, but having a shared ground-truth for the different teams creates a huge benefit.

Mission Engineering for Long-Life Systems

Long-life systems are extremely challenging to engineer.  Sometimes executive stakeholders don’t understand the scope of the problem. In other cases, the long-life of the system is a surprise. Finally, there are the cases in which an organization procures a technology system without any planning for anything beyond the initial deployment. At Systems Strategy, Inc some of our client engagements are specifically about helping clients model the least awful course of action in managing a large system of rapidly aging technology components.

In this presentation, we will first discuss several concrete examples of organizations that failed to plan realistically and ended up floundering in awkward attempts to manage the headaches. In reviewing these concrete cases, we will dig a little deeper into the more subtle aspects of this problem. In particular, we will discuss:

1. Financial Risk – Who accepts the responsibility for the uncertain future?
2. Human Resources – Humans are part of the system too.
3. Unsustainable Business Models – What if our business model was only laid out to look profitable for the next three months?
4. Warehousing – This strategy is not as easy as it sounds.
5. Open Market Buys – We forgot to build a warehouse.
6. Organizational Transitions – What if the support organization is no longer in existence 20 years from now?

With this background, we will present a study case of a hypothetical business that is fully aware of the challenge at the beginning. The study case will show how Mission Modeling using the Unified Architecture Framework can be used to set up a trade study of strategies to mitigate the challenges. Finally, we will give a brief demonstration of how simulation in SysML and other tools can be used to evaluate the trade study options and help the business decide on a strategy.

TBA

The Future of Systems Engineering

Exploring MBSE Trends in Research and Industry

Model-Based Systems Engineering is becoming increasingly important. From design to execution, complex systems should be supported with human-comprehensible and machine-readable models. In this context, the second MBSE Summit was held in Traunkirchen on June 5 and 6, 2023. More then 80 national and international experts and interested parties from science, research, technology, and industry met to discuss current trends and open challenges. The summit started with keynotes from standardization, research, and industry and was followed by intensive discussions in small breakout sessions on different MBSE focal points. It became clear that implementing model-based systems engineering from safety to standards to process quality is essential. Still, often, benefits have to be explained more intuitively, and the exchange between users needs to be intensified through training and discussions.

Car

There is a free parking lot in Traunkirchen parking P2 Lunn Park. From there you walk 300m to the academy.

If you arrive by car and stay at the hotel “Post am See” or Seehotel “Das Traunsee” in Traunkirchen, please contact the respective hotel directly regarding parking.

Cab

If you are staying overnight outside of Traunkirchen in a town at Traunsee and do not want to or cannot travel either by public transport or with your own car, there is also the option of cab.

Possibilities: Cab Aicher, Taxi Premm

What Participants say about the Summit 2023