dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments We are grateful to  Andrés Cuberos ,  Ecaterina Nisipasu ,  Mathieu Poulin  and  Przemyslaw Sloma  from  SCOR  for their valuable comments and support. We are also much indebted to  Roland Denis  and  Benoit Fabrèges  for intensive support on computational aspects. We are grateful to anonymous reviewers of a previous version of the paper, their comments helped to improve the paper.
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.
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.
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.
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.
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.
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].
Examples include Extended Finite State Machines, Petri nets  [47] , timed automata  [48]  and Q-models  [49]. • 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.
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]. • Imperative synchronous languages, such as ESTEREL  [65]. • 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].
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].
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. • 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.
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  [82] , IEEE 1220  [83]  and IEC 15288  [84] ). • 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]  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  [3] ).
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.
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.
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.
26 billion over the past 12-month leading to June 2021 (Table  6 ). While the growth is impressive, the total revenue generated online is still small in comparison to annual revenue generated by live auctions: USD 10. 2 billion in 2019 to USD 6. 3 billion in 2020 and USD 10. 1 billion over the past 12-month leading to June 2021. Table  6. Twelve-month rolling total revenue from live and online only auctions arranged at Christie's,  Sotheby's, and Phillips (from 2017-2021). Source: Pi-eX Ltd. proprietary database of auction results. As shown in Figure  6 , revenue from online only auctions has been growing over the past year while revenue from live sales plummeted after March 2020 due to the temporary operational challenge brought about by the Coronavirus pandemic. The scale, however, and growth trend of online revenue remains much smaller than that of live auctions (Figure  6 ).
The Art Market Future and the Future on the Art Market I built this part on a qualitative analysis of 86 forecasts of the art market's future. The main criteria for selecting data for the research were creation time, media coverage, and place of origin. The collected forecasts were published between March 2020 and April 2021. I decided to extend the period of collected materials to the maximum in order to diversify the perspectives as much as possible. As the pandemic continued, market participants began to become used to operating under pandemic conditions, which may have changed the nature of their predictions. In the research sample, 33 forecasts come from the first half of 2020, 39 from the second half of 2020, and 14 from the first half of 2021. Although the data vary by the institution of origin, institution type was not a criterion for selection.