Modelling a migration plan with Arcadia

Hello Antoine,
I find your question quite interesting and I’m surprised that you did not receive any answers so far. I am a beginner so I wouldn’t be of much help. But I would like to ask you a followup question: Given the large effort that you propose for putting your migration process into an Arcadia model, what added value do you expect from this undertaking?
Cheers,
Sergio

Hello Sergio
The added value I expect boils down to the content of the first paragraphs: demonstrate that each temporary configuration that will be used in commercial service provides the required functionality. Given the complexity of the system considered (number of subsystems, distributed architecture, safety-critical, mix of legacy systems and new components…) and the need to communicate with the client about service continuity, model-based approaches can be quite powerful. Furthermore, using the library mechanism ensures that components that appear in several configurations are consistently described in all those configurations.
I guess (but it’s only a guess) that the main reason I didn’t receive answers is that this “migration” use case is not a typical one in the industry that currently uses Capella with a reasonable level of maturity. The tool and the method are best suited to the design of new systems (albeit based on old systems or using existing COTS), but their focus isn’t on the long-term evolution of a system through various phases.
For what it’s worth: we applied the method outlined above and got some interesting results. The principle based on a shared library + one project for each phase worked as expected. And the implementation of library-related functionality in the tool is good (I thought we would find bugs or unfinished functions but in fact it works quite well !). Of course it still is a complex problem, but at least we could think about it without worrying about the aspects handled by the tool (including consistency across configurations). We eventually had to stop experimenting with Capella on this specific project, but this decision was not linked to a shortcoming of the tool or approach above.
Antoine

Antoine, sorry we missed your post at the time. Your problem is an interesting one.
We have been working these last months on both methodological and tooling solutions to better analyse the impact of modes and states on the rest of the system. To do so, we have introduced the concepts of
Configurations: allowing to mark which elements of the system are available or not in a given context – functions, ports, components, etc.)
Situations: specific contexts of interest representing a superposition of current modes and states in different state and mode machines.
The result of this is that we have a first set of means to model and study the variability of the system during its execution. In particular between two given situations. I have the feeling it could have been of interest in your case. Your different migration phases would for example be modeled with Modes.
Our solution is still a prototype and is not yet included in Capella. But alpha/beta versions will probably be made available in the coming weeks.

Stéphane,
Thank you for getting back to me on this subject. It sounds really interesting and I’ll definitely keep an eye on this development.
I’d just like to highlight something you probably are aware of but that may be of interest to other readers:
The modeling problem I described in the original post above is what I call the strategic evolution of the system. It is long-term and one-way. Example: how do we migrate our current road system (vehicles and road) to a driverless system ?
The modeling problem you are working on is, as you said, “the variability of the system during its execution”; I understand it as the tactical adaptation of the system to changes (whether external changes like a new actor in the environment, or internal changes like the failure of a component). It is short-term and definitely not one-way. Example: what happens to the driverless car when a pedestrian crosses ? When a sensor fails ?
I agree that the modeling constructs that will be introduced to solve the second problem would probably be useful to tackle the first one.

Dear Antoine and Stéphane, thanks a lot for your insights. It is indeed comforting to know that the amount of real-world evidence of the value of model-based system engineering (MBSE) is increasing, and the tools support is being actively improved. From my perspective (space industry), there is a huge potential accompanied by an equally sizable skepticism, that can be mitigated by referring to case studies and by pointing at yet undiscovered use cases.
I’m wondering if there is a kind of repository for Capella use cases that goes beyond the examples and provides real-world models (or at least non-NDA-bound versions of them). It would definitely serve a dual purpose:

  • As the aforementioned evidence of the value of MBSE and
  • As a reference source for the beginning engineers, where common patterns or interesting modelling techniques can be discovered and learned.
    Looking forward to experience the evolution of Capella.
    Cheers,
    Sergio
Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.