A Taxonomy of MBSE Approaches by Languages, Tools and Methods

Systems engineering has gained in maturity over the last decades and started a transition from document-centric approaches to Model-Based Systems Engineering (MBSE). Several papers have discussed the benefits and potential, but also the limitations, of using MBSE, based on literature surveys and analyze feedback from academia and industry. The current paper explores a complementary avenue and aims at giving students and industry practitioners a set of keys and decision criteria to select MBSE languages, tools and methods. Languages, tools and methods are categorised and selection criteria are proposed for a panorama of languages that goes beyond SysML and other techniques commonly associated with MBSE. In addition, research avenues for the future of MBSE are identified. The discussion relies on the authors’ experience in teaching and using system engineering and MBSE in both academia and industry, as well as on the experience shared within the framework of Concorde, a French project dedicated to drone systems design methodologies.


I. INTRODUCTION
Systems engineering (SE) has initially relied on a documentcentric approach. Whether documents are commonly accepted for conveying information, their scattering among the stakeholders (project management, marketing department, and manufacturing department, just to mention a few) hampers the sharing of consistent information. Starting from identified limits and pitfalls of document-centric systems engineering, amongst others the scattering of information, the potential ambiguity in the descriptions, and the absence of a good possibility to perform verification and validation based on such documents, solutions have been investigated and MBSE has opened up promising avenues for systems engineers [1]. With no intent to be exhaustive, application domains of MBSE include railway [2], [3], nuclear plants [4], aircraft operability [5], drones [6], and lunar exploration [7].
The associate editor coordinating the review of this manuscript and approving it for publication was Claudia Raibulet .
The expected benefits of MBSE include a better management of the requirements, a reduced ambiguity, and the possibility of performing a formal verification and validation process. Over the past few years, several papers have analyzed feedback reports from users of MBSE approaches. These papers mostly confirm the benefits of MBSE [1], [6], [8], [9], [10], [11], [12], [13], and less frequently mitigate these benefits [14], [15], [16], [17], [18]. Much rather than to reopen discussions on the pros and cons of MBSE, the purpose of the current paper is to place itself in a context where the switch to MBSE was already decided by a company or research institute and to address the selection of languages, tools and methods. The objective of this paper is indeed to categorize the languages, tools and methods in order to give students and industry practitioners the keys to select MBSE languages, tools and methods that meet their professional and learning requirements.
In terms of languages, the MBSE acronym has regularly been associated with SysML [19], the Systems Modeling Language standardized by OMG (Object Management Group) with the support of INCOSE (International Council for Systems Engineering). SysML is a graphic and semi-formal modeling language that applies to a broad variety of systems. As far as real-time and critical softwareintensive systems modeling are concerned, several limitations of SysML have been identified in terms of expression power and semantics, leading to extended versions of SysML [6], [11] that bridge the gap between SysML and the world of formal methods. The latter are mathematically grounded and enable formal checking of models against design errors, early in the design trajectory of systems.
The expected benefits of MBSE are not only to master the complexity of the systems under design, but also to offer a support throughout the life cycle of these systems. The maturity and user-friendliness of tools is a key enabler for MBSE development. MBSE tools include models editors, simulator and formal verification software enabling checking of models against design errors, code generators, and test sequence generators.
Last but not least, the success of transitioning to MBSE and acceptance in industry heavily depends on methods guiding systems designers in the way of using the modeling languages and tools.
This paper aims at addressing each of these three categories (language, tools, methods) so to evaluate where we are today. Then the paper continues to see where the new challenges are and how MBSE can be used to address them. The paper is organized as follows. Section II surveys papers that offer surveys on MBSE. Section III presents and categorizes several modeling languages commonly used in MBSE. Section IV then surveys different tools, both commercially available and tools in research status. Section V continues to present methods. Section VI identifies research directions. Finally, Section VII concludes the paper.

II. RELATED WORK
Over the past decade, a high number of papers have included the MBSE acronym in their title or abstract. Such an abundant literature has open avenues for other papers that survey and categorize MBSE approaches. The word ''taxonomy'', which appears in the current paper's title, was first used in [20] where Monteiro, Gil and Rocha categorize MBSE approaches in terms of system specification repositories, system execution models, and design automation models. The current paper proposes a taxonomy that differs from [20] and insists on the theoretical background of the surveyed languages and tools, for instance in terms of languages' paradigm and semantics, and theory behind formal verification tools. Further, the taxonomy proposed by the current paper relies on the authors' experience in teaching MBSE and not exclusively on paper-reading based feedback.
In [21] Madni and Sievers analyze the motivations for MBSE adoption and identifies system architecture, information search and requirement management, and communication and collaboration as key issues. The authors of [21] further confirm that a model abstracts a system and conveys a viewpoint. They further underline the importance of verification and validation, and this is another common point with the current paper. Another similarity lies in a classification in terms of languages, tools and methods even though the number of languages, tools and methods surveyed in [21] remains lower than the number of languages, tools and methods surveyed by the current paper. In terms of MBSE tools, the current paper presents a greater number of tools than [21] does, and addresses them in more technical terms, for instance when the current paper categorizes verification tools and code generators. In terms of methods, [21] focuses discussion on pattern-based, template-driven and feedbackenabled approaches. Finally [21] identifies future research directions with subjects as various as augmenting MBSE with descriptive and analytic models of humans, models complexity management, digital twin development, and MBSE methods that cover the full system life cycle. The current paper also addresses these issues and enlarges discussion.
In [22] Basnet, Bahootoroody, Chaal and Valdez Blanda enumerate criteria for selecting modeling languages and present a decision-making framework that integrates the endusers' opinion in the selection process. The authors of [22] identify several comparison criteria. Examples include structural modeling in terms of elementary block composition, behavioral modeling in terms of state or exchanged messages, traceability among several parts of the model, amount of resources for modeling, and difficulty in creating, interpreting and managing models at the appropriate abstraction level. Application of the aforementioned selection criteria is focused on the SysML and OPM modeling languages. Unlike the current paper, [22] surveys modeling languages independently of any tool and method and ignores several families of languages, e.g., formal methods, which are addressed in the current paper. The later further surveys tools and methods.
In [23] Azad, Sint, Zeman, Jungreitmayr, Wahl, Wenigwieser, and Kretschmer discuss a framework for MBSE tool selection ad rely discuss on user needs. Unlike the current paper, [23] focuses discussion on a limited number of diagrammatic modeling languages such as UML, SysML and BPMN. Further, MBSE tools are individually compared, thus ignoring possibilities to interface MBSE tools with external ones, in particular to implement formal verification (e.g., model checking) of models. By contrast, the current paper surveys formal verification tools and open doors for joint use of MBSE tools with tools developed by for other paradigms, e.g., MBSA [24] and MDAO [25].
In [26] Akundi, Ankobiah, Mondragon and Luna convey an industry point of view of what MBSE is and discusses MBSE adoption challenges. The approach developed in [26] is complementary to the one in the current paper in the sense that [26] mostly relies on interview of industry practitioners where the current paper surveys tools, as well as languages and methods, by essentially relying a literature review augmented by the authors' experience in teaching MBSE. VOLUME 10, 2022

III. LANGUAGES
In the same way as programming languages, or also spoken languages for that matter [27], modeling languages are defined by their syntax and their semantics. Languages can roughly be categorized into three categories: • Non-formal languages, • Semi-formal, usually diagrammatic languages, and • Languages based on formal methods endowed with a formal semantics, enabling formal proofs. Figure 1 gives some more insight in this categorisation. Different types of languages are shown, that will be more detailed in the next sub-sections, with the exception of non-formal languages that are not addressed in the current paper. Two green arrows indicate that several features of SDL and Statecharts have been introduced into UML 2.0.

A. SEMI-FORMAL LANGUAGES
This sub-section first surveys main graphic and semi-formal modeling languages. Then it focuses on UML and SysML, two standardized modeling languages frequently associated with the concept of MBSE, followed by a discussion on Arcadia/Capella and AADL.

1) TAXONOMY
One can see a large number of semi-formal modeling languages that are used at the moment. The following enumeration categorizes them: • SDL (Specification and Description Language) [28] and its companion standard MSC (Message Sequence Charts) have been developed for protocols and communicating systems; • VHDL-AMS (VHSIC Hardware Description Language), a hardware description language, with analog and mixed-signal extensions), used mainly for electronics systems, in particular those systems implemented on FPGA cards [29]; • Mathworks languages (Matlab, Simulink, Stateflow et Simscape) [30] originally developed for control systems modeling, but increasingly used for systems development; • Modelica, dedicated to mechatronic systems [31]; • AADL (Architecture and Analysis Description Language) [32], dedicated to embedded architectures description; • UML [33] and its related languages such as SysML [19], widely applicable modeling languages used in SW and Systems Engineering; • OPM Object Process Methodology [34], a systems modeling paradigm that integrates system structure and behavior. Besides these generic modeling languages, there are also DSML (Domain Specific Modeling Languages) that specifically address a particular application domain. The remainder of this sub-section focuses particularly on languages owing a broader application domain.

2) FROM UML TO SysML
UML (Unified Modeling Language [33]) is an international standard at OMG (Object Management Group). UML was originally designed with software modeling and development in mind and results from efforts to federate best practices in use among software engineers. UML supports use-casedriven analysis and object-oriented design. Its object orientation enables modeling software in UML before coding in Java or C++ (just to mention a few).
As much as the UML standard defines a notation, there is no specific method associated to it, no specific approach of using it. The lack of tool specification and associated methods in the standard makes this language to have a large application domain. The concept of ''profile'' allows for customising UML for a specific application domain by improving the language's expression power and formalizing its semantics as a prelude to developing tools.
The increasing development of real-time systems has stimulated research work on real-time UML profiles [35]. Many of such profiles have seen the light of day and OMG has standardized one of them: MARTE (Modeling and Analysis of Real Time and Embedded systems). MARTE was applied to avionics development [36]. Another example is TURTLE [37], a real-time profile that bridges the gap between UML and formal methods. TURTLE was the first UML profile supported by the free software TTool [38], which has now become a SysML tool.
Like UML, SysML is a notation defined independently of any tool or associated method. The UML, and therefore software-oriented, heritage of SysML has regularly been questioned. At the time of writing this paper, version 2 of SysML is in preparation [39], but not yet standardized.
The current version 1.6 of SysML enables covering the requirement capture, analysis and design steps in the life trajectory of systems. SysML particularly extends UML with a requirement diagrams enabling requirement expression and categorization, as well as requirement traceability with respect to other analysis and design diagrams. Analysis is use-case-driven and documented by scenarios and flow charts. Decisions taken during the requirement capture and analysis steps will help populating the design diagrams that model a block architecture of the system and the behaviors of the blocks. Joint use of MBSE stricto sensu and Multi-Disciplinary Analysis and Optimisation techniques (MDAO) may also help taking design decisions and therewith populating the SysML diagrams [40].

3) ARCADIA/CAPELLA
Today's flagship of alternatives to SysML is the Arcadia/Capella approach. This approach and associated tool were developed with the support of the Thales company as an open source solution for systems modeling. The Arcadia method leaves room to understanding user needs. It defines an architecture among the stakeholders. Design decisions can be validated and justified to make integration and verification and validation (V&V) of the system easier [4]. The Arcadia method is organised in four successive engineering analysis and design steps with increasing levels of detail, distinguishing needs expression (perspectives 1 and 2) from solution expression (perspectives 3 and 4): 1) Operational Analysis: what the users of system need to accomplish, 2) System Analysis: what the system has to accomplish for the users, 3) Logical Analysis: how the system will work to fulfill expectations, and 4) Physical Analysis: how the system will be developed and built. In [4], the authors customize the Arcadia method to distinguish between System Analysis and Logical Analysis.
• Systems Analysis includes two tasks: 1) Stakeholders and interfaces identification states how the system interacts with the stakeholders. 2) Identification of internal functions to make it sure the system will implement these functions in the way it interacts with the stakeholders.
• Logical analysis defines the requirements to be applied to the sub-systems and components that will actually be built. Logical analysis is made up of three tasks: 1) Transformation of external functions into internal, less complex ones to specify how the functions of system will be implemented. 2) Allocation of international functions and their requirements to a reference architecture. 3) Elicitation of dynamic scenarios to check the design against operational scenarios and appreciate the exhaustiveness of that design. This includes verification of how existing functions and requirements do specify the behavior that is expected for the sub-systems of the system. Whereas the basic form of the Arcadia/Capella approach and associated tool offers an open-source solution for systems modeling and engineering, in practice, analyzing models and generating code often requires additional, not open-source, tools, such as for example for the joint use of Capella and Simulink [41].
The Arcadia/Capella approach and SysML are two competing approaches [14], but bridges between the two can be found [42].

4) AADL
AADL (Architecture and Analysis Description Language) [32] has been introduced for modeling and analysis VOLUME 10, 2022 of embedded, real-time systems, such as IMA (Integrated Modular Avionics) systems implemented in modern aircraft. AADL describes a system as an assembly of components that may be software, hardware or composite components (a component may itself be described by an assembly of components).
AADL allows one to describe complex architectures made up of software applications modeled in terms of ''processes'', themselves modeled in terms of tasks modeled by ''threads''. The applications produce and consume ''data''. They are allocated on hardware components such as ''processors'', ''devices'', ''bus'', and ''memory''.
AADL enables topological description of systems in terms of connection and allocation between components. Each component may be assigned a set of behavioral characteristics termed as ''properties.'' The interest of such modeling approach lies in the capacity to capture the concrete architecture of the system and to check it against against schedulability properties, correct transmission of messages and hardware dimensioning (e.g., memory capacity).

B. FORMAL LANGUAGES
The term ''formal methods'' denotes a family of languages, techniques and tools that rely on a strong mathematical background and permit application of proofs [43] when safety is an issue. Formal methods specifically apply to critical systems [44], and more particularly to life critical ones, such as transport systems [2], [45]. They also find application to systems that cannot be prototyped many times at reasonable cost, such as for example satellites.
Formal languages have a clearly defined syntax and a formalized semantics. The expected benefits of using formal methods include early detection of design errors in the life cycle of systems and software. It is possible to categorize formal methods depending on whether their application requires a posteriori validation of models, or not.
Formal methods such as Event-B [3], [46] require to build models through a succession of iterative refinements. Good properties satisfied at refinement (n) are by construction preserved at refinement (n+1). Event-B falls in the category of formal methods that implement a correct by construction paradigm.
A limited number of formal methods implement the correct by construction approach and its refinement techniques. A majority of formal methods require a posteriori validation. The model is built up and subsequently checked against a set of requirements and properties. The verification may lead to modify the model and check it again until the expected requirements and properties are satisfied.
Formal methods that require a posteriori validation may be categorized as follows: • Process algebra, such as CCS (Calculus of Communicating Systems [50]) and CSP (Communicating Sequential Processes [51]). Their native composition operator enables decomposition of complex systems or pieces of software into elementary bricks.
• Logics. Linear, temporal and deontic logics are examples of logics enabling formal specification of properties.
Among formal logics, Floyd-Hoare logics [52], [53] have been regularly used for the specification and verification of imperative programs. It gave birth to the concept of contractbased design [54]. This approach was recently been extended to formal specification of components [55], [56] and therefore used in a MBSE context.
Over the past decade, formal verification has increasingly been associated with model transformation, for instance, to generate analysis models, i.e. models that enable to analyze the system from one particular point of view or models that can be used on execution platforms [57], [58]. Inside the Coq proof assistant, CoqTL [59] is a Domain Specific Language (DSL) that specifies models and model transformations, the latter being formally proved.
The group of synchronous languages [60], [61] were introduced in early 1980s to answer needs to specify industrial command/controls systems. They rely on mathematical concepts enabling formal management of programs compilation. Time is handled in the form of a sequence of instants where each instant represents one execution of the system's reaction.
With the so-called ''synchronous hypothesis'', computations are carried out at dates that are abstracted by the designer inside one logical instant, as soon as these computations are completed before a next instant starts. Such an approach has been implemented by three families of languages: • Equation-based synchronous languages such as LUSTRE [62], LUCID-Synchrone [63] and PRELUDE [64].
• Graphic languages, such as SCADE [10] that is based on Lustre and primarily applies to critical software modeling.
The world of formal methods is not completely separate from the world of semi-formal languages. For example, UML grounds in both Statecharts and SDL. On the other hand, the concept of ''UML profile'' allows to enhance the expression power of UML and to formalize semantic variation points that exist in the OMG standard [33]. Examples of real-time UML profiles include TURTLE [37] that is supported by the free software TTool [38].

IV. TOOLS
MBSE tools offer various, complementary capabilities: models edition, checking of models against design errors using simulation and formal verification, automatic or semi automatic generation of executable code from models, and test generation from models.
Model editors can be implemented as far as the syntax of the modeling language is clearly expressed, for instance in the form of a meta-model (which is the case for UML [33]. Papyrus [66] is an example of free UML editor that implements the metamodel defined in [33].

A. SIMULATION AND FORMAL VERIFICATION
Model simulators combine user-guided and random explorations of models to support early debugging of the models and subsequent in-depth exploration of the state space of the same models. Whatever the style of modeling language, for instance an imperative style or a state/transition one, a simulator enables inspection of the model's components, activation of simulation progress (e.g., by transition firing), and display of the simulation coverage.
Formal verification relies on mathematics rather than ''by chance'' exploration. For instance, reachability analysis computes a reachability graph representing all the valid execution paths and states the system can take/reach starting from its initial state. The state explosion risk has regularly been cited as the major limitation of reachability analysis with as consequence making the reachability graph computation infeasible. An optimized state space exploration and hash-functionsbased implementation of the graph's states help reducing the risk of not completing the graph generation process [67].
Model checking generalizes application of exhaustive exploration of models state space. Fisman and Pnuelli define model checking as the method by which a desired behavioral property of a reactive system is verified over a given system (the model) through exhaustive enumeration (explicit or implicit) of all the states reachable by the system and the behaviors that traverse through them [68]. The model checker is catered with a model of the system and a formal expression of the properties to be verified. The model checker processes the model and the properties, and outputs a ''yes/no'' answer stating whether the property is verified or not. The model checker also traces execution paths that lead to property violations. The tool must indeed help the system designer with the interpretation of the verification results with respect to the system model.
Stochastic simulation has recently been getting attention within the framework of model verification. In [69], the authors apply stochastic simulation techniques, in particular the Monte Carlo method, to avionic control-command systems. This approach makes it possible to select the best action and the best node to visit in order to optimize a reward function. Since the approach relies on Monte Carlo simulation, the price of that efficiency is a loss of exhaustivity when compared to formal verification.

B. CODE GENERATION IN A MBSE CONTEXT
As far as MBSE is concerned, code generators accept a model as input, and output a code that may be either the entry of a formal verification tool or an executable code developed for a target processor. Example of tools offering both verification and code generation capabilities are as follows: • Matlab/Simulink Mathworks. Beyond its capabilities for simulating and tuning control-command laws for avionics systems, it also allows code generation targeting C/C++ for various hardware platforms, through the Embedded Coder plugin.
• SCADE [70] whose code generator is qualified with respect to the DO-178C standard that serves as reference to aeronautics industry. VOLUME 10, 2022 • Ocarina [71], which supports the AADL language [72]. Its code generator can generate C and ADA source code, the ADA output being specifically compatible with the SPARK-ADA suite [73] used for formal verification of code. Both verification-oriented and execution-oriented code generators need to be validated. Validation by testing is a tedious task since code generators are programs turning programs (or models) into other programs. Therefore, code generation processes need to include Verification and Validation activities. Depending on the criticality level required of the systems under development, V&V may constrain code generation. In practice, if the generated software artifacts (classes, procedures, files, etc.) need to be traced by these V&V activities, a reviewer can precisely relate these artifacts to the design choices made at the MBSE level. This deeply impacts the process of code generation by restraining applicable code optimizations, as elementary and otherwise pervasive as code inlining.
Instead of an extended code generation process with verification activities, a ''correct-by-design'' approach may be used to intertwin the development of the code generator and its correctness proof. The work on correct by construction code generators was pioneered by the development of Geneauto [74] for a subset of the Simulink language (Stateflow). Several phases of the Geneauto generator were proven correct by design [75], [76]. The current undisputed summit along this approach is the Velus code generator from Lustre to C [77], the resulting C code being semantically conform, by design, to the initial Lustre model.

C. TEST SEQUENCE GENERATION
Simulation and formal verification enable checking of models against design errors early in the life cycle of systems and contribute to reduce testing. Nevertheless, testing remains an important activity in system development. Test sequence generation has extensively been discussed in the literature [78], sometimes associated with model checking [79], [80].
Tests sequence generation first depends on the type of testing.
• Conformance testing tests whether an implementation conforms its specification or not.
• Given two or several implementations that passed conformance tests, Interoperability testing check whether these two implementations can interact, communicate and cooperate.
• Robustness testing tests the capacity for a system to meet certain properties in uncertain environment.
• Performance testing enables measuring response time of systems depending on the ways these systems are stimulated. Test sequence generation requires addressing the following issues: 1) Test executability. Finally, the capacity of testing a system heavily depends on design. Design for testability remains a key issue.

D. COMPARISON BETWEEN MBSE TOOLS
To conclude the survey of MBSE tools, this sub-section compares MBSE tools and distinguishes between SysML tools (Table 3) and tools developed for modeling languages other than SysML (Table 4).

V. METHODS
The languages and tools identified by previous sections need to be associated with a method. This section categorizes methods and focuses discussion in particular on methods associated with SysML.

A. CATEGORIES OF METHODS
A survey of the literature indicates that methods can be categorized as follows.
• A method compliant with a standard from the aeronautical world (such as for example ARP 4754A [85] a standard discussed in [86]).
• A method associated with a specific modeling tool (such as for example [6] that associates SysML and the free software TTool [38] with a method that applies to a broad variety of real-time systems).
• A method M1 integrated to another method M2 that was not developed for implementing a MBSE approach (such as for example [87]

B. A METHOD ASSOCIATED WITH SysML AND TTool
In [88] a method associated with SysML and TTool can be sketched as follows (see also Figure 5, which depicts the method in the form of a SysML activity diagram): • Requirement capture.
• Expression of modeling assumptions stating how the SysML model simplifies reality.
• Use case driven analysis identifies the main functions to be offered by the system. Use cases are documented by scenarios and flow charts.
• Design both in terms of architecture and behaviors of the blocks the architecture is made up of.
• Simulation and formal verification for checking the SysML model against design errors and compliance to requirements. Figure 6 addresses the design step of the method shown by Figure 5 and focuses on incremental modeling of the architecture along with the behaviors associated with the blocks the architecture is made up of. Incremental modeling is a key enabler to managing complex systems, such as for example UAVs (Unmanned Aeronautical Vehicles) in unknown or partially known environments. One starts from a model that highly simplifies the real system and step by step alleviates restrictions (and takes new requirements into account) to come up with a model that eventually gets sufficiently close VOLUME 10, 2022 to the real system. When a (n-1) version of the model is upgraded to next version, non-regression tests are required to check whether the properties holding at (n-1) step still hold at step (n).
For each version of the model, it is recommended to use simulation and formal verification following the 3-step process sketched below: 1) The model is debugged using a simulator. 2) Core mechanisms are exhaustively analyzed relying on formal verification techniques. For example, considering a local area network managed by a tokenbased policy, a core mechanism to be verified would be: unicity of the token that grants permission to send frames on the network. 3) Intensive simulation on a model that integrates the previously verified core mechanisms and add features that make the model closer to the real system, but do not need or cannot be verified (e.g., because of the state explosion problem).
The method discussed so far highlights the importance of simulation and formal verification for checking design errors early in the life cycle of systems. Simulation and formal verification apply to the architecture and behaviors elaborated during the design step. How to populate the architectural and behavioral design diagrams is therefore a key issue. An avenue to explore relies on joint use of MBSE and MDAO (Multi-disciplinary Analysis and Optimization) approaches [40]. In parallel to requirements and use cases elicitation, it is possible to carry out engineering analysis techniques that will guide design decisions in terms of architecture [89] or drone battery optimization [25]. As usual, managing multi-domain models rises up coherence problems [90].

VI. RESEARCH DIRECTIONS A. LANGUAGES
In order to enhance MBSE processes, a first natural step is to enhance the descriptive power of the input language so that systems designers can model their problems with more details and higher fidelity. But language and method designers must not paint themselves into a corner by simply piling up features on top of features, resulting in a bloated and to a large extent unmanageable and unfathomable language, from users and designers' perspectives altogether. This would end up reproducing the fate of the so-called 'pivot' languages. While we acknowledge the importance of adding features to keep up with users needs, we also strongly advocate an evolution of MBSE languages towards more abstract and specification-oriented ways of modeling.
In our opinion, the kind of evolution we promote is tightly coupled with the ability of MBSE tools to support it and fill in the gap between a more high-level description and the low-level details of an executable (or at least simulable) target. We discuss this point in Section VI-B. Concretely speaking, this evolution could address the several following points: • In terms of expressive power, we may add the possibility to specify: -Deadline, periodicity, and WCET as examples of real-time constraints.
-Complex synchronization or concurrent structures, and suspend/resume mechanisms. -Various features of communication protocols between components such as FIFO, causal, buffered, diffusion versus point-to-point, maximum delays, and data freshness.
• To steer away from early concerns about how data is stored and where it is located, that may lead to over-commitment to not so carefully informed choices, we encourage the primary use of event-oriented descriptions, as can be found in use-case or sequence diagrams. Synthesis of class diagrams from the latter has already been experimented [91] and much effort has to be put in that direction.

B. ELABORATING MODELS
In terms of model developers assistance, elaboration of models is also an issue. Elaboration of models is a complex intellectual process. Feedback from industry practitioners and MBSE lecturers suggests that developers of SysML models often stumble on the same problem: thinking about the system before modeling it, e.g., in SysML. Solutions may be found using mind maps [92]. With their graphic form and rather flexible way of organizing ideas, mind maps turn out to be a good candidate to help thinking about the system. Other avenues may be explored with the support of ontologies [93]. Also, in the never-ending journey of integrating more aspects into modeling languages, a substantial effort must be devoted to prevent users' attention getting clogged by VOLUME 10, 2022 irrelevant parts or features of a model. It involves efficient pruning or masking techniques implemented in model editing tools to help users focus on interesting parts.
When the evolution of MBSE languages enables them to take more specification into account, i.e. such an evolution enables a more declarative style of modeling, tools will need to somehow propose automated synthesis of an executable refined model, to explore feasibility or even deal with optimization concerns as regards model complexity, memory footprint, communication delays, contention, etc. Some of these abilities may already exist in research prototypes and tools still not mature enough to handle industrial use cases. MBSE tools must exploit to the users' advantage the degree of freedom provided by rich but abstract models.
Finally, an interesting direction would be to try to reproduce the achievements of machine-learning tools that help completing user provided code sketches, such as Microsoft's Codepilot. At the model level, a tool that helps users completing partial descriptions, based on a library of MBSE projects with similar requirements and objectives, would be a great asset in MBSE activities. It has to be explored whether such a library could in principle exist and how an AI tool exploiting this library may be devised.

C. DOCUMENTING MODELS
Looking at sharing models, concurrent approaches, etc., an important issue with models may be phrased as follows: ''When sharing a model with another person, how long does the latter need to understand the main features of the system described by the model?'' (or as far as teaching is concerned, how long does a professor need to understand the models created by his or her students or trainees?) Answering these questions clearly raises a model documentation problem. Investigations are needed to come up with document templates for one or several modeling language.

D. FORMAL VERIFICATION TOOLS
Formal verification of models can be seen on two points of view: the properties to be verified and the verification engine.
Expressing the properties to be verified by a system remains a key issue in formal verification. Efforts have to be done to optimize formal verification, for instance by relying on dependency graphs [94] that contribute to reduce the state space to explore when checking a model against one or several properties. It is also important to keep in mind that systems may be checked not only against safety properties but against securities properties as well.
In terms of verification engine, it is worth being noticed that the verification tools surveyed by the current paper powerfully address the control part of the system. The surveyed verification tools offer little opportunities to verify the data part of the system. As an example, let us consider a communication system modeled in SysML. SysML verification tools offer nice features for verifying the temporal ordering of exchanged messages, as well as temporal constraints satisfaction. By contrast, they do not offer any facilities for verifying the semantics or the consistency of the data conveyed by the messages.
Finally, a powerful verification tool is not useful and will be soon left aside by potential users if it is not granted with great abilities to explain verification outcomes. It first requires producing a verification diagnosis in terms of model components, events and user data, not in terms of the verification tool internal representation. This problem occurs quite often since many verification activities begin by translating a model and its specification into a foreign verification language dedicated to a specific tool. Then, the valuable information computed must be carried back to the original model, which can be a tedious task in the absence of any guarantee on the translation. To alleviate this task, it is worthwhile to provide a reference formal semantics of the modeling language, a kind of lingua franca, which users and verification tools alike must adhere to. This reference semantics also serves as a basis to obtain a trustworthy simulation engine or code generator.
A fine way to present such complex verification results is to couple them with interactive graphical simulation abilities and additionally to allow model pruning and masking to get rid of irrelevant details. Also, in order to cope with limitations of such tools, it is important to exchange information about the model under scrutiny between verification tools, test suite generation and execution tools.

E. METHODOLOGICAL ASSISTANTS
Adoption of MBSE has been hampered by the lack of mature and high quality tools [13]. Examples of issues include scalability and assistance in applying methods. Recent papers have confirmed the interest of methodological assistants [95], [96], [97] as a complement to model editors, simulators, formal verification tools, code generators, and test sequence generators. The authors of the current paper support the idea of improving methodological assistants relying on Artificial Intelligence techniques, in particular Case Based Reasoning based on libraries of models.
Among many ways of assisting model designers, giving an assessment on the quality of models is an issue. Let us, e.g., consider what happens with SysML tools. Simulation tools enable debugging of activity and state machines diagrams, and help systems designers improving their models. By contrast, the same SysML tools merely offer editing capabilities for requirement and use case diagrams. We may need tools that evaluate the complexity of the diagrams and come up with recommendations in terms of model sharing and teamworking. Complexity may be evaluated using metrics, possibly in connection with guidelines. Complexity may also been evaluated by analyzing dependencies between several elements in a diagram or between the many diagrams a model is made up of.
The quality of models further depends on the various 'facets' of the system that are addressed by the model. For instance, all systems are subject to failures and their users make inadvertent and intentional errors. A method associated with a language and its support tools should therefore encourage systems designers to not limit their models to nominal behaviors but to systematically include degraded situations and human errors made by end users or maintenance crews.

F. ENSURING SEAMLESS CONNECTION FROM GENERALISED MBSE TOOLS TO SPECIALISED REAL-TIME SYSTEMS ANALYSIS TOOLS
Whilst the introduction of model-based systems engineering, addressing managing systems complexity and reducing the uncertainty associated with the design process, in industry can present interesting results, their actual use, taking full advantages of all possibilities of verification and validation, code generation, etc. is taking still some time [98]. There is a need for new approaches that ''support systems that allow the information and data associated with products to be developed and sustained through the product life-cycle''. This shift in development processes focus utilizes a more complex series of interfaces and necessitates a shift from previous dominant document-based approaches for the facilitation of communication, management of development risks, quality, process, and business productivity, as well as knowledge transfer.
One of the reasons leading to this situation lies in the difficulties to properly connect different tools between each other. Indeed, when transforming one model into another, the question arises on: • How to ensure that eventual changes in the ''other'' model can be fed back to the original model • Where to store eventual additional information that was maybe not necessary for the original model, but critical to the new model • How to keep it all coherent and consistent. In addition, if for each model a developer needs to start from scratch on the development of a model, for a given system development a lot of time and effort is devoted to each of the models, potentially on different tools, with as risk a loss of coherence between the tools and a loss of motivation for the developers. Whereas the potential advantages are clearly defined (amongst others by [16]), and include enhanced communications, reduced development risks, improved quality, increased productivity, and enhanced knowledge transfer, it remains difficult to get the use of different tools accepted with at each time starting from scratch, which makes the topic of seamless connection of tools an important one.
When looking at guaranteeing response times, different analysis approaches exist and have been mentioned in this paper. The proper connection of model-based systems engineering tools to such analysis tools is a focus point. Temporal constraints for specific (embedded) systems are often already known in the earliest stages of the design, but can become more apparent during subsequent design phases. In order to guarantee a seamless work over the stages, good information passing between the different phases and different tools is necessary. A particular focus in this respect concerns the analysis of asynchronously functioning systems, particular case that includes amongst others air traffic control, control of drone systems, complex vehicle control, etc.

VII. CONCLUSION
Model Based Systems Engineering has been largely discussed in the literature in the form of theory, practical feedback and surveys, and focuses on languages, tools, and methods.
Work on MBSE was pioneered in the context of UML (and other related approaches such as OMT before) and extended on subjects as various as meta-modeling, model transformation, and model management. The development of real-time UML profiles has stimulated research work on bridging the gap between graphic, semi-formal modeling languages and formal methods. Avenues have thus been opened for reuse of formal verification techniques and code generators initially developed for formal methods.
MBSE can be seen on three points of view: languages, tools and methods. Over the past three decades, much work has been published on modeling languages and tools, looking for the best languages and the more efficient or user-friendly tools. With the advent of semi-formal modeling languages standardized on consensus (e.g., SysML) and with the variety of formal methods for application domains that need them, mature tools have been developed. In this paper, it is claimed that method remains an issue that remains insufficiently addressed by tools, with the notable exception of the Arcadia/Capella approach.
Many issues remain to be explored in terms of languages, tools and methods to promote transitioning to MBSE in industry. In terms of language, extension mechanisms of SysML and tools such as Papyrus [66] enable definitions of modeling languages with enhanced expression power. These languages usually enable expression of safety properties and rarely offer constructs to express liveness properties.
Engineers and students need to think about the system before creating a model. Developing a system, be it a product, a service, or an organisation, passes several life cycle phases. The first stage in a system's life cycle, the concept stage, focuses on understanding the implications of a system's mission and core functionality. In [92] it is argued that mind maps may be the support of this first step, a step to be carried before creating a SysML of the system under design. Mind maps offer a support to orient thinking about the system before selecting one or several modeling languages.
The previous section has outlined directions for future research on MBSE. In the context of the current, final conclusions we further underline the need to make and keep MBSE open to and interacting with other modeling paradigms. Solutions to improving MBSE in terms of languages, tools and methods are to be looked for outside the MBSE community. For instance, by associating MBSE and MBSA [24] and by bridging the gap between the MBSE and MDAO communities [25].
Last but not least, the authors of the current paper point out the importance of education for the success of MBSE adoption. Efforts may be guided towards the following directions.
Of prime importance is the development of a body of knowledge to include MBSE in SE programs. Students and practitioners need to be trained to develop critical thinking about the model developed by themselves and by others. The same students and practitioners need to bee offered coaching programs to accompany them through their professional life at various steps accounting on their experience in implementing MBSE on real-size examples.
The concern is not only on the course content but the way of teaching it. Over the past two decades, a rich collection of slide-based supports have been developed and partly made publicly available. It is commonplace to say that not everything can be explained relying exclusively on slides and white papers. Video supports need to be developed, in particular in the form of short videos often termed as 'capsules'. For instance, students and practitioners need to clearly define the boundary of the system to be modeled; for instance, to decide whether modelling an entire system or solely its software controller.