Multi-view Modeling to Support Embedded Systems ... - Springer Link

Multi-view Modeling to Support Embedded Systems Engineering in SysML Aditya A. Shah, Aleksandr A. Kerzhner, Dirk Schaefer, and Christiaan J.J. Paredis Systems Realization Laboratory, G. W. Woodruff School of Mechanical Engineering, Georgia Institute of Technology, Atlanta, GA, USA [email protected], [email protected], [email protected], [email protected]

Abstract. Embedded systems engineering problems often involve many domains, each with their own experts and tools. To help these experts with analysis and decision making in their domain, it is desirable to present them with a view of the system that is tailored to their particular task. In this paper, a model integration framework is demonstrated to address issues associated with multi-view modeling. The Systems Modeling Language (OMG SysMLTM ) is used as a general language to represent a common model for the system as well as the dependencies between the different domain-specific tools and languages. To maintain consistency between these domain-specific views, model transformations are defined that map the interdependent constructs to and from a common SysML model. The approach is illustrated by means of a mechatronic design problem involving views in multiple domain-specific tools, namely EPLAN R (for dyFluidTM (to create production ready layouts) and Modelica namic system analysis).

1

Introduction

The design of embedded systems is becoming increasingly complex because of its dependence on a combination of multiple disciplines, such as mechanical, electrical, electronics and software engineering. Moreover, since such systems are designed in collaborative distributed environments, they need to meet the objectives of a variety of stakeholders. To solve these multi-disciplinary embedded systems problems, it is essential to be able to synthesize and analyze different system architectures efficiently and effectively. This requires the ability to describe a system from different viewpoints, such as: structural, behavioral, requirements, different disciplinary domains, or different levels of detail, fidelity and abstraction. Therefore, multi-view modeling, in which a system is described from multiple points of view, is gaining in popularity. A key challenge in dealing with multiple views of a system is that of consistency. This is conceptually illustrated in Fig. 1. Information about the product or system (e.g., the requirements, the physical structure, the behavior, or the G. Engels et al. (Eds.): Nagl Festschrift, LNCS 5765, pp. 580–601, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Multi-view Modeling to Support Embedded Systems Engineering in SysML

581

manufacturing-process specification) is represented by black dots; the dependencies between the information objects is shown as boxes labeled ‘D ’. Examples of such dependencies include an assembly-part relationship, the dependence between the mechanical length of a wire and its electrical resistance, or the dependence between a circuit description and the corresponding analysis model. During the product development process, new information is generated by the stakeholders using a variety of domain-specific tools: synthesis or authoring tools (e.g., CAD tool or drawing tool for hydraulic schematics) as well as analysis tools (e.g., dynamic simulation tool, or reliability analysis tool).   















 













 






































  

 







  












 








  






 

Fig. 1. An example of an embedded system problem with multiple subsystem models in different domains with interdependencies between the models. Dependencies (D) exist between certain parts of different domains but not across the complete domain. A method that can identify these dependencies as well as allow for the addition of knowledge between models is required, such as the method presented in this paper.

Ideally, the information and dependencies defined within such tools would be linked globally across tool boundaries. But because individual tools are not aware of the information in other tools, the dependencies across tool boundaries often remain unaccounted for. Currently, at best, such dependencies are maintained at a coarse-grained level in a Product Data Management (PDM) system. For instance, one may keep track of which finite element model is related to a certain CAD file. But such coarse-grained dependencies do not identify at a fine-grained level which parameters in the finite element model depend on which CAD parameters. Even worse, many of the dependencies are modeled only informally (e.g., in a text document) or not at all (e.g., they are unknown or exist only in the brain of a stakeholder).

582

A.A. Shah et al.

Still, not all information needs to be shared among all tools. For instance, the detailed description of the embedded software can be maintained in a software engineering tool but does not need to be shared with a mechanical CAD (MCAD) tool. A fine-grained approach is needed that can identify information that is or is not common between multiple views is needed. For instance, while component and connectivity information from electrical or hydraulic schematics are important for simulation-related views, diagram layout and placement details may not be relevant in this particular context. Moreover, additional knowledge is often required when integrating between views, such as specifying control and simulation parameters when creating a simulation model from a structural model. Therefore, in such cases where models cannot be completely converted using standard interchange formats, maintaining consistency is usually left to the users resulting in significant non-value-added efforts and potential for error. In order to avoid such costly and error-prone processes, the approach advocated in Model-Based Systems Engineering (MBSE) is to model both the various views and their dependencies formally in terms of a common system model. However, even when using such a common system model, the modeling formalism must explicitly allow for information to be shared between different views. In this paper, the focus is to demonstrate a framework in which different domainspecific views can automatically be generated from a common system model. We explore and develop a foundation for supporting multiple views in the Systems Modeling Language developed by the Object Management Group (OMG SysMLTM ) [1]. Through domain specific modeling and model transformations, multiple domains and their relations can be described. Moreover, the framework presented complies with industry standards such as Meta-Object Facility (MOF) [2], Model Driven Architecture (MDA) [3], and SysML, thereby facilitating its integration with a variety of existing tools and standard frameworks. In the next section, related work and the motivation for the use of SysML is discussed. In Section 3, we present a method for multi-view modeling in the context of an electro-hydraulic embedded systems example. Finally, Section 4 summarizes the work presented and discusses the challenges that exist with regard to this framework and multi-view modeling frameworks in general.

2

Related Work

Embedded systems traditionally involved only the software domain. However, the increasing use of software as a replacement for hardware has resulted in embedded systems becoming a part of many complex systems in practice. As a result, embedded systems design spans multiple domains including the software to control these systems. These domains contain different information maintained in multiple views for each of the various subsystems. Therefore, the requirements for maintaining consistency between multiple views are different than those for maintaining interoperability between models.

Multi-view Modeling to Support Embedded Systems Engineering in SysML

583

Interoperability involves managing similar information across different formats. For instance, standard file formats such as XML [4] and STEP [5,6], are commonly used for interoperability in the software and engineering domains. On the other hand, multi-view modeling involves managing different information across different tools and domains. In such cases, tools usually do not conform to common file formats and if they do then there are limitations such as data loss issues in STEP [7] and readability issues with XML and XMI. Moreover, such transformations are usually carried out in batch mode and hence maintaining consistency and updating various views can become cumbersome [8]. Since different views involve different knowledge, such as synthesis or analysis knowledge, only certain aspects of each view are related. Therefore additional knowledge is required to generate one view from another, such as an analysis view from a structural view. Model transformations are suited for this, in which a source model is converted into a target model based on specified rules. Czarnecki et al. [9] discuss the classification and comparison of different model transformation based approaches, such as direct manipulation and graph transformations. In direct manipulation, general purpose programming languages such as Java or C are used directly to define transformations. As a result, it can be cumbersome to use, understand and maintain due to the lack of high-level abstractions available. Graph transformations, however, can be defined in a declarative and visual manner [10], allowing complex rules to be expressed in an intuitive fashion [11]. Another benefit of graph transformations is that they can be executed in continuous or incremental modes. Therefore, transformations can be performed interactively with the user which makes managing consistency between various views easier [8]. In addition, Computer Aided Software Engineering (CASE) platforms such as Fujaba [12] and MOFLON [13] provide the capability to define graph transformations and automatically generate corresponding executable code for performing the model transformation in a language such as Java. Therefore, in the research described in this paper, a graph transformation approach is adopted for the integration of multiple views of a system. In addition to multi-view integration, a mechanism for systems level design is required for embedded systems that are large and highly complex. To overcome these problems, the use of a general-purpose modeling language such as SysML has been proposed as an alternative to UML [14,15,16]. The use of SysML as a unifying language for systems design is discussed in the next section, along with related work that is being carried out with SysML. 2.1

SysML as a Common Modeling Language for Multi-view Modeling

As discussed in the previous section, due to the widespread use of embedded systems in contemporary products and systems, there is an increasing requirement for multi-view modeling methods that can incorporate multiple disciplines as well as integrate between their associated views. Multi-view modeling also involves describing a particular system in multiple ways, such as structural, behavioral, and requirements views.

584

A.A. Shah et al.

UML has been widely used in software engineering to model multiple views of a software system. However, since embedded systems are used in multiple disciplines of a complex system, embedded systems can no longer be designed from a purely software modeling point of view. Consequently, to overcome this limitation of UML when dealing with domains other than software, we advocate the use of SysML – a general Systems Modeling Language – that provides certain key extensions of UML to enable modeling of multidisciplinary systems, including software. SysML extends UML in the form of a SysML profile. Some key features include the introduction of requirements modeling, extension of Class in UML to Block in SysML to model system structure, constraint blocks to support engineering analyses, and the use of ports and flows to support flow of energy, information or matter between elements. More information regarding the specification and features of SysML can be found in [1,17]. Vanderperren and Dehaene [15] highlight the advantages of using SysML for requirements modeling in embedded systems (System on Chip) as well as to improve current UML-based development techniques. In addition to these new features, SysML and UML provide a mechanism to customize the general semantics of SysML through profiles. This is an important part of the multi-view modeling method presented in this paper, and is discussed in more detail in Section 3.3 on Domain Specific Modeling in SysML. In order to support multiple complementary views of a system we propose to use a common model in SysML that consists of a combination of relevant knowledge from the domain-specific views at a high level of abstraction. In addition, we use profiles to enable the domain-specific description of different disciplines and languages in SysML, as shown in Fig. 2. When compared to Fig. 1, we see that the dependencies are not directly between the multiple disciplines; rather, they exist indirectly through a common model for the problem under consideration. Consequently, each domain-specific model is a subset of the common model and is therefore a view of the system. Since each domain-specific view is at a more detailed level of abstraction compared to the common model, only certain aspects are required to be mapped between the common model and the corresponding view. This is achieved by abstracting the domain-specific semantics mapped into SysML through the use of profiles. As a result, only those parts of domains that are related to each other are integrated instead of translating a complete model from one domain to another. This can allow the designer to concentrate on specifying the system without worrying about the semantics and features of specific tools. Moreover, since the different domain-specific views are complementary to each other, maintaining a common high-level representation in SysML provides designers with a consistent big-picture view of the problem being solved. The framework for multi-view modeling presented in this paper involves describing domains through SysML profiles and metamodels, and defining mappings between them through model transformations. This method is discussed in the following section through an example of an electro-hydraulic system that

Multi-view Modeling to Support Embedded Systems Engineering in SysML

D

D

Common SysML Model for Problem

D SysML View based on Profile for Tool 1

D

D

D

D

D

D

SysML View based on Profile for Tool 2

D

SysML View based on Profile for Simulation Tool

SysML View based on Profile for Software Design Tool

D

D

D

View in Software Design Tool

D

D

View in Simulation Tool

D D

D

D

D

D

View in Tool 2

SysML

View in Tool 1

D

D

585

D

Fig. 2. Use of SysML and mappings as a common modeling language in which dependencies between different domains are captured through the use of a common view of the system in SysML.

has multiple views - a schematic layout view and a continuous simulation view in which the control system is modeled.

3

Multi-View Modeling Using SysML Profiles and Model Transformations

Our general method for multi-view modeling involves the following steps, which will be described in the context of an example problem of an electro-hydraulic log splitter. 1. Formal definition of the domains involved in the system through metamodels. 2. Customization of SysML through profiles to enable domain specific modeling. 3. Model transformations to generate domain-specific views from SysML 3.1

Example Problem Description

To demonstrate the implementation of the above steps, an example is used that can be modeled in different views such as structural, control and simulation. The example used for the remainder of the paper is of an electro-hydraulic log splitter (Fig. 3), which is used to divide cylindrical logs into two or more pieces. A traditional log splitter includes a hydraulic circuit in which a valve is manually operated to actuate a cylinder into a piece of wood. Instead of manual valve operation, we consider an embedded control system to operate the valve, resulting in improved functionality but also additional subsystems. These different subsystems are usually represented in multiple domain-specific

586

A.A. Shah et al.

tools such as EPLAN FluidTM [18] to capture the hydraulic schematics and R [19] for modeling the control system and dynamic behavior. In order Modelica to support these complementary views, a common model in SysML is created in order to represent the entire system at a high level of abstraction from which EPLAN and Modelica specific views can be created with the relevant subset of information (see Fig. 4). This is similar to the approach of domain-spanning specification by Gausemeier et al. [20] and Product View Federations by Bajaj et al. [21]. Thus, the integration between EPLAN and Modelica is done indirectly through a common model from which views can be generated by using SysML profiles and model transformations. Log Loading & Splitting Area

Directional Control Valve

Hydraulic Cylinder & Ram Engine & Pump

(credit: Dave Thompson)

Fig. 3. An electro-hydraulic log splitter. The production-related hydraulic layout is done using EPLAN Fluid, while a dynamic simulation involving the hydraulics and its control system is done in Modelica. A common view for both will be represented in SysML, from which views for EPLAN and Modelica will be created.

From the common model two views are created: a structural hydraulic schematic in EPLAN (Fig. 5) and a dynamic simulation of the system behavior in Modelica (Fig. 6). These two views each contain a subset of the knowledge captured in the common model. For instance, both tool-specific views contain the components and connection information. However, the EPLAN view does not contain controller information while the Modelica view does not contain information related to geometric layouts. A designer using EPLAN or Modelica may add/remove components and this is where a common model is useful in maintaining the relevant changes on both sides. The process of maintaining consistency can be similar to the process used by Gausemeier et al. [20], in which problem-specific rules and intervention by experts can be used to manage update and propagation between views. However, since each of the views are in separate tools, this paper presents an initial effort for creating multiple views that are linked together by a common model in a common representation. Since the update and propagation of changes involve custom problem-specific rules, it

Multi-view Modeling to Support Embedded Systems Engineering in SysML

ibd [Block] Circuit [

Circuit ]

«block» cylinder : Cylinder

housing : Flange

A : Hydraulic

control : Control control : Control

B : Hydraulic

«block» directionalValve : DirectionalValve

«block» control : Control

P : Hydraulic

A : Hydraulic

rod : Translational

B : Hydraulic

A : Hydraulic

P : Hydraulic

587

«block» reliefValve : ReliefValve

T : Hydraulic

B : Hydraulic

«block» pump : Pump T : Hydraulic

A : Hydraulic

«block» tank : Tank

B : Hydraulic

Common SysML Model

Fig. 4. A common model representation of a log splitter in SysML. The EPLAN view does not need control system models while the Modelica view does not require layout information. However, both are represented in SysML as black-boxes which can further be developed in the respective tools and languages.

is not considered in this paper; however such rules can be included within the method presented. 3.2

Formal Capture of Domain Knowledge Using Metamodels

When dealing with domain-specific views of a system, a formal representation of each view provides a more structured and object-oriented representation to interpret. This is normally done through internal data-models that are customized for a particular domain-specific software package. The structure of these internal data-models is often captured only in the source code of the software package. Therefore, to integrate multiple views, the first step is to represent each domain or tool formally in a common format through the use of metamodels. A metamodel is a “model used to model modeling itself” [2]. In other words, a metamodel for a domain is a model that specifies the possible concepts that can

588

A.A. Shah et al.

Cylinder Project

Valve Pump

Pin Device

Fig. 5. A schematic for an Electro-hydraulic Log Splitter represented in EPLAN. From the common model in SysML, an EPLAN view is created in which a designer adds knowledge related to the layout of the system.

slidingMass

Cylinder

fixed

A

B

Cylinder valve4_3... A B

Valve P

A

Pump constantSpeed

j1

controller

T

B

reliefValve

j2

P

circuitTank constantDi... T

Dynamic Simulation in Modelica

Fig. 6. A dynamic simulation model for the log splitter in Modelica. Similar to the EPLAN view, the Modelica view is created from the common model in SysML. The designer adds knowledge related to the control system and then performs an analysis of the system.

Multi-view Modeling to Support Embedded Systems Engineering in SysML

589

exist within that domain. Each view of a system is therefore an instance of a metamodel defined for its domain. To support model and metamodel driven systems, OMG established the Meta Object Facility (MOF) [2] standard. MOF provides a methodology and framework for “defining, manipulating, and integrating meta-data and data in a platform independent manner” [2,22]. The approach we have taken is to specify explicitly the metamodel reconstructed from the API of the tool with which interoperability is desired [23]. This is a conversion of the implicit metamodel (i.e., the data structures used internally to the tool and only made visible through its API targeted for general purpose programming languages like C++) into a formal and explicit metamodel compliant with the MOF standard. The MOF compliant meta-CASE tool MOFLON [13] is used to define the metamodels for all of the domains involved. As an example, the abstract syntax of EPLAN Electric P8, which is accessible through its API, is explicitly defined in terms of a metamodel in MOFLON, of which a small part is shown in Fig. 7. EPLAN constructs, such as Project, Page, Function, Connection are specified as classes while the relationships between the constructs are specified as associations (ProjectHasPages, PageHasDevices, etc.).



           !   
     

 





 
 



            

      




 



  
 


   








 


   

 











 

 






  


         






Fig. 7. A part of a metamodel for EPLAN defined in MOFLON.

A similar approach is taken to define a metamodel for Modelica. In contrast to EPLAN, the abstract syntax of Modelica is contained within another metamodeling language known as Meta-Modelica [24]. Therefore, using the Modelica metamodel as a guide, a corresponding MOF metamodel is defined, as shown in Fig. 8.

590

A.A. Shah et al.    

 



   






 



 









    

 
 
     





 
 







   

Fig. 8. Part of metamodel for Modelica defined in MOFLON.

In both cases, only those portions of the language that are needed for defining the required transformations are captured within each MOF metamodel. The metamodels can be modified to incorporate more features of the language as well as ensure compatibility with new versions. After defining each domain by an explicit MOF metamodel, it is necessary to customize SysML to enable transformation between an instance of the metamodel and a corresponding instance in SysML. This is done through the use of SysML profiles and model libraries, which is the next step in our framework for multi-view modeling. 3.3

Domain Specific Modeling in SysML

In order for SysML to be used as a bridge between multiple domains, the necessary semantics from each of the domains must be included within SysML. However, since SysML is a general purpose modeling language, it lacks the detailed, formal semantics needed to represent specific views in an executable format [25]. For instance, a model that is described using generalized constructs such as SysML Blocks is just a visual representation. It cannot be executed, unlike a Modelica or Simulink model that can be simulated or an EPLAN model that can be used to create assembly schematics or a Bill of Materials. In addition, it can be cumbersome for domain experts to create models in SysML, thereby limiting the acceptance of general SysML for specific domains. To overcome this limitation, SysML can be customized to define semantics specific to a domain. Indeed, most UML / SysML tools allow for a broad range of customizations through the use of Domain Specific Languages (DSLs) and corresponding modifications to the graphical user interface. Among the various approaches available to define DSLs in SysML [26], profiles are preferred since they do not modify the underlying SysML metamodel so that SysML tool support is retained. A portion of a SysML profile created for EPLAN is shown in Fig. 9. The profile is constructed as per the MOF metamodel (Fig. 7).

Multi-view Modeling to Support Embedded Systems Engineering in SysML

591

Language constructs specific to the EPLAN (e.g., Page and Device) are defined as stereotypes that extend existing SysML and UML constructs, such as the Block metaclass of SysML.

pkg [Profile] EPLAN[

EPLANProfile]

FlowPort [Port]

Block [Class]

-direction : FlowDirection [1] = inout -isConjugated : Boolean = false -/isAtomic : Boolean

-isEncapsulated : Boolean

EplanProject [Class]

Device [Class]

-projectName : String -projectFullPath : String -fullInstallationNumber : Integer

-fullDT : String -category : Category -SupplementaryField : String [0..*] -Pins : Pin [0..*]

Category Cylinder FixedDisplacementPump DirectionalControlValve Filter Accessories Distributor Valve

Pin [Port] -targetPin : Pin [0..*]

FluidPin [Port]

ElectricalPin [Port]

-targetPin : FluidPin [0..*]

-targetPin : ElectricalPin [0..*]

Fig. 9. A Profile for EPLAN in SysML. Stereotypes such as EplanProject, Device, Pin represent constructs used in EPLAN.

A profile is also defined to represent Modelica simulation models in SysML. Rather than creating a stereotype for every language construct of Modelica, only the subset of constructs necessary for capturing the model interfaces is modeled. Such “black box” models refer to externally defined Modelica models for their internal details. The SysML profile includes the full path to the library and the specific model within it [27], as is shown in Fig. 10. Using these profiles, one can represent any EPLAN or Modelica model within SysML, and then establish the dependencies between them using the common model. To facilitate this process, it would be convenient to map entire libraries of models to their corresponding SysML-profile versions so that they can be referenced by systems engineers working in a SysML tool. At present, these SysML model libraries are created manually but the process could be automated by using a tool’s internal API (e.g., as for EPLAN) or by parsing through a model library file (e.g., as for Modelica). By storing models that reference preexisting tool-specific models, the designer’s need to know detailed syntax for each tool is reduced. Consequently, a designer can focus more on the problem to be solved instead of having to learn the syntax of each tool. In conclusion, the combination of profiles and model libraries with metamodels provides the framework in which model transformations can be applied to integrate multiple views. This is discussed further in the next section.

592

A.A. Shah et al.

pkg [Profile] Library [

Library ]

ExternalLibraryModel [Class] +ref : String [1] = FluidPower.Components.Cylinders.DoubleActingCylinder +url : String = C:\Program Files\Dymola\Modelica\Library\Modelica 2.2.1\package.mo +library : Block [1] = FluidPowerLibrary



ExternalLibrary [Class]

Block [Class]

+url : String = C:\Program Files\Dymola\Modelica\Library\Modelica 2.2.1\package.mo

-isEncapsulated : Boolean



Simulation [Class] +startTime [1] = 0 +stopTime [1] = 10 +analysis : Block [1]

Fig. 10. A Library profile is used to capture model library elements. Stereotypes such as ExternalLibrary and ExternalLibraryModel are used to specify the reference locations that point to the actual tool-specific models.

3.4

Model Transformations to Generate Domain-Specific Views

Once all of the domains are represented by MOF metamodels and SysML profiles, transformation rules can be defined both create domain-specific views in SysML from the common model and create domain-specific tool representations of the views. Model transformations are commonly used to convert a model in one domain (the source model) to a model in another domain (the target model), as is shown in Fig. 11. When creating domain-specific SysML views, the source model is the common SysML model and the target is a domain-specific view in SysML. For generating domain-specific tool representations, the source model becomes the domain-specific SysML view. Since both metamodels and SysML profiles can be described in terms of graphs [10], graph transformations can be used to integrate between the different views and models. In this case, the domain semantics (metamodel and profile objects) represent the nodes, and associations represent the edges.


   

 

 


    

 

 

   

  

     

 

  

Fig. 11. Process of model transformation from Source to Target model (Czarnecki et al. [28]

Multi-view Modeling to Support Embedded Systems Engineering in SysML

593

Also, many common transformation-based approaches can be used including OMG’s Queries / Views / Transformations (QVT) [29] and Triple Graph Grammars (TGG) [30] because both the source and target models are instances of formally defined metamodels. In our approach, story diagrams [31] are used to visually define rules for the transformations between different views. These rules are TGG-like in that they use a correspondence graph that captures the relationships between source and target model. Just as in TGGs, the correspondence graph is defined by a correspondence metamodel [22,30]. For instance, in Fig. 12 a correspondence metamodel is used to link objects of a SysML view to objects in an EPLAN tool specific view. The object DeviceBlock2Device links a Block object in SysML to a Device object in the Electrical CAD (ECAD) domain, just as the stereotype Device is a generalization of the Block metaclass in the SysML profile. Story diagrams are used because they allow the inclusion of API specific code.



  


 



   

   








 










 

      

  











  








   


  



 
 





  

   

 



 





 

 






 





  

  




Fig. 12. Correspondence metamodel between SysML and EPLAN. It is used to maintain relation between elements of different views. A Block in SysML is related to a MOF object of class Project through the correspondence MOF object of class EplanProjectBlock2Project.

Unlike TGGs, the story diagrams presented are not specifications of bidirectional transformation rules and therefore rules are required in each direction. For instance, rules are defined between the common model and the structural view in SysML, between the structural view in SysML and EPLAN, between the common model and the Modelica view in SysML, and finally between the Modelica view in SysML and the executable simulation in Modelica. The transformations are defined using a Meta-CASE (Computer Aided Software Engineering) tool called MOFLON [13], which simplifies the overall process with its modeling and automated code generating capabilities. A disadvantage of story diagrams is the need to specify the order of execution within the specification. Consequently, custom story diagrams are needed to implement problem-specific consistency management. Also, custom diagrams

594

A.A. Shah et al.

would be needed to do incremental model construction. This is in contrast to TGG approaches in which consistency management rules can automatically be derived from the transformation specification such as in work by K¨ onigs and Sch¨ ur [32]. TGGs can also be modified for incremental model construction as shown in work by Griese and Wanger [33]. In Fig. 13, a story diagram is shown that takes as input a SysML block (stereotyped with EplanProject) that contains path information for an EPLAN project file (LogSplitter.elk) and creates a Project object as per the EPLAN metamodel as well as updates the EPLAN project with information such as ProjectName. Other transformations (not shown) are then executed in order to fill in the EPLAN project from the SysML view. For instance, a transformation is defined that finds all the SysML blocks stereotyped as Device and creates devices in the EPLAN project along with the corresponding connections between them. Through such transformations, an input structural view in SySML as shown in Fig. 14 is converted into the corresponding EPLAN view as in Fig. 5. Not only can model transformations be used to create the entire model as shown here, they can also be defined to only propagate changes using correspondence information to find and update the appropriate model elements. Both the transformations from SysML to EPLAN and SysML to Modelica establish dependencies across different modeling environments, as illustrated in Fig. 2. In addition, it is necessary to capture the dependencies between different views and the common model within the SysML environment. For examples, the EPLAN profile can be used to describe the structure of electrical or hydraulic circuits within SysML. This structural view is related to a corresponding analysis view that can be represented using the Modelica profile and linked using the common model. It is often possible to define the dependencies between different systems views parametrically using SysML parametric diagrams, and this approach can be augmented with model transformations to create dependencies. Parametric dependencies alone are sufficient when the structure of the views remains the same and only the parameter values need to be modified or updated. However, in this case, it is quite common to change the topology of the different views also. A parametric mapping would have to be re-established each time the topology of the structure is modified, a cumbersome and error-prone process. The dependencies between the common model and domain-specific views have been modeled using model transformations. These model transformations embody the generic knowledge needed to create the domain-specific views from the knowledge available in the common model. These model transformations need to be complemented by domain-specific knowledge stored in mapping models, called Multi-Aspect Component Models (MAsCoMs) by Jobe et al. [34]. For instance, the EPLAN structural view contains a pump component, which refers only to the structural information about the pump: the type of pump, the key sizing parameters such as displacement and maximum pressure, and a product ID which are all present in the common model. With this information, a corresponding MAsCoM can be identified in a MAsCoM library, which in turn allows the model transformation to instantiate the appropriate EPLAN component model and

Multi-view Modeling to Support Embedded Systems Engineering in SysML

595

(3/$16\V0/HSODQ3URMHFW7R6\V0/3URMHFWV\VPO%ORFN%ORFN 3URMHF

V\VPO%ORFN

©FUHDWHª

VWHUHRW\SHG(OHPHQW

HSODQ3URMHFW 3URMHFW

$BDSSOLHG6WHUHRW\SH,QVWDQFHBVWHUHRW\SHG(OHPHQ DSSOLHG6WHUHRW\SH,QVWDQFH

RZQLQJ,QVWDQFH VORW VORW 6ORW $BVORWBLQVWDQFH6SHFLILFDWLRQ LQVWDQFH6SHF ,QVWDQFH6SHFLILFDWLRQ

RZQLQJ6ORW

SURMHFW)XOO3DWK  SURMHFW)XOO3DWK SURMHFW1DPH  V\VPO%ORFNQDPH

$BVORWBYDOXH6SHFLILFDWLRQ HFLILFDWLRQ

$BVORWBGHILQLQJ)HDWXUH

FODVVLILHUBLQVWDQFH6SHFLILFDWLRQ FODVVLILHU

YDOXH /LWHUDO6WULQJ

GHILQLQJ)HDWXUH

FODVVLILHU &ODVVLILHU QDPH

YDOXH

VORW

(SODQ3URMHFW

GHI 6WUXFWXUDO)HDWXUH QDPH

SURMHFW)XOO3DWK

8VLQJSDWKLQIRUPDWLRQFUHDWH(3/$1SURMHFWWKURXJK$3,IXQFWLRQFDOOV 6WULQJSURMHFW7HPSODWH)LOH3DWK &(3/$1,(&BWSOHSW 3URMHFW0DQDJHUSP QHZ3URMHFW0DQDJHU  3URMHFWS S SP&UHDWH3URMHFWSURMHFW)XOO3DWKSURMHFW7HPSODWH)LOH3DWK  SVHW3URMHFW1DPHHSODQ3URMHFWJHW1DPH 

HSODQ3URMHFW

SURMHFW

3URMHFW%ORFN

VES ©FUHDWHª

HSODQ3URMHFW6\V0/3URMHFW (SODQ3URMHFW%ORFN3URMHFW VES

%ORFN3URMHFW EORFN

V\VPO%ORFN

HSODQ3URMHFW

Fig. 13. A story diagram that creates an EPLAN project file with information from a SysML model. The input (sysmlBlock ) contains project location and through EPLAN’s API, project information is accessed and is added to the SysML input block.

596

A.A. Shah et al.

ibd [EplanProject] Circuit [

Circuit ]

«Device» : 4Way3PosOpenCenter

Valve in EPLAN 1

1

2

4 2

3 1 «Device» : Distributor1

«Device» : Cylinder

Cylinder in EPLAN

1e

2 3 1

«Device» : ReliefValve

1 2

«Device» : Distributor2 3

2 1 «Device» : FixedDisplacementPump

{direction = inout , targetPin = 1}

2

Pump in EPLAN

{direction = inout , targetPin = 3, 2}

«Device» : Tank

1

SysML EPLAN View (Derived from common SysML model)

Fig. 14. Model transformations are executed to convert this view in SysML to EPLAN. The SysML model is in the form of an Internal Block Diagram, within the block that corresponds to the EPLAN project.

establish the parametric dependencies. (See Fig. 15) Refer to [34] for the details of this mapping approach. In this same way, transformations are executed to generate a Modelica view in SysML from the corresponding common model in SysML, as shown in Fig. 16. Finally, once the Modelica model in SysML is generated, it is converted to executable Modelica code through model transformations defined on the Modelica metamodel (Fig. 8) and subsequent conversion to textual code through a tool integrator. The textual Modelica model can be executed in any Modelica solver such as the OpenModelica Compiler [35] or Dymola [36]. Figure 6 shows the generated Modelica model within Dymola. The model transformations discussed above are defined in MOFLON, which automatically generates JMI (Java Metadata Interface) code that implements the transformations in Java. This JMI code is combined with a JMI-compliant SysML tool, such as Magic Draw [37], in the form of a plugin. To handle the incompatibility of programming languages of different tools (e.g., EPLAN is based on .NET while Magic Draw and MOFLON are based on Java), interoperability software may be necessary to bridge the gap. In the implementation of this example, JnBridge Pro [38] has been used to access the EPLAN API from within a Java-based model transformation framework. In conclusion, through the successive execution of graph transformations, it is possible to generate several domain-specific views and domain-specific tool representations from a common model in SysML, thereby integrating tools that are otherwise incompatible with each other and encoding knowledge that would otherwise require manual regeneration of views each time the system topology changes.

Multi-view Modeling to Support Embedded Systems Engineering in SysML

SDU >%ORFN@&RQWH[W >

597

&RQWH[W @

HSODQ&LUFXLW&LUFXLW

FLUFXLW&LUFXLW

)L[HG'LVSODFHPHQW3XPS

PRGHOLFD&LUFXLW&LUFXLW

SXPS3XPS

SXPS&RQVWDQW'LVSODFHPHQW3XPS

WDQN7DQN

WDQN&LUFXLW7DQN

5HOLHI9DOYH

UHOLHI9DOYH5HOLHI9DOYH

UHOLHI9DOYH5HOLHI9DOYH

&\OLQGHU

F\OLQGHU&\OLQGHU

GRXEOH$FWLQJ&\O'RXEOH$FWLQJ&\OLQGHU

:D\3RV2SHQ&HQWHU

GLUHFWLRQDO9DOYH'LUHFWLRQDO9DOYH

7DQN

FRQWURO&RQWURO

YDOYH9B2&9DOYH%ORFN

FRQWUROOHU&RQWUROOHU

'LVWULEXWRU M1-XQFWLRQ 'LVWULEXWRU

M1-XQFWLRQ

IL[HG)L[HG FRQVWDQW6SHHG&RQVWDQW6SHHG VOLGLQJ0DVV6OLGLQJ0DVV

Fig. 15. Dependencies between the common model and domain-specific views in SysML.

ibd [Block] Circuit [

Circuit ]

«ExternalLibraryModel» fixed1 : Fixed

«ExternalLibraryModel» doubleActingCyl1 : DoubleActingCylinder

flange_a : Flange_a «ExternalLibraryModel» slidingMass1 : SlidingMass

flange_b : Flange_b port_a : FlowPort

Cylinder in Modelica

flange_b : Flange_b

port_b : FlowPort B : FlowPort

A : FlowPort

«ExternalLibraryModel» valve1 : V4_3OCValveBlock y : RealOutput

Valve in Modelica

u : RealInput [1..*]

«ExternalLibraryModel» controller : Controller flange_a : Flange_a

«ExternalLibraryModel» j1 : NJunction

«ExternalLibraryModel» pump : ConstantDisplacementPump

«ExternalLibraryModel» constantSpeed : ConstantSpeed

«ExternalLibraryModel» reliefValve : ReliefValve

«ExternalLibraryModel» j2 : NJunction1

Pump in Modelica

«ExternalLibraryModel» tank : CircuitTank

SysML Modelica View (Derived from common SysML model)

Fig. 16. Model transformations are executed to convert the common model in SysML to a Modelica model in SysML. The SysML model is in the form of an Internal Block Diagram.

598

4

A.A. Shah et al.

Discussion and Closure

In this paper, the use of SysML profiles and model transformations for multiview modeling of embedded systems is discussed. Embedded systems are becoming more prevalent, resulting in the increasing use of software throughout a variety of systems [14]. Although considerable research has been done for the automation of software development through UML, little effort has been focused on the model-based engineering of entire systems, including both software and hardware. To support the development of embedded systems, no single language such as UML or SysML can effectively capture all of the needed information. For instance, SysML is well-suited for defining the high-level relationships that exist between requirements, structure, and behavior. It is not suited for specifying schematics for assembly (EPLAN’s function) or simulating control systems and dynamic system behavior (Modelica’s function). Therefore, the method presented in this paper integrates multiple views that involve different knowledge (structural or analysis knowledge), thereby leveraging the capabilities of different domain-specific tools. As a result, one can synergistically combine the strengths of multiple modeling languages and tools. In SysML, the designer can trace requirements to desired behavior or allocate functions to structural components; these capabilities can now be combined with the modeling views created in tools that are specifically tailored for authoring or analyzing systems in formalisms with which domain specialists are most familiar. However, as shown in the previous section, there are a number of challenges still to be addressed when creating a general framework for multi-view modeling. A major research question involves determining an effective way maintain consistency in a problem independent fashion. This is in contrast to the current approach of using problem specific update and propagation rules [20]. But it is not clear which approach is most suitable for maintaining and managing consistency between the different views. Ideally, a general framework must also take into account the work flow process, to allow consistency to be evaluated and reestablished periodically but not enforced all the time. This process is likely to require human involvement to resolve inconsistencies when multiple views cannot be reconciled without ambiguity. These challenges are applicable to any framework and we believe that the model-based framework demonstrated in this paper is sufficiently flexible to accommodate extensions that will address these challenges. Moreover, additional design capabilities such as the design synthesis algorithms by Kerzhner and Paredis [27] and Helms et al. [39] can benefit from the model-based framework defined in the paper. In conclusion, the framework presented in this paper is an approach that we believe is not restricted to any particular domain and can serve as a step towards the unification of the various domains involved in embedded systems design. Acknowledgments. This work has been funded by Deere & Company. Additional support was provided by the ERC for Compact and Efficient Fluid Power, supported by the National Science Foundation under Grant No. EEC-0540834.

Multi-view Modeling to Support Embedded Systems Engineering in SysML

599

The authors would like to thank Roger Burkhart, Sanford Friedenthal, Leon McGinnis, and Russell Peak for the discussions that helped crystallize the ideas presented in this paper. No Magic Inc. provided access to its MagicDraw UML/SysML tool, EPLAN Software & Services LLC provided access to Electric P8, and JNBridge LLC. provided access to JNBridgePro. Their in-kind support is gratefully acknowledged.

References 1. OMG: Systems Modeling Language v 1.1 (2008), http://www.omg.org/docs/formal/08-11-02.pdf 2. OMG: Meta Object Facility (MOF) Core Specification v 2.0. (2006), http://www.omg.org/docs/formal/06-01-01.pdf 3. OMG: Model Driven Architecture, http://www.omg.org/mda/ 4. Kovse, J., H¨ arder, T.: Generic XMI-Based UML Model Transformations. In: Bellahs`ene, Z., Patel, D., Rolland, C. (eds.) OOIS 2002. LNCS, vol. 2425, pp. 183–190. Springer, Heidelberg (2002) 5. Lubell, J.: From Model to Markup: XML Representation of Product Data. In: XML 2002 Conference (2002) 6. Chen, K., Schaefer, D.: MCAD - ECAD Integration: Overview and Future Research Perspectives. In: ASME International Mechanical Engineering Congress and Exposition, ASME (2007) 7. Alexander, B., Lian, D., Manjula, P.: An Approach to Accessing Product Data Across System and Software Revisions. Advanced Engineering Informatics 22(2), 222–235 (2008) 8. Sendall, S., Kozaczynski, W.: Model Transformation: The Heart and Soul of ModelDriven Software Development. Software, IEEE 20(5), 42–45 (2003) 9. Czarnecki, K., Helsen, S.: Classification of Model Transformation Approaches. In: 2nd OOPSLA Workshop on Generative Techniques in the Context of the Model Driven Architecture (2003) 10. Baresi, L., Heckel, R.: Tutorial Introduction to Graph Transformation: A Software Engineering Perspective. In: Corradini, A., Ehrig, H., Kreowski, H.-J., Rozenberg, G. (eds.) ICGT 2002. LNCS, vol. 2505, pp. 402–429. Springer, Heidelberg (2002) 11. Giese, H., Levendovszky, T., Vangheluwe, H.: Summary of the Workshop on MultiParadigm Modeling: Concepts and Tools. In: K¨ uhne, T. (ed.) MoDELS 2006. LNCS, vol. 4364, pp. 252–262. Springer, Heidelberg (2007) 12. Fujaba: Fujaba Tool Suite, http://wwwcs.uni-paderborn.de/cs/fujaba/ 13. MOFLON: MOFLON Homepage, http://moflon.org/ 14. Selic, B.: From Model-Driven Development to Model-Driven Engineering. In: Keynote talk at ECRTS 2007 (2007) 15. Vanderperren, Y., Dehaene, W.: SysML and Systems Engineering Applied to UMLBased SoC Design. In: UML-SoC Workshop at 42nd DAC, 2005 (2005) 16. Espinoza, H., Cancila, D., Selic, B., G´erard, S.: Challenges in Combining SysML and MARTE for Model-Based Design of Embedded Systems. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 98–113. Springer, Heidelberg (2009) 17. Friedenthal, S., Moore, A., Steiner, R.: A Practical Guide to SysML: The Systems Modeling Language. Morgan Kaufmann, San Francisco (2008)

600

A.A. Shah et al.

18. EPLAN: EPLAN Electric P8, http://www.eplanusa.com/ 19. Modelica: Modelica Language Specification v 3.1. (2009), http://www.modelica.org/documents/ModelicaSpec31.pdf 20. Gausemeier, J., Sch¨ afer, W., Greenyer, J., Kahl, S., Pook, S., Rieke, J.: Management of Cross-Domain Model Consistency during the Development of Advanced Mechatronic Systems. In: Bergendahl, N., Grimheden, M., Leifer, L., Skogstad, P., Lindemann, U. (eds.) Proceedings of the 17th International Conference on Engineering Design (ICED 2009). Design Methods and Tools, vol. 6, pp. 1–12 (2009) 21. Bajaj, M., Paredis, C.J.J., Rathnam, T., Peak, R.: Federated Product Models for Enabling Simulation-Based Product Lifecycle Management. In: Proceedings of ASME International Mechanical Engineering Congress and Exposition (2005) IMECE2005-81663 22. K¨ onigs, A., Sch¨ urr, A.: Tool Integration with Triple Graph Grammars - A Survey. Electronic Notes in Theoretical Computer Science 148(1), 113–150 (2006) 23. Czarnecki, K.: Overview of Generative Software Development. In: Banˆ atre, J.-P., Fradet, P., Giavitto, J.-L., Michel, O. (eds.) UPP 2004. LNCS, vol. 3566, pp. 326– 341. Springer, Heidelberg (2005) 24. Pop, A., Fritzson, P.: MetaModelica: A Unified Equation-Based Semantical and Mathematical Modeling Language. In: Lightfoot, D.E., Szyperski, C.A. (eds.) JMLC 2006. LNCS, vol. 4228, pp. 211–229. Springer, Heidelberg (2006) 25. Brucker, A.D., Doser, J.: Metamodel-based UML Notations for Domain-specific Languages. In: 4th International Workshop on Software Language Engineering (ATEM 2007) (2007) 26. Weisem¨ oller, I., Sch¨ urr, A.: A Comparison of Standard Compliant Ways to Define Domain Specific Languages. In: Giese, H. (ed.) MODELS 2008. LNCS, vol. 5002, pp. 47–58. Springer, Heidelberg (2008) 27. Kerzhner, A.A., Paredis, C.J.J.: Using Domain Specific Languages to Capture Design Synthesis Knowledge for Model-Based Systems Engineering. In: ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference 2009, ASME (2009) DETC2009–87286 28. Czarnecki, K., Helsen, S.: Feature-Based Survey of Model Transformation Approaches. IBM Systems Journal 45(3), 621–645 (2006) 29. OMG: Meta Object Facility (MOF) 2.0 Query / View / Transformation v1.0. (2008), http://www.omg.org/docs/formal/08-04-03.pdf 30. Sch¨ urr, A.: Specification of graph translators with triple graph grammars. In: Mayr, E.W., Schmidt, G., Tinhofer, G. (eds.) WG 1994. LNCS, vol. 903, pp. 151–163. Springer, Heidelberg (1995) 31. Fischer, T., Niere, J., Torunski, L., Z¨ undorf, A.: Story Diagrams: A New Graph Rewrite Language Based on the Unified Modeling Language and Java. In: Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764, pp. 157–167. Springer, Heidelberg (2000) 32. K¨ onigs, A., Sch¨ urr, A.: MDI: A rule-based multi-document and tool integration approach. Software and Systems Modeling 5(4), 349–368 (2006) 33. Giese, H., Wagner, R.: From model transformation to incremental bidirectional model synchronization. Software and Systems Modeling 8(1), 21–43 (2009) 34. Jobe, J.M., Paredis, C.J.J., Johnson, T.A.: Multi-Aspect Component Models: A Framework for Model Reuse in SysML. In: 2008 ASME International Design Engineering Technical Conferences and Computers in Information Engineering Conference (2008)

Multi-view Modeling to Support Embedded Systems Engineering in SysML

601

35. OpenModelica: The OpenModelica Project, http://www.ida.liu.se/~ pelab/modelica/OpenModelica.html 36. Dymola: Dymola, http://www.3ds.com/products/catia/portfolio/dymola 37. NoMagic: MagicDraw, http://www.magicdraw.com 38. JNBridge: JNBridgePro, http://www.jnbridge.com/jnbpro.htm 39. Helms, B., Shea, K., Hoisl, F.: A Framework for Computational Design Synthesis Based on Graph-Grammars and Function-Behavior-Structure. In: 2009 ASME International Design Engineering Technical Conferences and Computers in Information Engineering Conference, ASME (2009) DETC2009–86851