Using fUML Combined with a DSML: An Implementation using Papyrus UML/SysML Modeler Maurice Theobald1 and Jérémie Tatibouet2 1SAFRAN/SAFRAN Tech, Magny-Les-Hameaux, France 2CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, P.C. 174, Gif-sur-Yvette, 91191, France Keywords: fUML, UML, SysML, Systems Architecture, DSML, Papyrus. Abstract: The definition of standards is an efficient way to ensure a consensus on concepts and usages for a given domain. Unified modeling language (UML) and System modeling language (SysML) are standards: UML provides a large set of concepts enabling the specification of software-oriented systems meanwhile SysML specializes UML for system engineering. Both languages have an accurate semantics, this is especially true for UML which has a subset of objects (classes, composite structures, activities and state machines) that can be executed. Executable UML is driven by the following standards: Foundational subset for executable UML (fUML), precise semantics of UML composite structure (PSCS) and precise semantics of UML state machines (PSSM). From the UML based standard contributor standpoint, there is a great temptation to conclude that system architects can use these standards easily to model complex systems, and run simulations. Unfortunately, in practice, this assumption hardly ever holds. Indeed, these standards are built to be generic enough to apply for the largest possible set of systems. This implies that their scopes are wider than what is required by a user to work in its domain. This problem is solved by using and specializing (if required) a subset of these generic languages to match the needs. This paper shows how to reuse the power of UML, SysML, fUML, PSCS and PSSM efficiently, with a customized version of Papyrus dedicated to system architecture design. 1 INTRODUCTION framework using simulation. To reach that goal, models formalizing the system to be simulated must SysML (OMG, 2017a) provides many concepts that be executable ones. Making models executables can can be reused to specify complex systems. To get the be performed in two ways: by formalizing the benefits of this language (e.g., SysML), our company execution semantics of the language used to specify has defined its profile on top of it. This profile is the model or by mapping the model to a language that implemented in a specialized version of Papyrus as a can be executed. At SAFRAN, the choice is to map pilot, to support the model-based systems engineering the models of a system into an equivalent model (MBSE) (Cameron and Adsit, 2018) methodology conforming to an executable UML subset. The adopted by the group SAFRAN. Then it’s easier for a rationale behind this choice is the following. First, system architect to use the profile and the methods SAFRAN profile is based on the UML (OMG, 2017b) implemented in the tool, to model the architecture of and SysML (OMG, 2017a) standards, hence, if a system. However, while the language is well suited semantics are defined for the models then they shall to specify complex systems, it doesn’t provide the be captured based on the standard semantics defined capability to use models defined with this language for UML. Second, SAFRAN strongly advocates for for simulation. This problem is mainly related to the keeping the system specification models separated fact that SysML and its specialization have no formal from the model used to simulate. Indeed, at definition for their semantics. This assertion is true SAFRAN, the system architect and the simulation for both SysML and its specialization at SAFRAN engineer are two contributors involved, to design the since their semantics are defined in natural language. system models. But only the simulation engineers Nevertheless, now, it became essential for SAFRAN design the simulation model. to validate the system designed based on its modeling 248 Theobald, M. and Tatibouet, J. Using fUML Combined with a DSML: An Implementation using Papyrus UML/SysML Modeler. DOI: 10.5220/0007310702480255 In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 248-255 ISBN: 978-989-758-358-2 Copyright c 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Using fUML Combined with a DSML: An Implementation using Papyrus UML/SysML Modeler The contribution reported in this paper is the generate these events. For functional mode, a set of definition of the transformation rules to map a SysML functions is enabled. model to an executable model compliant with the Four types of diagrams describe the functional executable subset of UML. Beyond the aspects: transformational aspects that remain classical, this . The Functional mode diagram displays article shows how standards from the OMG, the system functional state. specifying the semantics of subsets of UML could be . The Functional decomposition diagram used to execute models. represents the system’s functional The paper is organized as follows: breakdown structure. Here, the highest- Section 2 presents the MBSE architecture framework level functions are more abstract than the used in Safran, with a focus on the functional lower-level functions. architecture design. Section 3 presents an overview of . The Functional flow diagram shows how the intended semantics for functional models the flows are transformed within the specified within the architecture framework. Lastly, system. section 4, presents how to generate a model used to . The Functional scenario diagram simulate from a functional specification. We used the describes the temporal relationships model of a toy quadcopter to illustrate our works. between the executions of the functions. Figure 1 shows these diagrams. 2 OVERVIEWS OF THE MBSE ARCHITECTURE FRAMEWORK The MBSE system architecture framework used in Safran (Theobald et al., 2018) is made of three main views: . Operational . Functional . Physical A system architecture is designed and organized according to these views. The operational view defines the system as a black Figure 1: The set of diagrams used to model the functional box. Its main purpose is to capture how the system view. interacts with its environment, collect and consolidate the requirements specified by the stakeholders. In this document the focus is on simulations from The physical view describes how the system the functional architecture view. Section 3 presents functions are implemented. It shows the interactions the supported semantics. between the system components, the subset of components that are active according to the system functional mode and the physical scenarios. 3 THE FUNCTIONAL 2.1 The Functional View INTERACTIONS SEMANTICS The functional point of view describes what the The functional interaction diagram shows the system should do to provide the services required by relationships between the function’s inputs and the stakeholders. Here the focus is on the outputs. It describes how the flows are consumed or transformation process of functional flows inside the transformed within the system. However, it doesn’t system. These flows can be from many types: data, show the sequence of execution: parallel, alternate mechanical, fluids, thermal, electrical, or path, sequence. electromagnetic. During this transformation process, Functions are run in the following way: the functional mode of the system is changing . A function can start its execution when flows depending on events; the system or its environment are ready on a subset of its inputs; data don’t need to be ready for all inputs at the same time. 249 MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development Note: In section 4 we consider a pure dataflow The proposed tooling avoids the simulation engineer case where all inputs are required to start the the need of such knowledge. The functions designed execution. by the system architect are translated automatically . The order in which the flows are ready for the into executable functions. This translation is inputs of a function is not relevant. described in section 4. Let’s consider Figure 2, and Figure 3. Table 1: Functions allocated to functional model. with the ground thestationwith ground Navigate in space Communicate energyStore electrical Program firmware the move space in theplanmanage flight Store parameters flight Distribute energy electrical video Capture landscape PowerOn X X Self Tests Flight X X X X X Figure 2: Abstract of functional flow diagram from the planning Cruise quadcopter model. X X X X X X X Charge X X X Stand by X X Takeoff/ X X X X X X X Landing Emergency X X X X 4 GENERATION OF THE EXECUTABLE MODEL FOR SIMULATION Figure 3: The functional mode diagram of the quadcopter. 4.1 Rationale For each mode in Figure 3, a subset of functions from Figure 2 is enabled. fUML (OMG, 2017c), PSCS (OMG, 2018), and For example, when the system is in Charge PSSM (OMG, 2017d) identify a subset of UML mode, the function Program the firmware is defined with a precise semantics. Models built using enabled, and can be executed. The other functions are this subset are by construction executable. While disabled, except the functions that manage the energy these standards offer the means to specify simulation of the drone. The reason is that functions Store models, they require a high skill in UML to be used electrical energy and Distribute efficiently. One of the challenges is to abstract some electrical energy are transverse, and must be aspect of the language from the domain simulation active, as far as the system is powered on. engineer (i.e., a domain expert responsible for Table 1 shows the allocation of the functions to the specifying/completing the simulation model). Indeed, system functional modes. it’s useless for a simulation engineer to know that Modeling an executable behavior with UML, sending an integer through a port requires to: (1) read requires a deep knowledge of this language. the execution context, (2) encapsulate the integer into signals (3) and finally send out the parameterized 250 Using fUML Combined with a DSML: An Implementation using Papyrus UML/SysML Modeler signal through a port.