Provided services
We provide different services around Model-Based Systems Engineering (MBSE) ranging from studies about pragmatic opportunities to use models, support on definition of a “model driven engineering” process and methods, up to efficient modelling deployment through tooling assessment and customization, training and coaching on operational projects.
Success or failure of MBSE deployment on a project or at enterprise level is generally linked to several factors.
Here are some of them that we find essential from our experience with several industrial companies.
- Modelling purpose and scope: do you intend to describe concepts (conceptual modelling)? illustrate requirements (descriptive models)? specify requirements (prescriptive model)?
- Without clearly defined strategy, there is high risk to mix those different purposes and finally consume a lot of efforts for limited results.
- Tips: define expected returns from modelling activity (support to requirement validation, support to requirement writing, support to architecture definition…) and durability of the produced model (intermediate means that can be thrown in the garbage or reference engineering artefact).
- Analysis and share of systems engineering practices that are applied in your company: do all of your colleagues share same vocabulary and definition for systems engineering concepts and activities ?
- In MBSE there is “SE”. Trying to build a unified modeling approach on top of heterogeneous practices is the best means to fail.
- Tips: take time to first verify that fundamental SE concepts are shared and fully understood: requirement, function, mode, scenario, logical/physical architecture… , and that activities are well described for the different processes, especially technical ones (ISO15288:2015). Then identify existing language (standard if possible) the most appropriate to formalize those concepts. SysML, Capelle, Simulink, Core… and specialize it to match your business domain/enterprise/project.
- Pragmatic approach based on project context: will you use same definition for a completely new system or for addition of a new function in a product line? for a critical system or an information system?
- If approach is too rigid, there is risk that team considers the change as a strong constraint and does not see benefits.
-
- Tips: leave degrees of freedom, especially between a top down approach starting from stakeholder needs analysis and a bottom-up approach that is based on assembling components. Truth is always a mix between those both approaches, but with weights that differ according to the project context, phases and team expectations.
- Identification of savings and quantification: can you explain what modelling approach will save for the project and after which period?
- This question is really important because there will always be managers to ask for such returns. Ignoring this request, it is ignoring approach sponsor and mortgaging the future of modelling…
- Tips: define a modelling strategy with precise saving goals on each project phase and modeling activity in comparison to an approach without modelling . Once savings are well targeted, you will have to define how to reach them and it might require adaptations in method (and therefore trainings, coaching, support) and in tooling. It is important to anticipate those efforts as early as possible. Concurrently, you will have to refine the savings, first qualitatively and then quantitatively through metrics on validation time, error analysis, iteration number to mature requirements… Those figures, when combined with efforts, will give you ability to conclude on modeling interest and will give you credibility on MBSE deployment.
You can read ICSSEA 2016 conference – MBSE tutorial: gradual modeling approach to support development of complex systems if you want to see practical benefits of an MBSE approach to support industrial development (based on ISO 15288 systems engineering standard).
We deliver practical MBSE training targeted to support systems engineering. It means that we present diagrams and concepts needed to perform 80% of your modelling activities. We are used to provide training for initial (engineering high schools, university) and continuous training (companies) and can adapt to different backgrounds, experience, culture.
Most of our training sessions concern OMG SysML language to support Systems Engineering, but we can build sessions for other modelling languages (Vitech Core, PolarSys Capella…).
Each training session is specific to the culture, context and background of attendees. We illustrate modelling approach with a sample case and work on exercises with the modelling tool you choose and one a case study that generally comes from your company.
Coaching
Training is one way to help systems engineering acquiring knowledge and practice but is not always the best solution for the following reasons: bad timing (training sessions might be too early before the project starts or too late (project already started for two months), limited availability(difficult to get all project team members available during 3 or 4 days in a given week), not enough experience(interesting and advanced questions arise often during operational project, often AFTER the training session, when training expert is no more available to answer….).
For all those reasons, it makes sense to provide another kind of support, through coaching, audit and dedicated meetings. We have experience on that and provide our modelling expert directly involved in the project. At the beginning, our modelling expert builds the model so that things progress fast and we can show benefits on completeness and consistency within days (quick wins).
Then, next step consists in doing “pair modelling” with a few team members ready to learn modelling language and tool and become experts in the future. When those referents are autonomous, our modelling expert becomes “second level” support and comes back in the projet only once a week (or less) to answer advanced questions and suggest modelling rules if needed.
We provide detailed analysis of potential benefits and needed efforts to implement this shift.
We support you in choosing right modelling language for your concerns. Concerning Systems Engineering, OMG SysML is a good candidate but it remains a general-purpose language and needs some customization in order to address domain vocabulary and existing domain specific standards. For instance SysML does not address natively the concept of “Function” that is a fundamental concept in avionics when dealing with safe systems (ARP4754a/ARP4761). We help detailing all the concepts you need to support systems engineering in your company and Which SysML concepts can be used or extended (through profile).
SAMAREQ method: in case you would like to start quickly with MBSE approach and do not know where to start, we can provide access to SAMAREQ
Samares Approach for Modelling of Architecture and REQuirements) that is a method defined by Samares Engineering.
Here is an illustration of approach suggested by SAMAREQ method:
Please find below two presentations about SAMAREQ methodology. First presents the identification of requirements within the model: Catia NMEC 2019 (Hambourg) – Specification development during modeling
The 2 videos below show the demonstrations done during the conference. They illustrate the SAMAREQ approach in the context of a UAV for aircraft inspection.
The first video illustrates the translation of functional needs into operational scenarios and identification of functional interfaces and top-level functions.
2nd video shows how to initialize logical architecture from functional architecture and allocation of functions on components.
The second presentation provides more details about SAMAREQ: No Magic European Conference 2018 – Building Good Quality Functional Specification Model
You can contact us if interested.
Sometimes companies have already defined their own corporate modelling tool and have to use it. And sometimes it is less guided and project might need some pieces of advice to choose the most appropriate modelling tool.
We know different systems engineering modelling tools and especially SysML tools (commercial and open-source solutions)…:
- MagicDraw/Cameo System Modeler (NoMagics) ,
- Enterprise Architect(Sparx Systems ),
- Rhapsody (IBM),
- Rational Software Architect (IBM),
- Papyrus (Eclipse foundation),
- Modelio (ModelioSoft),
- Integrity Modeler (PTC).
But also other solutions not based on SysML:
- Capella (PolarSys) ,
- arKItect SEA (Knowledge Inside),
- Core (Vitech),
We define with you the key assessment criteria according to your context and modelling goals and perform assessment with scores ranking from 0 to 2 for each criterion. Your company defines weights for each criterion and we can then apply a global mark that gives a formal assessment.
Then we support you in defining and building your modelling platform from your modelling language or by extending existing one (SysML, Capella, Core…): customization, assessment of technologies to complete existing platform or to bridge it with external tools (requirement tool, physical simulation…)
See ERTS 2014 conference – Efficient modelling of avionics systems: combining standard language and custom editor as an illustration of work done with Airbus to build a custom modelling tool based on Eclipse Papyrus SysML to support functional architecture definition.
Below is an example of definition of a modelling platform based on a specific modelling language (meta model) through Eclipse technologies: EMF, Sirius…
