Mapping Simulink to UML in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioral Mapping

Transcription

1 1 Mapping Simulink to UML in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioral Mapping Carl-Johan Sjöstedt 1, Jianlin Shi 1, Martin Törngren 1, David Servat 2, DeJiu Chen 1, Viktor Ahlsten 1, Henrik Lönn 3 KTH, Sweden 1, CEA LIST, France 2, Volvo Technology, Sweden 3 carlj /jianlin/martin/chen@md.kth.se, david.servat@cea.fr, henrik.lonn@volvo.com, ahlsten@kth.se Abstract The multidisciplinary nature of advanced embedded systems requires a combined usage of several tools and modeling languages in systems development. We investigate the needs and some of the possibilities in simultaneous usage of MATLAB/Simulink and UML. Structural and behavioral mappings are explored considering the needs for models at different abstraction level as well as environment models. Structural and behavioral mappings are explored focusing on continuous-time and discretized models. A procedure for transforming Simulink models to UML composite structure and activity models is presented. The behavioral transformation takes the behavior of the MATLAB/Simulink simulation engine into account, and captures it as UML activity diagrams. The transformation has been (partially) implemented using the Atlas Transformation Language. 1. Introduction There are several traditional ways in which developers try to manage the integration of embedded systems. We distinguish between hardware level, software level and model level integration [5]. Among these approaches, the model level integration has a major advantage with respect to both product qualities and engineering effectiveness by enabling earlier solution integration, verification and validation (V&V), and design space exploration [10]. The design of advanced embedded systems requires a consideration of several levels of abstraction, from requirements to the implementation in software and hardware, and also the environment with which the system interacts. Embedded system development is moreover characterized by the diversity of tools being used, as results of multiple domain needs and aspects, various organizations, and different preferences and legacies. Although many endeavors have attempted to define a single language for all purposes, it is generally agreed that this goal is difficult, if not impossible, to reach. Consequently, there is a need for combining the usage of several disciplinary-specific tools and modeling languages. 1.1 Objectives and goals The goal of this paper is to investigate the needs and possibilities concerning a combined usage (i.e., model level integration) of MATLAB/Simulink (Simulink) [11] and the Unified Modeling Language (UML) [12]. This investigation is motivated by the fact that Simulink is a very common tool for modelbased control system design and in particular simulation, whereas design of embedded systems software architecture and software functionalities is increasingly based on UML and its derivatives. The original purpose of UML is to provide graphical views of software systems. There is an increasing industrial interest and research work in supporting the integration of Simulink and UML to allow one to exploit the benefits of both [3, 7, 9]. The contribution of this paper is to approach the combined usage of Simulink and UML in four ways: By identifying integration needs and providing motivation for model transformations. By investigating structural and behavioral mappings between subsets of the two modeling languages. Simulink models could be described using composite structure diagrams combined with activity diagrams for behavior. By describing a prototype tool, how the integration and transformation could be carried out using the Atlas Transformation Language. Since Simulink and UML are rich languages, and designed for different purposes, it is evident that it is not meaningful to try to model one language completely using the other. Rather, an intersection between the languages has been explored, where mod- - PAGE 1 -

2 els can interact and possibly be interchanged. Stateflow, which is a Simulink add-on to describe event-triggered behavior, has been excluded from this work. Both languages are constantly evolving, here UML version 2.1 is used, and MATLAB/Simulink 2006a. The work is performed in the context of the ATESST project [1], where an architecture description language EAST-ADL2 for automotive embedded systems is developed and implemented as a UML profile. A structural mapping between Simulink and UML has been developed in the project and is reported in this paper. In addition, this paper reports on results from an investigation on why and how to deal with behavioral mappings between Simulink and UML. 1.2 Disposition The paper is structured as follows: Section 2 describes needs for integration and the context of our work. Section 3 presents structural and behavioral aspects of UML and Simulink, and explores mappings between the languages. A mapping of Simulink models to UML is proposed, and a example of this mapping is shown in Section 3.3. Section 4 describes the technology behind the translation tool developed in this project. Section 5 describes similar approaches, and how they relate to this approach. Section 6 concludes the paper with a discussion and proposals for further work. 2. Integration needs This section first provides overall requirements and context for embedded systems modeling, and then concretizes these with model integration scenarios. 2.1 Scope of models and dependencies From the design perspective, two orthogonal dimensions of a system can be identified: system content and abstraction level. The content includes system structures and behaviors, representing what the system is and what the system does, respectively. An embedded system typically includes behaviors of different types such as discrete-time, continuoustime, and discrete-event. The abstraction levels are defined according to the degree of preciseness and details with respect to the final realization, ranging from abstract function specifications to operational software code. Figure 1 illustrates five abstraction levels of an embedded vehicle system and the tight connection to the systems environment, which has to 2 be considered at all levels. An engineering process has to deal with these levels and also cover V&V and information management. Vehicle Level Analysis Level D esign Level Im plem entation Level O perational Level Figure 1 Abstraction levels of embedded vehicle system [1] Each abstraction level is populated by design entities, from abstract models to physical components, such as functions, software, and hardware components. Among these components there are obviously dependencies, examples of which include [6]: Communication/composition at a particular level e.g., between software components. Refinement where e.g., a set of functions are refined into a piece of software. Allocation e.g., where software components are allocated to processors. Duplication e.g., due to undesired overlap of information among models. Commonality e.g., because of reuse of functions. 2.2 Simulink/UML model integration scenarios Given that UML and Simulink are used to represent different views/concerns related to a product, the above types of dependencies will be introduced between the models. This causes a general need for creating and managing these dependencies. Moreover, it is highly desirable to support dedicated system views as well as system level analysis and synthesis. Examples of the latter two include consistency checks across the models, system level quality analysis (e.g., safety analysis or co-simulation), and coordinated generation of code/documentation. Such scenarios and needs can be supported in different ways: Description of Simulink models in UML One example of model level integration is General- Store [3], which performs structural transformations between Simulink models and UML class diagrams, where UML models are used as the overall system representation. Related scenarios can include needs to impose UML structure on a Simulink model, or building UML structure diagrams from Simulink subsystems. - PAGE 2 -

3 Co-simulation between a UML tool and Simulink (behavior interaction) CASE tools like ARTiSAN Real-time Studio, I- Logix Rhapsody and Rational Rose Realtime claim support for co-simulation with Simulink. See for example [7]. Simulation of UML models using Simulink Some UML diagrams could possibly be converted to Simulink models, and then Simulated using the Simulink engine, also together with native Simulink blocks. One example is the mapping from the AUTOSAR 1 software component description to Simulink models as a basis for behavior modeling and simulation [2]. In the ATESST approach, the UML model contains the complete system model and Simulink is considered as a specific system view. Given that the functionality is first developed in Simulink, it would then be desirable to import this into the UML system model. Alternatively, if the UML system model is first developed, the functional model could be exported to yield a Simulink model. For behavior, UML activity diagrams can be used to specify the complete system behavior, where a subset may correspond to the Simulink design. Hence, there is an on-going effort to map Simulink behavior to activity diagrams, which is presented in the following sections. 3. Mapping Simulink to UML Since both UML and Simulink are semi-formal languages and can be used in different ways, it is impossible to provide a silver bullet that gives a unique mapping. UML makes a clear distinction between behavioral and structural aspects, but all behaviors are attached to structural entities. However, Simulink essentially describes system behaviors, i.e., with a main emphasis on what the system does although a logical model structure can be imposed using subsystem hierarchy. This fundamental difference also means that different mapping strategies are possible. For example, the detailed design of a subsystem in Simulink could be mapped to a UML structural diagram for information management purposes or a behavioral description of one class representing the subsystem for behavior specification purposes. Another issue for the mapping is the interpretation of the languages vs. tool support and implementations. For UML, there are a number of profiles which extend the standard UML and a lot of 1 Automotive Open System Architecture 3 UML tools with slightly different implementations of the UML language. The following sections discusses structure and behavior in UML and Simulink, and explores solutions for their mapping. 3.1 Structural concept mapping From a systems engineering viewpoint, a system structure represents concrete solution elements to which system functions are allocated. In modeling, a different logical structure can also be imposed on both behavioral and system structural abstractions. This logical structure, which has the purpose to facilitate model usage, may thus have no direct correspondence to the physical structure of a system Simulink model structure Two types of composition can be used in Simulink model; virtual subsystems and non-virtual subsystems. Examples of the latter one include enabled subsystems, triggered subsystems, and function-call subsystems. Virtual subsystems are used for imposing a logical structure of a model. The boundaries of virtual subsystems are ignored in simulation and the semantics of the virtual subsystem structure relies on the user. The interpretation could for example be related to the physical system structure or the software structure. As a contrast, a non-virtual subsystem is treated as an atomic unit when determining the execution order of blocks. Basic elements of a Simulink model are blocks and lines. A block represents a model entity, which might be a system that contains subsystems. To create a subsystem, it is necessary to include two kinds of special blocks Inport and Outport to represent the input-ports and output-ports of the subsystem. A line connects two blocks by connecting SrcPort and DstPort which correspond to the output-port and the input-port respectively to represent the interaction of model entities in terms of data and control flows UML model structure UML uses structural diagrams to describe the static relationships between system elements independent of time, where basic elements include classes and associations. Composition and aggregation are used to describe the part-whole relationship. UML has six kinds of structural diagrams, the class, object, composite structure, package, component, and the deployment diagram. The composite structure diagram seems to be most suitable for representing Simulink models. One reason for this is that the composite structure diagram was introduced into UML with the - PAGE 3 -

4 explicit purpose to show logical relationships between elements of a complex class and to identify their collaborations [8]. Composite structure diagrams show the internals of classes in terms of interconnected sub-parts. Two parts may have ports and be connected via dedicated connectors. The resulting view thus fairly resembles the graphical settings of Simulink block diagrams Structural mapping The modeling entities in a Simulink model can be treated as objects in UML, where in a general sense everything is defined by a class. Signals between Simulink blocks correspond to UML connectors with ports attached to the corresponding classes. Table 1 gives our proposed structural concept mapping. By this mapping, structures of a UML model depicted by connected classes through connectors, correspond to structures described by connected blocks in a Simulink model. An example UML to Simulink structural transformation produced by our prototype tool is given in Figure 2. A simple one-to-one mapping between structural entities at both ends is not sufficient though. Several parameters need to be stored in the transformation process. Besides, annotations might be needed to let users see that UML elements created to correspond to Simulink elements have a precise semantics attached to them, which may differ from their use or assumed semantics in a plain UML settings. This can be dealt with through the definition of a dedicated UML profile. A profile is a set of stereotypes which are tags that can be applied to UML elements in order to store additional information and provide specific semantics. In our case, a UML profile containing all standard blocks, and their behavior has been defined. The profile is generated from a Simulink meta-model. Table 1: Structural concept Mapping Simulink Concept Primitive block Subsystem Line SrcPort DstPort Line Branch UML 2 Concept Class Property with a class defining it Connector Port with a class defining provided interfaces for the port Port with a class defining required interfaces for the port Connector Composite structure and ports In UML, a composite structure diagram is made out of classes. An intuitive solution is to use classes to represent standard Simulink blocks, and to use in- 4 stances to represent individual blocks in a model. Another feature is that the block defaults in the Simulink model file (.mdl file) can be stored in the class. In UML, the instances of the class inherit all properties from the class, this is a fundamental UML concept. So, if a port is added to the class, the instance will have the port as well. In Simulink, some blocks can have a user-decided number of ports, i.e. zero-to-many or one-to-many. To deal with this issue, an abstract port type was defined, having a defined multiplicity. When instantiating the class, the number of ports is decided, and corresponding names given. To clarify this, the sum block of Simulink can be used as an example. It will sum any number of inputs, and produce exactly one output. This is defined in the Simulink meta-model, from which a profile is generated. When transforming from the Simulink model, a sum parent class will be created, having the block defaults from the.mdl file, and the stereotype sum. Then, instances of this class will be made, and ports will be attached to the instances. The ports will have the abstract port type. acc_enable_button [0/1] desired_target_distancepedal acc torque request [Nm] wheel_speed (4) measured_wheel_speed [km/h] (4) [km/h] rain_intensity [mm/h] HMI mean_vehicle_speed [km/h] Perception acc_enable [0/1] rain_intensity [%] acc_enable [0/1] accelerator_pedal_request [Nm] measured_wheel_speed (4) [km/h] vehicle_speed [km/h] moderated_torque_request [Nm] rain_intensity [%] Vehicle application Figure 2: Structural mapping example Data types acc_mode [0/1] acc_enable_button [0/1] desired_target_distance [s] engine_torque [Nm] wheel_speed (4) [km/h] rain_intensity [mm/h] Vehicle Environment Simulink does not require an explicit declaration of types. Some blocks, e.g., Unit Delay and Sum, do not have type constraints on the block itself, instead they inherit the type from their input. However, Simulink does reject models due to type errors, e.g., when two inputs of a Sum block have different types and the - PAGE 4 -

5 setting of the Sum block is set to require the same type of inputs. Nine kinds of data types are defined in Simulink, known as boolean, double, single, int8, uint8, int16, uint16, int32, and uint32 respectively. UML has four predefined data types, Boolean, Integer, UnlimitedNatural and String, known as instances of primitive type. In UML, a data type is similar to a class, but it is a special classifier whose instances are identified only by the value. A user can define new data types when needed similar to defining a class. The mapping of data types between Simulink and UML therefore becomes rather straightforward to handle. 3.2 Behavioral concept mapping Behavioral mapping is somewhat more complicated compared to structural aspects. Several Models of Computation and Communication (MoCCs) can be represented in UML and Simulink, and the respective MoCCs have different origins. As a baseline for the proposed behavioral mapping between Simulink and UML we first present the behavioral constructs of Simulink and UML. Basic elements to describe behaviors includes data, triggers, actions, states and time. There are many types of MoCCs based on various combinations of these basic elements. For instance, simple MoCCs can be based on pure event-triggering (control flows), pure data-flow, or combinations thereof. Finite state machine formalisms (FSM) provide ways to express more complex MoCCs Simulink model behavior Three overall types of MoCCs can be modeled by Simulink: continuous-time, discrete-time, and eventtriggered. Simulink uses different types of blocks, e.g., continuous-time blocks and discrete-time blocks for the corresponding MoCCsFel! Hittar inte referenskälla..fel! Hittar inte referenskälla.. Primitive blocks are pre-defined in the Simulink library. Compositions of primitive blocks form subsystems which are virtual or atomic. The behavior in Simulink can be interpreted in two ways: either from the language viewpoint or from the viewpoint of the observable simulation behavior. As described in 3.1, the Simulink language, i.e. the blocks and connectors, will be translated to UML composite structure diagrams. The simulation behavior, i.e. what happens in the model when running a model, will then be described by UML behavior diagrams Continuous time behavior A typical continuous Simulink diagram describes a feedback system using the signal flow model, like in Figure 3. Figure 3: A second order differential equation modelled in Simulink It constitutes of a second order system, described by equation (1): & + & (1) x x + 2x = F( t) The feedback can be due to a controller, i.e., a PID controller, or physical feedback, e.g. a friction force that is dependent on the speed. It is a causal representation [13], that gives a relation between input and output. Such a continuous causal model has behavior at every time instant. This corresponds to the same MoCC as bond graphs, which are interchangeable with signal flow [14]. There is not a unique mapping between the equation and the signal flow representation, an equation can be modeled in different ways. A causal representation could then be seen as a preparation of an equation for numerical solution. The continuous blocks will be discretized by the solvers, using different methods depending on the solver Ordering of blocks The blocks of a Simulink model are typically in a loop, needing input from each other to perform computations. It is thus not trivial to decide where to begin or end computations. This can also be seen as an advantage of using Simulink, that this is abstracted away from the user. Simulink uses two rules for defining the order of the blocks [11]. Each block must appear in the sorted order ahead any of the blocks whose directfeedthrough ports it drives. Direct feedthrough means that the output is controlled directly by the value of an input port Blocks that do not have direct feedthrough inputs can appear anywhere in the sorted order as long as they precede any blocks whose direct-feedthrough inputs they drive. This way, Simulink only has partial order. The actual 5 - PAGE 5 -

6 ordering of the blocks can be displayed by the slist MATLAB command. This ordering can also be altered by assigning priorities to blocks Running simulations When a simulation of a Simulink model is started, it enters the model compilation phase. Here, model hierarchy is flattened, the blocks are sorted, data types are determined etc. Then there is the link phase, where memory is allocated, and an execution list is generated. Finally, it enters the simulation loop phase, where blocks first are initialized, and then runs in the iteration loop of: output Calculates the propagation from outputs from the continuous blocks to their inputs as described in update Runs the solver. Some solvers uses minor outputs to calculate intermediate values, which is the same loop, but excluding user output (e.g. scopes, to workspace). check for discontinuities After a complete update, Simulink checks if there has been any discontinuities in any block. If it has, the zerocrossing mechanism will set in. This could be seen as the link between event-triggered behavior, and continuous behavior. calculate next time-step Self explanatory More details on the simulation behavior is to be found in [16] Discretized time behavior The ordering of blocks is the same for discretized models. Note that there are integrators having directfeedthrough (e.g. backward Euler), which will affect the order of the blocks. In discrete models, all behavior are in the blocks themselves, the discrete solver only sets new time steps for the iterations UML model behavior The fundamental unit for behavioral description in UML is the action. UML predefines a number of primitive actions such as the reading of and writing to properties of a classifier, sending signals, calling operations and/or behaviors. On top of this action set, there are three kinds of behavior formalisms in UML: activities, state machines and interactions. Interactions focus on message exchange sequence in time occurring during the execution of a behavior. Activities describe behaviors in a control-flow oriented manner, whereas state machines provide for a state-transition view of a behavior logics. Behaviors can be hierarchically 6 composed: e.g. a state machine may have submachines; an activity may have sub-activities which are compositions of actions.. The execution of behavior itself relies on various triggering mechanisms. These involve the occurrence of specialized events depending on the type of trigger e.g. CallEvents, TimeEvents, ChangeEvents, SignalEvents. Behaviors described by these formalisms are thus essentially restricted to discrete-time and eventtriggered MoCCs. Figure 4 and Figure 5 give examples for each of them. However as the interval between two events is not specified by UML and can be as small as needed or even infinitesimal, continuous behaviors can theoretically be specified in UML. Aside from these UML native behavior constructs, UML introduces the concept of OpaqueBehavior for user-defined behaviors given in terms of a specific language (e.g., C-code, text, reference to an external file, or an equation). In our case OpaqueBehavior is suitable to refer to a Simulink-defined behavior, and Activity seems a good candidate for capturing the translation of the Simulink model into UML. This is further discussed in section Figure 4: Example of event-trigger in UML activity diagrams. Figure 5: Example of time-trigger in UML activity diagrams Behavioral mapping A combined structural and behavioral mapping is suggested. In the UML profile of Simulink, as described in 3.1.3, local behavior of blocks and associated parameters can be stored. For instance, when converting from Simulink to UML, a gain block gets associated behavior from the UML profile. The method to go from Simulink to UML can be seen as a 5-step process: 1. Mapping the Simulink diagram to a composite structure diagram, and a corresponding class diagram, as described in Attaching corresponding behavior to each block. Each block will get a local behavior, where based on data from the input(s) calculates outputs, which is transferred to the input port(s) in to the following blocks. - PAGE 6 -

7 3. Generation of outputs.major and outputs.minor activity diagrams, to show the (partial) ordering of the blocks as defined in An activity in this diagram corresponds to executing the local behavior, defined above. 4. Generation of activity diagrams to show the complete simulate behavior. 5. Attachment of a solver in a modular way, so that solvers can be exchanged by interchanging activity diagram of the solver. All one-step ODE solvers can be described using activity diagrams. What we get by using this method is a one-to-one mapping of the Simulink model structure to a UML composite structure diagram together with associated UML class definitions. We also get a complete description of the simulation behavior of this particular model. 3.3 Example system To clarify our approach, the example system in Figure 3 is translated to UML. First, a composite structure diagram is generated, and ports instantiated as described in , this is shown in Figure 6. 7 is one part of the Simulation loop, which in turn is a subset of the complete Simulate method in Figure 8, which is called when starting a Simulation. Figure 8: The overall simulation methods used by Simulink, described as an activity diagram The SimulationLoop is the heart of the simulation engine. After the outputs.major activity, new inputs for the integrators becomes available in the update activity. The integrators execute in the Solver activity, which is dependent of what solver is used (e.g. ODE23, ODE45). The solver itself can also contain outputs.minor steps. For instance, one major Runge Kutta (ODE4) time step, includes four minor steps. In this example, the outputs.minor activity diagram is the the same as the outputs.major diagram in Figure 7, excluding the Output block. Figure 6: The Simulink model in Figure 3, represented as a composite structure diagram The order is determined by the rules as defined in section This is a partial order, which can be visualized by the activity diagram in Figure 7. Figure 7: The execution order in a major time step. When executing the slist command in Simulink, the actual execution order of the blocks is displayed, which could be seen as an instantiation of the diagram in Figure 7. The outputs.major diagram Figure 9: The Simulink simulation loop, executed at each major time-step At the end of the solver activity the zero-crossing mechanism is executed. Then, if the end time has not been reached, the next major time step is decided, and the simulation loop is completed. 4. Technical implementation To enable extension and modification of the tool, the approach used describes the transformations as explicitly as possible. This is achieved using a QVTlike transformation language, the ATLAS Transformation Language (ATL), rather than using a general purpose language. The ATL toolset is used under the Eclipse platform, which leads to the need of an initial transformation from the Simulink to the EMF technical space. This is implemented in Java, as a line-by-line translation between the.mdl and XML structured text file formats. Additionally the input meta-model, that the input model conforms to, needs - PAGE 7 -

8 to be defined. The meta-model describes a subset of the complete Simulink file format. This subset represents all the elements and attributes that could used in the transformation. The output UML meta-model is loaded from the Eclipse meta-model repository. The prototype tool is under development, so far a proof-of-concept partial mapping has been implemented. MDL MDL{} Conform to File stream Java EMOF (Eclipse) MDL subset ATL UML < XML /> *.atl Figure 10: The transformation tool technologies 5. Related approaches ATL Toolset There are related approaches, where a causal continuous representation of a system is described, using computer scientific formalisms. Two of these approaches are shown here, and compared with our effort 5.1 Comparison with Ptolemy continuous time MoCC Ptolemy is a formal approach to describe modeling, simulation, and design of concurrent, real-time, embedded systems [15]. A focus is the use of a combination of well-defined MoCCs. One of the MoCCs is continuous time. Ptolemy also uses function block modeling, so the models resemble Simulink. A socalled director is defined for each MoCC, defining how blocks and communication s are scheduled and thus how the whole systems. For the continuous time MoCC, the director is similar to the Simulink simulate method, as described in Figure 8: The overall simulation methods used by Simulink, described as an activity diagram, including ODE solvers, major and minor steps, etc. The blocks diagrams also resemble Simulink, see Figure 11. UML Di2 DI2 Figure 11: Ptolemy continuous time example system The execution order of the blocks is described as tokens are emitted at non direct-feedthrough blocks, and then propagated through-out the model. In systems with algebraic loops, the more tokens will be consumed than are produced, which leads to a deadlock. Simulink has a special algebraic solver, while Ptolemy today does not support algebraic loops. In Ptolemy, the order of the integrators are arranged to get the lowest derivative first. This will have effect when using implicit solvers (Gauss- Siedel vs Gauss-Jacobian). Although there are implicit solvers in Simulink, it is not documented that Simulink have this behavior. Implicit solvers have direct-feedthrough in integrator blocks, and uses iteration in each time-step to solve the system. 5.2 Comparison with UML 2/SysML continuous flow Figure 12: Our example system, modelled like [4] In activity diagrams there is no limit on how close together in time items may move through an activity, or how long activities can execute. This way, continuous activities can be defined as a flow where the time between individual items or control values is zero. In SysML, the rate at which items and control arrive and leave activities can be set to continuous. A direct mapping of Simulink to activity diagrams is tempting. It is even suggested by Bock [4]. However: Algebraic loops will introduce nonstreaming activities having inputs, requiring outputs from itself to fire. The activity diagram in Figure 12 have an order, from the start activity to the end activity, which is not the same as the order in Simulink (in Figure 7). It is not even possible to fire the Add activity, due to lack of input. In [4] it is suggested to be initial values for the Add activity, to solve that 8 - PAGE 8 -

9 problem. Anyhow, this description is not coherent with how Simulink works. Even though the time between the activities is zero, continuous activity diagrams suggests a sequencing of actions that is not part of the continuous causal MoCC, where everything happens simultaneously. 6. Conclusion and future work The development of complex embedded systems requires numerous specific views. We have studied the integration between Simulink and UML by investigating integration scenarios and by exploring possible solutions for structural and behavioral mapping. Performing a mapping first requires consideration of the purpose and scope for the mapping in order to determine a suitable mapping strategy. Here, the scope was not only to store information about the structure of the Simulink model, but also to map the actual simulation behavior. It is a philosophical question what to call behavior, and what is structure. In SysML, continuous causal diagrams (i.e. Simulink models) are modeled as activity diagrams. To one extent, one could say that a differential equation describes the behavior of an entity. But since the diagrams cannot be executed, they do not have behavior by computer science means. We suggest instead a mapping of the Simulink language to composite structure diagrams, and to attach behavior separately. We have showed how Simulink simulation behavior can be expressed using activity diagrams, and how these activity diagrams can be generated using our translation tool. This opens up for many future possibilities: The simulation could be run using a UML activity diagram execution engine. Implementation code could be generated from the activity diagrams. The functions can be further developed, assigned to processes, hardware etc. in UML. Structural mapping between Simulink and UML has been proved useful before. For example, physical components modeled in Simulink can be imported to become a part of a system information model in UML, to support versioning, traceability to requirements, etc. In the particular case of the EAST-ADL in the ATESST project, behavior from different notations and legacy tools can be integrated, while keeping the integrated behavioral model sound. Acknowledgments This work was sponsored by the EC 6 th framework programme in the ATESST project (project no ), the ARTIST2 project ( project no. IST ), and the SAVE++ project. References [1] ATESST project, [2] AUTOSAR specification, Applying Simulink to AUTOSAR, available from [3] C. Reichmann, M. Kuhl, P. Graf, K. D. Muller-Glaser. "GeneralStore - A CASE-Tool Integration Platform Enabling Model Level Coupling of Heterogeneous Designs for Embedded Electronic Systems". P , 11th IEEE Int. Conference and Workshop on the Engineering of Computer-Based Systems (ECBS'04), May, [4] C. Bock, SysML and UML 2 support for activity modeling, Systems Engineering, P Vol [5] D. Chen, M. Törngren., J. Shi, S. Gerard, H. Lönn, D. Servat, M. Strömberg., K-E. Årzen. Model Integration in the Development of Embedded Control Systems - A Characterization of Current Research Efforts. IEEE International Symposium on Computer-Aided Control Systems Design (2006 CCA/CACSD/ISIC), Munich, Germany. 4-6, Oct [6] J. El-khoury, D. Chen and M. Törngren, A survey of modeling approaches for embedded computer control systems (v2.0). Tech. report, ISRN/KTH/MMK/R- 03/11-SE, TRITA-MMK 2003:36, ISSN , KTH, [7] J. Hooman, N. Mulyar, L. Posta, Coupling Simulink and UML Models, Proc. Symposium FORMS/FORMATS, [8] J. Holt, UML for Systems Engineering: watching the wheels, The Institute of Electrical Engineering, London, [9] L.B. Brisolara, M. F. S Oliveira, F. A. Nascimento, L. Carro, F. R. Wagner, Using UML as a front-end for an efficient Simulink-based multithread code generation targeting MPSoCs, 4th International UML DAC Workshop: UML for SoC Design (UML -SoC 07), June, [10] M. Törngren and O. Larses. Maturity of model driven engineering for embedded control systems from a mechatronic perspective. In: Model Driven Engineering for Distributed Real-time Embedded Systems. Sébastien Gérard, Jean-Philippe Babau, Joel Champeau (editors). ISBN: August [11] MATLAB/Simulink, PAGE 9 -

10 [12] OMG, the UML, [13] P. Fritzson, Principles of Object-Oriented Modeling and Simulation with Modelica 2.1, IEEE Press, John Wiley & sons, [14] D. Karnopp, D. Margolis, R. Rosenberg, System dynamics_ modeling and simulation of mechatronic systems, John Wiley & sons, [15] Ptolemy project, [16] Simulink user manual, Mathworks, PAGE 10 -