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.

Transportation Revolution through Automation

Transportation-related decision-making significantly impacts CO2 emissions, thus contributing to climate change. The incorporation of automation and connectivity into this framework introduces a transformative dimension. Physical and virtual interconnections, make it possible to evolving transportation demands through digital technology by leveraging sensor integration within information and communication technologies, These dynamic scenarios are crucial in shaping decision-making processes related to traffic safety, a topic that will be thoroughly explored during the presentation.