Member, IEEE Pierre De Saqui-Sann

Member, IEEE Rob A Vingerhoeds

Christophe Garion

Xavier Thirioux

A Taxonomy of MBSE Approaches by Languages, Tools and Methods

Keywords: MBSE, formal methods, method, modeling tools, safety-critical systems, SysML, systems engineering

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 [START_REF] Chami | A survey on MBSE adoption challenges[END_REF]. With no intent to be exhaustive, application domains of MBSE include railway [START_REF] Ter Beenk | Formal methods for transport systems[END_REF], [START_REF] Fotso | A formal requirements modeling approach: Application to rail communication[END_REF], nuclear plants [START_REF] Navas | Bridging the gap between model-based systems engineering methodologies and their effective practice-A case study on nuclear power plants systems engineering[END_REF], aircraft operability [START_REF] Manikar | A formal framework for modeling and prediction of aircraft operability using SysML[END_REF], drones [START_REF] Apvrille | An educational case study of using SysML and TTool for unmanned aerial vehicles design[END_REF], and lunar exploration [START_REF] Rimani | MBSE approach applied to lunar surface exploration elements[END_REF].

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 [START_REF] Chami | A survey on MBSE adoption challenges[END_REF], [START_REF] Apvrille | An educational case study of using SysML and TTool for unmanned aerial vehicles design[END_REF], [START_REF] Selic | Modeling and Analysis of Real-Time and Embedded Systems With UML and MARTE[END_REF], [START_REF] Reilley | Model-based systems engineering: An emerging approach for modern systems[END_REF], [START_REF] Sergent | Benefits of model based system engineering for avionics systems[END_REF], [START_REF] Baduel | SysML models verification and validation in an industrial context: Challenges and experimentation[END_REF], [START_REF] Wolny | Thirteen years of SysML: A systematic mapping study[END_REF], [START_REF] Bucchiarone | Grand challenges in model-driven engineering: An analysis of the state of the research[END_REF], and less frequently mitigate these benefits [START_REF] Bonnet | Not (strictly) relying on SysML for MBSE: Language, tooling and development perspectives: The arcadia/capella rationale[END_REF], [START_REF] Gregory | The long and winding road: MBSE adoption for functional avionics of spacecraft[END_REF], [START_REF] Henderson | Value and benefits of model-based systems engineering (MBSE): Evidence from the literature[END_REF], [START_REF] Wu | Maturity assessment of systems engineering reusable assets to facilitate MBSE adoption[END_REF], [START_REF] Di Maio | Evaluating MBSE methodologies using the FEMMP framework[END_REF]. 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 [START_REF]Systems Modeling Language[END_REF], 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 [START_REF] Apvrille | An educational case study of using SysML and TTool for unmanned aerial vehicles design[END_REF], [START_REF] Baduel | SysML models verification and validation in an industrial context: Challenges and experimentation[END_REF] 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 [START_REF] Monteiro | A taxonomy for model-based systems engineering[END_REF] 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 [START_REF] Monteiro | A taxonomy for model-based systems engineering[END_REF] 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 [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] 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 [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] 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 [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] 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 [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] does, and addresses them in more technical terms, for instance when the current paper categorizes verification tools and code generators. In terms of methods, [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] focuses discussion on pattern-based, template-driven and feedbackenabled approaches. Finally [START_REF] Madni | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF] 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 [START_REF] Basnet | A decision-making framework for selecting an MBSE language-A case study to ship pilotage[END_REF] 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 [START_REF] Basnet | A decision-making framework for selecting an MBSE language-A case study to ship pilotage[END_REF] 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, [START_REF] Basnet | A decision-making framework for selecting an MBSE language-A case study to ship pilotage[END_REF] 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 [START_REF] Khandoker | Towards a logical framework for ideal MBSE tool selection based on discipline specific requirements[END_REF] 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, [START_REF] Khandoker | Towards a logical framework for ideal MBSE tool selection based on discipline specific requirements[END_REF] 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 [START_REF] Nguyen | A study on SysML and AltaRica models transformation[END_REF] and MDAO [START_REF] Aïello | Sizing a drone battery by coupling MBSE and MDAO[END_REF].

In [START_REF] Akundi | Perceptions and the extent of model-based systems engineering (MBSE) use-An industry survey[END_REF] Akundi, Ankobiah, Mondragon and Luna convey an industry point of view of what MBSE is and discusses MBSE adoption challenges. The approach developed in [START_REF] Akundi | Perceptions and the extent of model-based systems engineering (MBSE) use-An industry survey[END_REF] is complementary to the one in the current paper in the sense that [START_REF] Akundi | Perceptions and the extent of model-based systems engineering (MBSE) use-An industry survey[END_REF] 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 [START_REF] Church | Carnap's introduction to semantics[END_REF], 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 [START_REF][END_REF];

• Mathworks languages (Matlab, Simulink, Stateflow et Simscape) [START_REF]Matworks. Mathworks-Languages[END_REF] originally developed for control systems modeling, but increasingly used for systems development;

• Modelica, dedicated to mechatronic systems [START_REF]Modelica Association[END_REF];

• AADL (Architecture and Analysis Description Language) [START_REF] Mkaouar | A formal approach to AADL model-based software engineering[END_REF], dedicated to embedded architectures description;

• UML [START_REF]Unified Modeling Language Version 2[END_REF] and its related languages such as SysML [START_REF]Systems Modeling Language[END_REF], widely applicable modeling languages used in SW and Systems Engineering;

• OPM Object Process Methodology [START_REF] Li | Modelbased systems engineering for aircraft design with dynamic landing constraints using object-process methodology[END_REF], 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 [START_REF]Unified Modeling Language Version 2[END_REF]) 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 [START_REF] Gherbi | UML profiles for real-time systems and their applications[END_REF]. 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 [START_REF] Zhang | Behavior modeling on ARINC 653 to support thee temporal verification of conformed application design[END_REF]. Another example is TURTLE [START_REF] Apvrille | TURTLE: A real-time UML profile supported by a formal validation toolkit[END_REF], 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 [START_REF]OMG. SysML v2[END_REF], 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 [START_REF] Chaudemar | MBSE and MDAO for early validation of design decisions: A bibliography survey[END_REF].

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 [START_REF] Navas | Bridging the gap between model-based systems engineering methodologies and their effective practice-A case study on nuclear power plants systems engineering[END_REF]. 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 [START_REF] Navas | Bridging the gap between model-based systems engineering methodologies and their effective practice-A case study on nuclear power plants systems engineering[END_REF], 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 [START_REF] Duhil | Chaining model transformations for system model verification: Application to verify capella model with simulink[END_REF].

The Arcadia/Capella approach and SysML are two competing approaches [START_REF] Bonnet | Not (strictly) relying on SysML for MBSE: Language, tooling and development perspectives: The arcadia/capella rationale[END_REF], but bridges between the two can be found [START_REF] Badache | Capella to SysML bridge: A tooled-up methodology for MBSE interoperability[END_REF].

4) AADL

AADL (Architecture and Analysis Description Language) [START_REF] Mkaouar | A formal approach to AADL model-based software engineering[END_REF] 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 [START_REF] Clarke | Formal methods: State of the art and future directions[END_REF] when safety is an issue. Formal methods specifically apply to critical systems [START_REF] Nanda | A survey of formal specification application to safety critical systems[END_REF], and more particularly to life critical ones, such as transport systems [START_REF] Ter Beenk | Formal methods for transport systems[END_REF], [START_REF] Ferrari | Systematic evaluation and usability analysis of formal methods tools for railway signaling system design[END_REF]. 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 [START_REF] Fotso | A formal requirements modeling approach: Application to rail communication[END_REF], [START_REF]Modeling in Event-B: System and Software Engineering[END_REF] 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:

• Models relying on a state/transitions paradigm. Examples include Extended Finite State Machines, Petri nets [START_REF][END_REF], timed automata [48] and Q-models [START_REF] Motus | Timing Analysis of Real-Time Software[END_REF].

• Process algebra, such as CCS (Calculus of Communicating Systems [START_REF] Milner | Communication and Concurrency[END_REF]) and CSP (Communicating Sequential Processes [START_REF] Hoare | Communicating Sequential Processes[END_REF]). 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 [START_REF] Hoare | An axiomatic basis for computer programming[END_REF], [START_REF] Floyd | Assigning meanings to programs[END_REF] have been regularly used for the specification and verification of imperative programs. It gave birth to the concept of contractbased design [START_REF] Meyer | Applying 'design by contract[END_REF]. This approach was recently been extended to formal specification of components [START_REF] Benveniste | Multi-mode DAE models-challenges, theory and implementation[END_REF], [START_REF] Benveniste | Contracts for systems design: Theory[END_REF] 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 [START_REF] Calegari | Verification of model transformations: A survey of the state-of-the-art[END_REF], [START_REF] Amrani | Formal verification techniques for model transformations: A tridimensional classification[END_REF]. Inside the Coq proof assistant, CoqTL [START_REF] Tisi | CoqTL: An internal DSL for model transformation in COQ[END_REF] is a Domain Specific Language (DSL) that specifies models and model transformations, the latter being formally proved.

The group of synchronous languages [START_REF] Benveniste | The synchronous languages 12 years later[END_REF], [START_REF] André | Comparing programming styles in synchronous languages[END_REF] 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 [START_REF] Halbwachs | Generating efficient code from data-flow programs[END_REF], LUCID-Synchrone [START_REF] Pouzet | Lucid synchrone, version 3. Tutorial and reference manual[END_REF] and PRELUDE [START_REF] Forget | A synchronous language for critical embedded systems with multiple real-time constraints[END_REF].

• Imperative synchronous languages, such as ESTEREL [START_REF] Boussinot | The ESTEREL language[END_REF].

• Graphic languages, such as SCADE [START_REF] Sergent | Benefits of model based system engineering for avionics systems[END_REF] 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 [START_REF]Unified Modeling Language Version 2[END_REF]. Examples of real-time UML profiles include TURTLE [START_REF] Apvrille | TURTLE: A real-time UML profile supported by a formal validation toolkit[END_REF] 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 [START_REF]Unified Modeling Language Version 2[END_REF]. Papyrus [START_REF] Theobald | About DSML design based on standard and open-source-REX from SAFRAN tech work using Papyrus-SysML[END_REF] is an example of free UML editor that implements the metamodel defined in [START_REF]Unified Modeling Language Version 2[END_REF].

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 [START_REF] Holzmann | The model checker spin[END_REF].

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 [START_REF] Fisman | Beyond regular model checking[END_REF]. 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 [START_REF] Delmas | An evaluation of Monte-Carlo tree search for property falsification on hybrid flight control laws[END_REF], 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 [START_REF] Sergent | SCADE: A comprehensive framework for critical system and software engineering[END_REF] whose code generator is qualified with respect to the DO-178C standard that serves as reference to aeronautics industry.

VOLUME 10, 2022

• Ocarina [START_REF] Hugues | Leveraging Ada 2012 and SPARK 2014 for assessing generated code from AADL models[END_REF], which supports the AADL language [START_REF] Feiler | The SAE avionics architecture description language (AADL) standard: A basis for model-based architecture-driven embedded systems engineering[END_REF]. Its code generator can generate C and ADA source code, the ADA output being specifically compatible with the SPARK-ADA suite [START_REF] Brosgol | Tutorial: A practical introduction to formal development and verification of high-assurance software with SPARK[END_REF] 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 [START_REF] Toom | Gene-auto: An automatic code generator for a safe subset of simulink/stateflow and Scicos[END_REF] for a subset of the Simulink language (Stateflow). Several phases of the Geneauto generator were proven correct by design [START_REF] Izerrouken | Certifying an automated code generator using formal tools: Preliminary experiments in the geneauto project[END_REF], [START_REF] Izerrouken | Use of formal methods for building qualified code generator for safer automotive systems[END_REF]. The current undisputed summit along this approach is the Velus code generator from Lustre to C [START_REF] Bourke | Mechanized semantics and verified compilation for a dataflow synchronous language with reset[END_REF], 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 [START_REF] Dssouli | Testing the control-flow, data-flow, and time aspects of communication systems: A survey[END_REF], sometimes associated with model checking [START_REF] Villani | Integrating model checking and model based testing for industrial software development[END_REF], [START_REF] Elkholy | Model checking intelligent avionics systems for test cases generation using multi-agent systems[END_REF].

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. 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 systems engineering standard (such as for example ANSI EIA632 [START_REF]EEIA632-Process for Engineering a System[END_REF], IEEE 1220 [START_REF]IEEE Standard for Application and Management of the Systems Engineering Process[END_REF] and IEC 15288 [START_REF]Ingénierie des Systèmes et du Logiciel-Processus du Cycle de vie du Système[END_REF]).

• A method compliant with a standard from the aeronautical world (such as for example ARP 4754A [START_REF]ARP4754A: Guidelines for Development of Civil Aircraft and Systems[END_REF] a standard discussed in [START_REF] Zhu | A formal approach using SysML for capturing functional requirements in avionics domain[END_REF]).

• A method associated with a specific modeling tool (such as for example [START_REF] Apvrille | An educational case study of using SysML and TTool for unmanned aerial vehicles design[END_REF] 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 [START_REF] De Souza | Combining STPA with SysML modeling[END_REF] that integrates SysML and the free software TTool into the STPA method (STPA was developed by MIT and stands for Systems Theoretic Process Analysis), or Formose, a French project where SysML is associated with KAOS [START_REF] Fotso | A formal requirements modeling approach: Application to rail communication[END_REF]).

B. A METHOD ASSOCIATED WITH SysML AND TTool

In [START_REF] De Saqui-Sannes | Checking SysML models against safety and security properties[END_REF] 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

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 [START_REF] Chaudemar | MBSE and MDAO for early validation of design decisions: A bibliography survey[END_REF]. 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 [START_REF] Leserf | Trade-off analysis for SysML models using decision points and CSPs[END_REF] or drone battery optimization [START_REF] Aïello | Sizing a drone battery by coupling MBSE and MDAO[END_REF]. As usual, managing multi-domain models rises up coherence problems [START_REF] Missaoui | Verification and validation of the consistency between multi-domain system models[END_REF].

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 [START_REF] Apvrille | Real-time UML synthesis from sequence diagrams[END_REF] 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 [START_REF] De Saqui-Sannes | Mind maps upstream SysML v2 diagrams[END_REF]. 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 [START_REF] Gray | On the relationship between models and ontologies[END_REF]. 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 [START_REF] Apvrille | SysML models verification relying on dependency graphs[END_REF] 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 [START_REF] Bucchiarone | Grand challenges in model-driven engineering: An analysis of the state of the research[END_REF]. Examples of issues include scalability and assistance in applying methods. Recent papers have confirmed the interest of methodological assistants [START_REF] Aquino | A methodological assistant for use case diagrams[END_REF], [START_REF] Mussbacher | Opportunities in intelligent modeling assistance[END_REF], [START_REF] Savary-Leblanc | A modeling assistant for cognifying MBSE tools[END_REF] 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 VOLUME 10, 2022 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 [START_REF] Detlef | MBSE-PLM integration: Initiatives and future outlook[END_REF]. 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 [START_REF] Henderson | Value and benefits of model-based systems engineering (MBSE): Evidence from the literature[END_REF]), 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 [START_REF] Theobald | About DSML design based on standard and open-source-REX from SAFRAN tech work using Papyrus-SysML[END_REF] 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 [START_REF] De Saqui-Sannes | Mind maps upstream SysML v2 diagrams[END_REF] 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 [START_REF] Nguyen | A study on SysML and AltaRica models transformation[END_REF] and by bridging the gap between the MBSE and MDAO communities [START_REF] Aïello | Sizing a drone battery by coupling MBSE and MDAO[END_REF]. VOLUME 10, 2022 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.

VOLUME 10, 2022 FIGURE 1 .

 20221 FIGURE 1. Modeling languages.

FIGURE 2 .

 2 FIGURE 2. Categorisation of MBSE Tools.

FIGURE 3 .

 3 FIGURE 3. MBSE tools for SysML modeling language.

FIGURE 4 .

 4 FIGURE 4. MBSE tools for modeling languages other than SysML.

VOLUME 10, 2022 FIGURE 5 .

 20225 FIGURE 5. SysML activity diagram depicting the method associated with SysML and TTool.

FIGURE 6 .

 6 FIGURE 6. Incremental modeling.

  Fault model. The model must characterize all the faults one expects to meet at the time of testing the system.

			test case must be satisfied by the variables used in the
			test case.
			2) Examples of faults include output, transfer and tempo-
			ral faults [80].
			3) Test fault coverage. The capacity to detect faults on
			implementations is an important criterion for com-
			paring test generation techniques that share one fault
			model in common.
			4) Conformance relation. It makes sense to conformance
			testing and requires a common, formal, modeling lan-
			guage to represent the system and the implementation.
			As far as networked systems are concerned, test sequence
			generation may refer to IS 9646 standard to use Point of
			Control and Observation. TTCN (Testing and Test Control
			Notation [81]) enables test sequence expression, especially
			for networked systems.
	• 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. Given a state/transition model, the
	constraints associated to the transitions traversed by a

Pierre de Saqui-Sannes (pdssThis work was supported by the Defense Innovation Agency (AID) of the French Ministry of Defense through the Research Project CONCORDE under Grant 2019 65 0090004707501.


Phonographic Encounters is a welcome contribution to the growing field of recorded sound history. Since the early 2000s, alternative narratives to the top-down and linear accounts of inventors and major phonographic companies, and the conception of recording as a sociotechnical practice rather than a transparent technology (a mere 'inscription' of sound), have gained in importance. By bringing together contributions from historians, musicologists and cultural and media theorists, this opus furthers the deconstruction of diffusionist, essentialist and Western-centric narratives, and frames a study programme attentive to materialities, 'ordinary' agents, margins, transfers, negotiations, improvisations and diversions. This process highlights entanglements between technologies and social, political, economic and legal issues.

The book is deployed in four parts, respectively devoted to the agents and spaces of production, listening practices and their aesthetics, ideologies involved in the uses of recorded sound, and to the social geography of consumption.

The contributions in Part 1 highlight practices and the roles of agents overlooked by mainstream history. They focus on how the temporal and spatial trajectories of these agents, as well as their cultural representations and social interactions, shaped early recordings and the organisation of the phonographic industry. Sergio Ospina Romero's contribution on the scouts sent by Victor and Columbia to make 'ethnic' or 'foreign' recordings fascinatingly reverses the usual narrative, insisting on improvisation and negotiation at the heart of an activity that had to perform the convergence of Western cultural representations, technical and commercial requirements, and practices and dispositions that did not fit in with the planned arrangements. Multiple externalities (linguistic, social, material) dynamically shaped the categories and the very organisation of the phonographic market. More focused on the symbolic aspects of the interactions between settlers and colonised, Henry Reese's contribution, entitled 'Settler colonial soundscapes: phonograph demonstrations in 1890s Australia', offers a compelling analysis of how sounds recorded and offered for public listening by transnational agents of the phonographic industry contributed to a sense of 'British' community: a sound perceived as 'one's own' (e.g. bells, political speeches in English), shared by peers, which muted indigenous sounds and voices, and redefined the local through the categories of modernity, urbanity, mobility and entertainment culture.

The second part examines 'how the circulation of imported phonographic commodities challenged or altered auditory and performance practices in selected regional and national contexts, but also in new spaces (such as the domestic or intimate environments of the house and the private listening club) and countries which have generally been marginalised (Portugal, Spain and Sweden)' (p. 8). Thematically and methodically less original, this section would have been strengthened by being put into perspective with previous publications, in order to compare those national specificities, circulations and adaptations of practices and cultural referents.

The third part focuses on the discourses surrounding phonography in order to understand their place in the ideological issues of the twentieth century. Benedetta Zucconi's article exposes the opposition between two groups of agents in 1930s Italy: Crocian-inspired neo-idealistscomposers, music critics and intellectuals -who considered phonography incompatible with art because of its 'mechanical' and industrial dimension, and the community of jurists who, around the issue of copyright (and hence through their attention to the intervention not only of performers, but also of sound engineers), contributed to the recognition of its 'medial nature ' (p. 165). While this analysis of lawyers' contribution to the structuring of phonography is interesting, one is less convinced by the argument of the specifically Italian character of this phenomenon. Indeed, similar controversies existed in neighbouring countries, where distrust for 'mechanical music' and 'mass culture' was countered by the valorisation of the latter as 'art' (discographic criticism, prizes) [START_REF] Maisonneuve | L'invention du disque[END_REF]. Thus, placing this analysis in a transnational framework would allow the author to nuance her statements and further contribute to the deconstruction of mainstream historiographic categories announced in the introduction. Britta Lange's contribution on 'The construction of "das Volk" through acoustic knowledge. Recordings of "ethnic German repatriates" from the Institute for Acoustic Research, 1940Research, -1941' ' is also very interesting. The author convincingly brings to light the interweaving of science and politics in the context of the Nazi state, both through the political instrumentalisation of science to legitimise the Lebensraum project, and through the scientists' use of the political context to obtain grants and escape conscription. Thus, Lange highlights how the recording activity forges sonic evidence of the Germanness of a dispersed people, supporting their integration into an expansionist empire. This effective and rich demonstration would, however, have benefited from being embedded in the older history of the relationship between music and nationalism [START_REF] Bohlman | The Music of European Nationalism: Cultural Identity and Modern History (Santa Barbara, ABC-Clio)[END_REF]).

Finally, the fourth part focuses on the places and spaces of music purchase, and on the often marginalised traders and consumers who contribute to creating a new culture (see the excellent contribution by J. Martin Vest on the shop windows of The Victor Talking Machine Company). Through his analysis of the networks of the Italian opera recording trade in Philadelphia's Little Italy of the 1900s-1920s, Siel Agugliaro highlights the polycentric and reticular character of a transnational phonographic market, undergirded by issues of legitimacy, solidarity and visibility, far from the smooth and linear narratives of the dominant historiography: negotiation, hybridization and margins are core to the development of multiple markets, at once singular and global. This attention to marginal and little visible practices is further embodied in the inclusion of hitherto little-exploited corpora: oral testimonies, paraphernalia, often discarded because they are not indexed or systematically preserved by institutions. This reveals the singular research of passionate collectors like Thomas Henry, who have built their corpus over several years and called on fan communities. In this respect, it is worth stressing the consistency of this editorial project and its polycentric historiography, making space for non-institutionalized and new corpora, also welcoming authors on the margins of the academy. Overall then, this book not only historicizes 'the record' as a commodity distributed and consumed, but also as a complex object that is constantly invented, used, discussed and brought to life.

Original and ambitious, rich in its diversity of perspectives and objects, this edited volume constitutes an undeniable contribution to the historiography of recorded sound. However, given the global ambition of this industry, more dialogue with previous works could provide information on the national or local specificities of certain developments as well as on their links with other territories and situations. Such perspectives would also point out the resistance to such dynamics, and the scales of circulation, transformation and negotiation that brought together ideas, objects, agents and practices in the early years of sound recording. One may also regret the sometimes list-like effect of certain fashionable concepts such as intersectionality, empire, colonialism, gender, multimediality or mobility, which appear more programmatic than necessary. Nonetheless, these reservations are only a call to continue the good work along the lines outlined in this stimulating volume.

Sophie Maisonneuve

Université de Paris, Cerlis sophie.maisonneuve@u-paris.fr