Model and Tool Integration in High Level Design of Embedded Systems

TRITA – MMK 2007:10 ISSN 1400-1179

ISRN/KTH/MMK/R-07/10-SE

Licentiate thesis Department of Machine Design Royal Institute of Technology SE-100 44 Stockholm

JIANLIN SHI

TRITA – MMK 2007:10 ISSN 1400-1179 ISRN/KTH/MMK/R-07/10-SE

Model and Tool Integration in High Level Design of Embedded Systems

Jianlin Shi

Licentiate thesis

Academic thesis, which with the approval of Kungliga Tekniska Högskolan, will be presented for public review in fulfilment of the requirements for a Licentiate of Engineering in Machine Design. The public review is held at Kungliga Tekniska Högskolan, Brinellvägen 83, A425 at 2007-12-20.

TRITA - MMK 2007:10 ISSN 1400 -1179 ISRN/KTH/MMK/R-07/10-SE

Mechatronics Lab Department of Machine Design Royal Institute of Technology S-100 44 Stockholm SWEDEN

Document type Licentiate Thesis

Date 2007-12-20

Supervisor(s) Martin Törngren, Dejiu Chen

Author(s) Jianlin Shi (jianlin@md.kth.se)

Title Model and Tool Integration in High Level Design of Embedded Systems

Sponsor(s) SSF (through the SAVE and SAVE++ projects), VINNOVA (through the Modcomp project), and the European Commission (through the ATESST project)

Abstract The development of advanced embedded systems requires a systematic approach as well as advanced tool support in dealing with their increasing complexity. This complexity is due to the increasing functionality that is implemented in embedded systems and stringent (and conflicting) requirements placed upon such systems from various stakeholders. The corresponding system development involves several specialists employing different modeling languages and tools. Integrating their work and the results thereof then becomes a challenge. In order to facilitate system architecting and design integration of different models, an approach that provides dedicated workspaces/views supported by structured information management and information exchange between domain models and tools is required. This work is delimited to the context of embedded systems design and taking a model based approach. The goal of the work is to study possible technical solutions for integrating different models and tools, and to develop knowledge, support methods and a prototype tool platform. To this end, this thesis examines a number of approaches that focus on the integration of multiple models and tools. Selected approaches are compared and characterized, and the basic mechanisms for integration are identified. Several scenarios are identified and further investigated in case studies. Two case studies have been performed with model transformations as focus. In the first one, integration of Matlab/Simulink® and UML2 are discussed with respect to the motivations, technical possibilities, and challenges. A preliminary mapping strategy, connecting a subset of concepts and constructs of Matlab/Simulink® and UML2, is presented together with a prototype implementation in the Eclipse environment. The second case study aims to enable safety analysis based on system design models in a UML description. A safety analysis tool, HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies), is partially integrated with a UML tool where an EAST-ADL2 based architecture model is developed. The experience and lessons learned from the experiments are reported in this thesis. Multiple specific views are involved in the development of embedded systems. This thesis has studied the integration between system architecture design, function development and safety analysis through using UML tools, Matlab/Simulink, and HiP-HOPS. The results indicate that model transformations provide a feasible and promising solution for integrating multiple models and tools. The contributions are believed to be valid for a large class of advanced embedded systems. However, the developed transformations so far are not really scalable. A systematic approach for efficient development of model transformations is desired to standardize the design process and reuse developed transformations. To this end, future studies will be carried out to develop guidelines for model and tool integration and to provide support for structured information at both meta level and instance level.

Keywords Model integration, Model transformation, Tool integration, Model based development, Embedded Systems

Language English

-I-

Acknowledgement

This work is realized at RTC group in Department of Machine Design. I would first like to express my appreciation to Professor Martin Törngren for introducing me into such a fantastic research field and being my supervisor. Also I would like to thank him and my co-supervisor Dr. DeJiu Chen for the indispensable guidance, endless inspirations, valuable encouragements and practical support. Without their help, this thesis won’t be finished on time. Also thank Martin for leading the physical exercises – the badminton time.

I would like to thank my previous co-supervisor Ola Redell for those fruitful advices and instructions.

Thanks also go to all members of the research group, current and old, for providing a pleasant environment and the collaboration.

Also my thoughts go to all at the department, the administration team, the IT team and the workshop team.

I would also like to thank the SSF (through the SAVE and SAVE++ projects), the Swedish Governmental Agency for Innovation Systems, i.e., VINNOVA (through the Modcomp project), and the European Commission (through the ATESST project) for supporting my work.

Finally I would like to thank my wife, Yu Wang for the understanding and support in my work! Regards are also given to my parents who are always supporting me.

Thank you all!

Stockholm, 30 November 2007

Jianlin Shi

-II-

-III-

List of Appended Publications

Paper A:

J. Shi, M. Törngren, D. Servat, C.J. Sjöstedt, D. Chen, and H. Lönn, "Combined Usage of UML and Simulink in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioural Mapping". On the 4th workshop of "Object-oriented Modeling of Embedded Real-time Systems", Paderborn, Germany, Oct. 2007

The work presented was a result of collaboration between the authors. Jianlin Shi conducted the design and tool implementation. Martin Törngren provided advice on many concepts and the writing. David Servat provided input on UML2 behaviour concepts. Other authors also assisted in discussing and provided input on the conceptual mapping.

Report B:

J. Shi, D. Chen, and M. Törngren, “Case Studies on integrating Simulink, UML and Safety Analysis through Model Transformations”, Technical report, TRITA-MMK 2007:12, ISSN 1400-1179, ISRN/KTH/MMK/R-07/12-SE

The tool and algorithms presented are implemented by Jianlin Shi. Dejiu Chen performed the error modelling and assisted in writing. The design of the transformations was carried out in close cooperation between the authors.

-IV-

Other Publications

• J. Shi and M. Törngren, An Overview of UML2.0 and Brief Assessment from the Viewpoint of Embedded Control Systems Development, TRITA-MMK 2005:11, ISSN 1400-1179, ISRN/KTH/MMK/R-05/11-SE, 2005

• D. Chen, M. Törngren, J. Shi, S. Gerard, H. Lönn, D. Servat, M. Strömberg, and 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. 2006.

• J. Shi and M. Törngren, A Brief Evaluation and Overview of UML2.0 from the Viewpoint of Embedded Control Systems, 8th Real-time in Sweden 2005-RTiS conference, Skövde, Sweden. Aug. 2005.

• J. Shi, M. Törngren, J. El-khoury, and O. Redell, “Model and tool integration in embedded system development – a survey of state of the art”, Technical report, TRITA-MMK 2007:11, ISSN 1400-1179, ISRN/KTH/MMK/R-07/11-SE, 2007

-1-

Table of Content

Acknowledgement ..........................................................................................................I

List of Appended Publications.....................................................................................III

Other Publications........................................................................................................IV

Table of Content ............................................................................................................1

Abbreviations.................................................................................................................3

1 Introduction............................................................................................................5

1.1 Background ....................................................................................................5

1.2 Outline of the thesis .......................................................................................6

1.3 Basic concepts definition ...............................................................................6

2 Problem Formulation .............................................................................................9

2.1 System integration: interpretations, purposes and solutions..........................9

2.2 Delimitations................................................................................................11

2.3 Requirements and challenges.......................................................................13

3 Research goals, questions and approaches...........................................................15

3.1 Aim and purpose ..........................................................................................15

3.2 Research questions.......................................................................................15

3.3 Research approaches....................................................................................15

3.4 Contributions................................................................................................16

3.5 Validity ........................................................................................................17

4 The state-of-the-art approaches............................................................................18

4.1 Related early work on tool integration.........................................................18

4.2 Multi-paradigm modeling ............................................................................19

4.3 Model transformations .................................................................................21

4.4 Standard exchange formats ..........................................................................23

4.5 Systems modeling languages .......................................................................24

4.6 Model integration platforms ........................................................................25

4.7 PDM/SCM integration .................................................................................29

5 Framework and discussions .................................................................................30

5.1 Discussions on selected approaches.............................................................30

-2-

5.2 Integration scenarios ....................................................................................35

5.3 Comparison framework ...............................................................................38

6 Case studies..........................................................................................................43

6.1 Background ..................................................................................................43

6.2 Integrating Simulink and UML2..................................................................45

6.3 Integrating HiP-HOPS and system architecture design ...............................50

6.4 Experience and lessons learned ...................................................................53

7 Conclusion and future work.................................................................................55

References....................................................................................................................57

-3-

Abbreviations

AADL – Architecture Analysis & Design Language

ADL – Architecture Description Language

API – Application Programming Interface

ATL – Atlas Transformation Language

CAx – Computer Aided X (anything)

CAD – Computer Aided Design

CAE – Computer Aided Engineering

CACE – Computer Aided Control Engineering

CASE – Computer Aided Software Engineering

CAI – Computer Aided Integration

CBD – Component Based Development

CORBA – Common Object Request Broker Architecture

COTS – Commercial Off-the-Shelf

CMM – Capability Maturity Model

CVS – Concurrent Version System

ECS – Embedded Control Systems

ECU – Electronic Control Unit

EMF – Eclipse Modeling Framework

FEAF – Federal Enterprise Architecture Framework

FFA – Functional Failure Analysis

FTA – Fault Tree Analysis

GUI – Graphical User Interface

JMI – Java Metadata Interface

IAF – Integrated Architecture Framework

MDA – Model Driven Architecture

MBD – Model Based Development

MDE – Model Driven Engineering

MoCC – Model of Computation and Communication

MoC – Model of Computation

-4-

MOF – Meta-Object Facility

OMG – Object Management Group

PDM – Product Data Management

PIM – Platform Independent Model

PSM – Platform Specific Model

SCM – Software Configuration Management

SysML – System Modelling Language

STEP – Standard for the Exchange of Product Model Data

PSL – Process Specification Language

UML – Unified Modelling Language

XML – Extensible Makeup Language

XMI – XML Metadata Interchange

XSL – Extensible Stylesheet Language

XSLT – XSL Transformations

-5-

1 Introduction

1.1 Background With the introduction of electrics/electronics and software into traditional mechanical engineering products, the usage of embedded systems are greatly increased. As a consequence, existing devices are largely improved and provided with complete new functionalities by integrating mechanical, electronic, software, and control system components. Example products of such integrated embedded systems include different types of vehicles, medical equipments, robotics, and manufacturing equipments. The concept of developing such systems is often referred to as a mechatronics approach in development [121]. Such an approach requires achieving synergistic effects from subsystems integration, and normally has the emphasis on co-design and systems optimization according to expected system qualities. Some typical product qualities of concern are dependability, real-time timeliness, performance, reliability, safety, security, and resource utilization.

However, as another consequence, product complexity is becoming a serious problem. One source of the complexity is due to the increasing functionality that is implemented in embedded systems. More functions are desired in modern products, many of which are more software-dependent. There is a dramatically increasing use of software-based functions in embedded systems with the introduction of computer technology. For example, [41] stated that “The amount of software in a car is doubling every two to three years,” and "it will increase to about one-third the cost of a car in the next few years”. Commonly, many systems functions are interdependent and need to cooperate with each other to gain expected system behavior. The dependencies between those functions then further bring more complexity for product development.

The complexity comes also from the requirements put on embedded systems. These requirements are stringent and often are even conflicting with each other. For example, from a control engineer’s point of view one obvious concern of an embedded system is the core motion control functionality and the dynamic behavior of this system, where the control logic and algorithms are especially important considerations. However, another concern from a hardware developer may be the processor resource. There are also many other aspects of the system, examples of which may include performance, safety, cost, security, network communication, geometrical design, IO, and power.

When dealing with the system development complexity, multidisciplinary and multiple engineering teams become necessary, where a complex system is divided into multiple views, e.g., mechanics, software, and control. Each view presents models and information that are of relevance for a particular aspect of the design and development [34]. These various views are further decomposed into detail in the corresponding areas, where they are handled by specialists employing varied methodologies and tools due to diverse design patterns and traditions in different engineering areas. For example, in

-6-

development of automotive embedded systems the design of control functionality is often based on Matlab/Simulink [72], whereas the design of overall system architecture as well as the implementation could be based on UML (Unified Modeling Language) [118] or its extensions like SysML (Systems Modeling Language) [109]. This leads to the result that the information used during system development (and also in later life-cycle stages) is distributed and has to be transferred among the engineering teams in order to support efficient decision-making, communication and documentation. However, there are complicated dependencies and overlapping information between different groups involved in the system development lifecycle, which cause difficulties in maintaining information consistency. Frequent design changes made in individual groups make this even more challenging.

As a summary, the richness of systems content and internal dependency, the conflict of requirements, and the heterogeneity of methods bring challenging problems [60]. For successful system development, these complexities need to be efficiently managed to reduce inconsistencies, conflicts, and costs when integrating different aspects into a system whole. As a consequence, the design task of advanced and complex embedded systems requires a systematic approach to manage the concurrent development of mechanical, electronic, software and control system components, which supports various dependencies and frequent integration.

There is an increasing industrial interest and research work addressing this by supplying different solutions, e.g., providing methodology and tool support for across domain collaboration [6]. One example is the ATESST project [8], where this thesis was partly performed. The ATESST project aims to develop an architecture description language, i.e., EAST-ADL2, to support structured system information management for complex automotive software development.

1.2 Outline of the thesis In this thesis, Section 1 introduces the background of the work. Section 2 explains basic concepts, identifies the need, formulates the problems and delimits the focus. Section 3 introduces the goals, research questions, approaches and main results. These goals and results are further elaborated in Section 4 to 6. Section 4 reviews related works and state-of-the-art solutions addressing model and tool integration. Section 5 discusses selected approaches, identifies integration scenarios, and presents a developed framework for integration, followed by case studies described in section 6. Some additional detail information on the studied model integration approaches is provided in [102]. More discussions on the case studies are given in Paper A and Report B. Finally Section 7 draws conclusions and discusses future work.

1.3 Basic concepts definition Configuration management: Defined as “a discipline applying technical and administrative direction and surveillance to identify and document the functional and

-7-

physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.”[49]. it is concerned with the issues such as version control and use access control.

Consistency: The coherence and uniformity among system components. To keep consistent in related objects, following functionalities must be supported [43] [103]: 1) navigating related objects; 2) propagating changes in related objects; and 3) detecting objects that violate consistent condition.

Extensibility: The capability of a platform to integrate new tools. The term “flexibility” of a platform used in this thesis has the same meaning.

Information model: An information model is used to define system entities with their properties and relationships.

Meta-model: A meta-model is a semantic information model, which precisely defines the constructs and rules needed for creating semantic models [76]. The syntax is provided by created models.

Model and tool integration: The combined usage of models through different level of tools collaboration.

Repository: A repository is a system incorporating all four of following characteristics [18]:

• A data storage mechanism;

• An interface to persistent data;

• A set of schema, or information model, and

• A concept of operation to manipulate the data.

Traceability: Traceability was defined as the ability to trace the life of an artefact from its creation to its use [90]. The traceability service of a platform answers the question “How well can a tool support the mechanism to relate data between different tools?” In other words, it makes navigational relations including both automatically generated and manually specified relations.

View: In IEEE1471, a view is defined as “a set of models that represent one aspect of an entire system” [63]. In this thesis it refers to the scope and concerns (core product artefacts and aspects of them) of interest for a group [18]. Several views are normally required for a system description, therefore there are many proposals for view frameworks, e.g., the “4+1” view [57] and the 4 views in [106] for software development.

Wrapper: To integrate multiple tools, one has to deal with the heterogeneity of tools supplied by different vendors, often with different syntax and semantics. One solution is to employ a set of components which act as glue or translators between tools. They

-8-

abstract technical details from individual tools and make them available at conceptual level. These components are called wrappers or tool adapters.

-9-

2 Problem formulation

2.1 System integration: interpretations, purposes and solutions

System integration is a popular but ambiguous term. In general it refers to the process of combining parts into a whole, and as such integration is involved in many dimensions. Study [35] has identified three integration domains: product, organization and process. See Figure 1. The product integration involves hardware and software, where components are composed into a consistent whole to obtain desired behaviors and qualities which are provided by the integrated components; the process integration aligns different engineering processes, e.g., mechanical, software, and control engineering processes; and the organization integration supports cooperation and communications among involved groups. These three types of integration are not isolated but closely related to each other. Due to strong interdependencies among them, providing support for integrating product models can also supply aids for organization and process integration [1][116]. Tools are not explicitly shown in the figure; however, they provide technical support and are associated with all three kinds of integration.

Integration takes place in different stages of the life cycle associated with different system requirements and design parameters. For example, system integration may take place at an early stage of development during the system architecture design or at a later stage when subsystems are composed. From early to late stages system requirements are allocated, refined, or changed; and this has to be properly managed during integration. More over, different stakeholders have various perspectives and concerns on integration, e.g., software engineers are concerned with issues such as configuration, information model, traceability, and consistency, while control engineers are concerned with performance and robustness.

There are several ways in which developers try to manage the product integration, essentially applying separation of concerns at different levels and for different aspects. In this thesis it distinguishes between [22]:

Process Integration

Organization Integration

Product Integration

analysis

software hardware implementation

test

EE team

supplier IT team

Figure 1 Integration in terms of Organization, Product and Process

-10-

• Hardware level integration. In this approach, the interfaces are standardized at the hardware level. A typical example is standardized black box electronic control units (ECUs) taken from automotive systems, where ECUs are integrated at the network level. One problem is that it is difficult to perform early stage verification and validation (V&V). Moreover, new functions often require additional hardware resource in this approach.

• Software level integration. Here the unit of composition is black or white box software components which are developed by different organizations, either hand-coded or through code-generation from modeling tools. The actual integration takes place at the software level where the software platforms (e.g., for simulation and for targeted execution) have to be standardized. However, the traditional software interface specifications do not consider aspects such as hardware and embedded systems environment, which also to a great extent affect the system behavior, for example the timing behavior.

• Model level integration. The key concept of this approach is that models of system parts are developed and integrated throughout the development, hence enabling incremental development and also software level integration in industry practices.

One should note that these three approaches are not completely isolated in practice, but are complementary. E.g., as a common case, software-in-the-loop simulation is a hybrid of model and software level integration, where code is encapsulated and executed together with models [93][115].

Among these approaches, the model level integration has major advantages with respect to both product qualities and engineering effectiveness by enabling earlier solution integration, verification and validation, and providing opportunities for design space exploration [22][114]. Therefore, model integration is of particular interest in this thesis work.

In general, integrating different models that present particular concerns of a product provides support for the following development activities [116].

• Information management and representation. Management of information has to be performed to support refine and changes, and representation of information has to be performed for system composition and documentation. A complex system development usually involves several subsystems. This is one of important characteristics of advanced embedded system development. Proper documentation is of particular importance to manage the entire system information for maintenance, updates and reuse. Several scenarios can be identified where a more complete view of the system has to be in place to support design and information management. Examples include the representation of both functions and hardware when performing architectural

-11-

design or the generation of specific views based on the information contained in individual models. Another need can be seen be seen in projecting one view onto anther. An example of this is to impact the control function development from the software structure perspective.

• Analysis: To verify the correctness of solutions throughout the development as well as for identifying impacts on design choices, different analyses techniques are adopted, for example safety and cost analysis. Analysis across individual models is relevant for many design scenarios. Co-simulation is one typical example when modeling different subsystems using different formalisms and tools. The actual co-simulation could be carried out by connecting the tools or by transferring one of the models (often in terms of executable code) into the other tools. Other examples are given by system level analysis of properties such as timing and safety. In this case, a more complete representation of the system is normally desired in order to provide information required by various analysis tools.

• Synthesis: There are different types of computer assisted synthesis. Examples include coordinated generation of code and of documentation based on the system models.

2.2 Delimitations As described in the previous section, there are several dimensions for system integration. In this work we focus mainly on the product dimension of integration as opposed to the organization integration and process integration, and particularly on the model and tool integration associated with product integration. This thesis is then delimited by the following scope:

• Product dimension related model and tool integration;

• In the context of high level (in terms of function and architecture) design of embedded system, and

• Taking a model based development approach.

2.2.1 Model based development

Model based development (MBD) refers to a development approach where models play a key role for documentation, communication, analysis and synthesis. It has been proposed and widely accepted as a cost-efficient approach within engineering disciplines for better complexity management, supported by different modeling techniques and tools. In an MBD approach, models form the basis for comprehending the design and relationships within or across engineering domains and developing phases. Models represent multiple views and provide support for early stage evaluation of functionality and qualities of concern. There are different interpretations of MBD.

-12-

For example, Model Driven Development (MDD) is used in software engineering for model based development of software and the term of Model Driven Architecture (MDA) is proposed as an OMG (Object Management Group) realization of MDD. However, the maturity of MBD in advanced embedded systems design is rather low in industry practice to handle various model/tool integration [114]. There are increasing efforts in this area from both academia and industry.

As a result of modelling heterogeneous properties of embedded systems, several types of languages and tools have been adopted for various purposes at different abstraction levels and stages of development. For example, Simulink and Modelica [73] are typical modeling languages in control engineering, while UML is in frequent usage in software development, yet other approaches use Statecharts [46], architecture description languages or hardware description languages. However, these modeling techniques address one or few specific aspects of a complex system, and models that individual tools manipulate are rarely easily exportable. Communication between models becomes difficult because the corresponding modeling languages have different syntax and semantics. The models correspondingly have different representation and scope. There is still a lack of optimized information management and good communication among these tools as one consequence of the diversity of tools.

Examples of techniques that are used for model integration purposes include:

• Co-simulation, where the focus is run-time simulation and interaction between involved models and tools or integration in terms of software code integration without clear semantics.

• Super-modeling approaches, where the intention is to cover as many aspects as possible within one, more or less integrated, framework. One example of this approach is the UML. This is an ambitious approach and useful for system architecting and information management. However, super-modeling is challenging and tends be more or less specific-domain dominated and still requires integration when new aspects or models/tools are introduced.

• Model transformation, where models transit between different formats, semantics and syntax. It can be realized on different abstraction levels. One example is code generation from model to code to achieve model integration at the code level. Another example is the model import/export between tools relying on exchange standards, intermediate languages, or dedicated APIs (Application Programming Interfaces).

Among these, the importance of model transformations are increasingly recognized in the area of software development, and model transformations are considered as the key to solving the problem of model integration among diverse tools and providing the opportunity to combining the power of individual tools into a tool chain [113].

-13-

2.3 Requirements and challenges As discussed before, developing advanced embedded systems involves the use of heterogeneous modeling paradigms. As one consequence, model and tool integration in embedded product development should provide support for dedicated workspaces/views supported by

• Structured information management for proper traceability across lifecycle stages and engineering domains for various purpose such as problem identification, versioning, variants, decision, and change control;

• Information transformations across heterogeneous views and model interactions across domain specific CASE tools used, e.g., ranging from requirements engineering tools, to implementation design and diagnostics tools. Even for similar purposes, there are variations of tools adopted; and

• Integrated tools support for above two.

To this end, data sharing and exchange in integrating different models have to be efficiently managed. Requirements put on this include Interoperability (efforts to manipulate data produced by another tool), Consistency (maintenance of the validity, integrity), Security (access restriction), Traceability (efforts to navigate relations), Concurrency (multiple user support), Redundancy (degree of data duplication) and Granularity (degree of data level). Furthermore, integration of modeling tools should provide support for configuration management, analysis and workflow management. However, all these are not easy tasks due to the complexity of system development, e.g., the variety of tools and modeling languages. In practice, when new tools are introduced, they need to cooperate with legacy tools; and some tools are evolving, e.g., UML tools. A successful tool integration platform therefore should be extensible and flexible in order to enable adding of new views and supporting process changes without much difficulty.

Addressing the need of integrating multiple views, numerous solutions have been proposed. In general, they fall into two main categories [22]: either 1) to provide a modeling language targeting the technical complexity and explicitly supporting identification and standardization of related product information; or 2) to provide an integration platform focusing on technologies enabling tool interoperation and information management in an engineering environment. Approaches in both categories have integration as central concern. The variety of proposed solutions mirror the fact that the area has not yet converged and existing approaches are restricted to certain views.

One central issue in managing model integration is the rules specifying the interdependencies as well as the transformations of information. A common solution is to employ system meta-models to model-level information integration and transformation. However, there is a challenge of the variety of meta-models (and even

-14-

meta-meta-models). One simplified solution is to cover predefined syntactical or limited aspects (e.g., structural aspect) of information, while leaving the semantics or other aspects (e.g., behavior definitions) in the associated original tools, e.g., [93].

In summary, to fulfill the requirements and meet the challenges, several research questions arrive and are discussed in the following sections.

-15-

3 Research goals, questions and approaches

3.1 Aim and purpose Given the focus of product domain model and tool integration, this work aims to provide engineering support and improve complexity management in the development of embedded systems by model transformations and tools integration. The work is devoted to develop knowledge, support methods and a prototype tool platform for efficient information integration during the model based development of embedded systems, e.g., vehicle systems, where various domain specific tools may be applied. The aim of developing prototype tool is to investigate integration technologies and provides support for integrating different models and tools applied in system development. More specifically, this work aims to study the model transformation and tool integration techniques, to identify the needs and engineering scenarios of integrating different models and tools, and to develop a tool platform for integration purpose. The integration platform focuses on integrating UML models and Matlab/Simulink models with the consideration of analysis tools such as safety analysis tools.

3.2 Research questions The following research questions are identified:

A: Why is integration needed in the context of embedded systems development?

This question needs to be answered at both a high level and a detailed level, i.e., the general need and concrete scenarios should be supported by a model/tool integration solution.

B: What are the pros and cons of current model/ tool integration approaches?

This question requires investigations on existing approaches with comparisons of their advantages and limitations.

C: What services should be provided by model/tool integration solutions?

This question addresses those requirements put on the functions and services provided by an integration solution.

D: Which techniques and tools are suitable for a desired integration platform?

This question focuses on the implementation techniques and provides insight into the targeting tool platform.

3.3 Research approaches To fulfill the requirements of multidisciplinary product development, this work is performed through method and tools development and by means of studies of both industrial practice and academic research. The work is carried out in three ways:

-16-

• Theory study: the state of the art investigation;

• Identification of need: the state of the practice study;

• Technology support: prototype tool development.

In order to answer research question A, the state-of-the-art of modeling technologies and tools were studied with the focus in the area of embedded systems. Investigations on industrial practice and problems have been accomplished in the research projects Modcomp [75] and ATESST [8] carried out mainly by other researchers in collaboration [66]. Based on the collected knowledge, several typical integration scenarios were identified for highlighting different integration needs.

Addressing questions B and C, a survey on model and tool integration approaches has been performed, from which an integration framework for model/tools integration was developed. The framework identifies criteria, applied technique and user requirement. These works partly answer question D as well.

The answer to question D is also addressed in the development of prototype tool platform in the projects ATESST and SAVE++ [96] applying techniques that identified and selected. In addition, answering question D has the potential to development of guidelines or integration patterns for model and tool integration, which are planed in future work.

3.4 Contributions This thesis discusses the techniques of integrating models and tools from various engineering domains. It provides an overview of current practices of model and tool integration, particularly in the field of embedded systems, covering challenges and solutions from both academic and industrial perspectives. The need for integrating various models into a consolidated whole coming along with the integration of heterogeneous tools is identified and explained. Typical integration scenarios have been identified. State-of-the-art solutions are studied and discussed. An integration framework is developed based on the known integration techniques applied in the studied approaches.

This thesis also presents two model integration case studies performed in the ATESST project together with lessons learned. One of them focuses on connecting the concepts and constructs of Matlab/Simulink and UML2, where a prototype platform for tool integration is developed. The other case study focuses on integrating safety analysis with system architecture design using a UML2 profile in automotive domain.

The main results from this work are two parts: The theoretical result is a framework for model and tool integration based on the state-of-the-art study; the practical results are two plug-ins developed in the case studies.

The main results and their corresponding sections in the thesis are listed as the following:

-17-

• State-of-the-art solutions: Section 4 and section 5.1.

• Scenarios: section 5.2.

• Framework: section 5.3.

• Prototype tools:

o Integrating Simulink with UML2: section 6.2 and Paper A.

o Integrating safety analysis with architecture design section 6.3 and Report B.

3.5 Validity In this thesis, the studies of the state of practice and industrial problems have mainly been limited to the automotive industry. The studies of state of the art and technical solutions have been broader, encompassing techniques from many application domains and disciplinary fields. The framework was developed based on the studies of the state of the art and practice, and it is possible to be extended by covering more aspects, e.g., together with development of integration guidelines. Evaluations of the framework through actual use in practice are required. The prototype tools are developed mainly based on the experienced gained from the projects ATESST [8], SAVE and SAVE++ [96], and Modcomp [75], which are all mainly in the context of automotive industry. The contributions are believed to be valid for a large class of advanced embedded systems.

-18-

4 The state-of-the-art approaches Studies of the state-of-the-art integration approaches in this thesis, as stated in the delimitations, mainly focus those that address design information integration throughout product development with a model-based approach. Some selected approaches are not mainly addressing embedded systems, but are still considered valuable. In general these approaches could be divided into three main categories: (1) system description languages, (2) Multi-paradigm modeling languages and tools, and (3) multi-tool/model integration environments. They further explained and discussed in the corresponding section 4.5, 4.2, and 4.6 respectively. A detailed introduction and discussion on selected approaches are given in report [102]. In addition, this section reviews early works on tool integration; and the scope of the study also covers model transformation techniques, standard exchange formats, integration between product data management and software configuration management. There are also several approaches that address methodology development for model and tool integration (see e.g., [6]); however, they are beyond the scope of this work.

The included approaches are far from exhaustive, but they do represent complementary efforts to meet different needs of integration. For example, UML and SysML in the first category aim to be general modeling languages that cover as many modeling aspects as possible, while the AADL [5] originally from the avionics and the EAST-ADL [26] from the automotive represent solutions for domain specific needs. In the model/tool integration environment category Fujaba [21] tries to be a generic tool integration solution for embedded systems, while GeneralStore[93][67] and ToolNet [1][40] have emphasis on the integration of domain specific CASE tools. On the other hand, SystemWeaver [108] aims to support information management, in which database techniques play a key role for structuring, storing, and provisioning of information, while the MIC approach presented in [54] provides explicit support for model mappings and transformations. Focusing on another concern, ModelCenter[64][65] and GENESIS [16][77][53] representative approaches addressing process workflow management. These selected approaches are briefly introduced in section 4.6 and further discussed in section 5.1.

4.1 Related early work on tool integration Tool integration has been a hot topic for more than 15 years. One of the earlier efforts, back in the 80’s, resulted in the integration approach based on message server. Examples of this category are FIELD, HP-SoftBench, and Tooltalk, where basic control- and event-oriented integration mechanisms were offered [19][59] . In contrast to the control-oriented mechanism, another data-oriented mechanism was proposed; one approach of this was based on compatibility maps, where a common database was introduced [2][59].

-19-

Wasserman [120] identified five kinds of integrations: (1) presentation integration, which provides one unified GUI (Graphical User Interface) of the integrated tool platform and involved tools; (2) data integration, which enables use of data from individual tools; (3) control integration, which concerns the interoperation among tools; (4) platform integration, which concerns the services provided by the platform; and (5) process integration, which concerns the software development process.

Similarly, Sum and Ibold [107] divided integration into four typical different dimensions: presentation integration, data integration, communication integration and control integration. Three of these dimensions (see figure 2) were discussed by Brown et al in [18], where they proposed a three-level conceptual model of CASE tool integration, i.e., processes, end-user services, and mechanisms integration respectively. According to this conceptual model, Brown et al categorized tool integration approaches into a conceptual level and mechanism level. Wasserman’s effort is an example of integration at conceptual level. At the mechanism level of integration, G. Kappel et al [55] categorized relevant research efforts into (a) standardization efforts and middleware services, (b) architecture models, infrastructures and tool suites, (c) basic tool integration mechanisms. Paper [55] also summarized research efforts in the area of Integration patterns and bridging operators and Ontology-based Integration.

With the introduction of MBD, multiple tools have been adopted for modeling embedded systems. Numerous efforts have been done to integrate these tools by proposing different solutions, e.g., multi-paradigm modeling, model transformations, and standard intermediate format. The following sections will further discuss them.

4.2 Multi-paradigm modeling Advanced embedded systems are comprised of many aspects from requirements over design, verification, implementation, integration, testing and finally production. Describing these different aspects requires different modelling paradigms. In [56] five major modeling paradigms for embedded systems are identified: Ordinary differential

Triggers

files

window manager

GUI Control Integration

Data Integration

Presentation Integration

database

Message server

Figure 2 Tool integration dimensions in [18] and [120]

file

-20-

equations, Partial differential equations, Finite-state machines (Statecharts [46] or Petri nets [86] for discrete event modeling of reactive systems), Stochastic models (e.g., for performance analysis), and UML based descriptions for software intensive system components.

There are a lot of tools and efforts providing multi-paradigm modelling languages, in which a number of sublanguages are integrated. Examples of them include Ptolemy [61] and commercial tools that integrate a few sublanguages, e.g., Matlab/Simulink/Stateflow [72], and ASCET-SD [38]. Among them, the Ptolemy and Matlab/Simulink are further studied and discussed in the following section 4.2.1.

However, the complexity of embedded systems makes it unlikely that a single tool will be capable of handling the development of the complete system. Current tools supporting the development of such systems deal with a limited number of aspects, they are “point tools”. The problem becomes worse since there are “no or few interface standards, no common data bases, no common user interfaces” [56]. Thus while multi-paradigm modelling tools can be and are extended, there still be a need for other tools and demand for tool coupling and model integration. To support integration of multiple models and tools in embedded systems development, different strategies are adopted, e.g., to provide super-modeling language, or to provide integrated tool environments e.g., through co-simulations or model transformations. Effort address these strategies are further introduced the following sections.

4.2.1 Multi-paradigm modeling tools

Matlab/Simulink:

Simulink is a graphical modeling/programming platform for simulation and model-based design of dynamic systems running on top of Matlab. Since it was introduced in the early 90s with the purpose of supporting modeling and simulation of continuous time systems and simple logic, Simulink has been extended and widely used in development of control system functions for modeling of multi-rate discrete time systems, continuous time systems, event-driven system by means of Stateflow, and with features that support modes of operations by means of triggering and enable blocks, modeling of programming constructs, etc. Several toolboxes have been developed to extend the basic models of computation and communication in Simulink, for example, tools from Mathworks [72] such as the Real-time Workshop and from other tool vendors such as dSPACE [25] provide testing and validation support for rapid prototyping, such as software-in-the loop, code generation, processor in the loop, hardware-in-the loop simulation. Another example is the True-Time toolbox [79], which extends Simulink with possibilities to describe hardware and software, allocation, scheduling and communication protocols.

-21-

Because of the richness of the language, Simulink can be used to represent systems at several levels from high level of abstractions to a detailed functional development including transformations to code. Typical usages include the following [7][115]:

• High abstraction level of system functional modeling including both internal aspects (the embedded system logic) and external aspects (the embedded systems environment, e.g., driver and vehicle). At high levels of abstraction, the system implementation is typically considered as ideal with basic assumptions e.g., zero time delay between sampling and actuation.

• Detailed function modeling bridging the gap to implementation. At this level, it is common to take timing effects due to the real-time system implementation into consideration, for example implementation data types (e.g., Int16 on a 16 bit microcontroller), software modularization for code generation purposes, processing and communication delays, and details of the interfaces to the environment and between computing devices. Real software can be included, and tested with the other models.

There are of course several variants of the above. As a sequence of the richness of usage, specialized guidelines for Simulink have been (and are being) developed to constrain it for specific purposes by some industry and organizations, e.g., MAAB [71].

Ptolemy:

Ptolemy [61][87] is a project that is dedicated for modeling and integrating heterogeneous MoCs (Models-of-Computations). A software framework named Ptolemy II was developed using Java, providing graphical user interfaces for mixed uses of defined MoCs that are realized by a suit of domains in the framework. Examples of well-implemented domains include continuous-time modeling, dynamic dataflow, discrete-event modeling, finite state machines, and process network with asynchronous/synchronous message passing. Some domains such as discrete time and timed multitasking are under experimenting [61]. XML is used in Ptolemy II for data representation.

4.3 Model transformations Model transformation refers to the process that on model is translated into another model which may conform to a different metamodel from the source metamodel [23][80]. This is an important facet in the MBD to enable integration of heterogeneous views, transition from platform business models to implementation models, creating new views, and assuring model incremental refinements.

Facing the challenge of having various meta-models, e.g., a UML model and C code, numerous efforts have been made to provide model transformation techniques. In general, they can be classified into two main categories: “model to text” approach and “model to model” approach [52]. Some common scenarios of the former include

-22-

generating html, xml and doc documents. Code generation is considered as a special kind of model-to-text transformation because code is also a kind of model. Intermediate models are sometimes needed, for instance, for purpose of optimization and debugging before directly translating the platform independent models (PIMs) into platform specific models (PSMs) such as implementation codes. In addition, considering the need of integration and synchronization, a “model to model” approach, which performs translations between the source and target models at the same abstraction level, is required for different purposes, e.g., for analysis.

There are different classifications depending on the applied techniques. In general, they are either declarative and rule based, or imperative, or a combination of both. For example if we categorize it in terms of transformation languages and tools, there are three alternatives: (i) General purpose languages such as Java which is available in tools via the JMI [51] (Java Metadata Interface) API; (ii) Intermediate transformation languages which are typically XML-based (Extensible Markup Language) such as XSLT (Extensible Stylesheet Language Transformations) [123], and (iii) Dedicated Model-Transformation languages including many DSLs (Domain Specific Languages) for transformation. A survey of model-transformation approaches can be found in [23][101]. Königs and Schürr discussed some model transformation approaches in [59] with respect to features such as transformation rules, rule application scoping and source-target relationship. The technical details and other ways to identify model transformation approaches such as rational-based, graph-transformation based, and structure-driven approaches, are beyond the scope of this thesis, interested readers could refer to [50] and [70].

OMG has put numerous efforts into model transformations, for example, the XMI (XML Metadata Interchange) [83] techniques and MOF QVT (Queries/Views/Transformations) [82] offer one possible solution for a standard way to define model transformation in the context of OMG MDA space. As its name stands for, the QVT aims to define specifications for standard languages to expressing queries, views and transformations. The transformation defined by QVT is also a MOF2.0 meta-model and executed on instance of MOF2.0 meta-models. This is a rather new technique. The currently QVT specification (version 1.1) was published on July 2007 and still under revision. As a consequence, tools support for QVT is still insufficient. Some open issues such as the performance and scalability need be further studied. Many existing approaches in model transformation languages have been either submitted to the QVT-RFP or already a part of MDA (Model Driven Architecture) activities for meta-model-based tool integration [55] [100]. And there are also few efforts which are already aligned with QVT. For example, the model transformation languages-ATL (Atlas Transformation Language) [10], which supports metadata management and data mapping, is developed to be consistent with the MDA standards, in particular MOF/QVT. It has been elaborated in the MODELWARE [69] project and recognized as

-23-

a standard component in the Eclipse M2M project [74]. The difference, alignment and interoperability between ATL and MOF/QVT are introduced in [58].

With respect to the efficiency and effectiveness of model transformations, one common concern is the consistency and traceability between models as well as model management. i.e., how could a change trigger a transformation? Another issue is how to specify and test a transformation, i.e., how to assure the transformation is giving correct results. These issues are very important and have to be taken into account, especially in the context of complex embedded systems. In several cases, the issue of model graphical representation, i.e., diagrams and their layout are also very important. Although some efforts have been put into this, e.g., the XMI-DI [84], it is still an unsolved (at least far from complete solved) problem.

4.4 Standard exchange formats The importance of standardized interface formats for models on system level and component level is emphasized in [56], in which Müller-Glaser et al carried out a study on multi-paradigm modeling in embedded systems design with insight into some engineering practices and problems mainly from the automotive embedded systems domain. Examples mentioned include description languages like SABER [97], VHDL-AMS [119], SDL [104], and interface formats like CDIF [36], EDIF [31], STEP [111], XML [124], and XMI [83]. This section in the following further introduces some of these exchange formats, and more information can be found in report [102].

One well-known of these formats is the XMI. It was developed based on XML, which has been successfully used to support many model representation standards. XMI was proposed by OMG to describe data and support model interchange for UML and other information assets. Being platform independent, XMI makes it possible to freely access information data regardless of the model type and storage location. However, the graphical information presented in a UML diagram is contained neither in UML meta-model or MOF (Meta-Object Facility) meta-model. Therefore the diagram information will be lost when a UML model is represented by XMI documents. Tackling this situation, the XMI-DI was proposed for describing diagram information. Despite of the immaturity [3], it was proposed as a standard to exchange models between tools where diagrams are represented.

Another effort addressing the data exchange format is the Standard for the Exchange of Product Model Data (STEP) [111], which is dedicated to provide a standard for information exchange and representation. It aims to provide flexible support for interoperation and integration between different systems throughout the entire product lifecycle from design, development, and manufacture to maintenance. This standard in fact is a family of protocols for reading and writing data between different systems, also known as ISO 10303. However, it is developed mainly for mechanical engineering, for example for exchange data between CAD tools.

-24-

The AUTOSAR partnership [11] was founded in 2003 by major European automobile constructors. It aims for provided a standard open architecture for automotive E/E systems. One of the major goals is to the re-use of software component between different OEM and suppliers. Other goals include modularity, scalability, and transferability. AUTOSAR focuses on the low level of implementation. Particular emphasis is put on the non-functional issues such as software modularity instead of performances.

4.5 Systems modeling languages This section reviews some system description languages, UML/SysML, AADL, and EAST-ADL. They are far from exhaustive, but they do represent complementary efforts to meet different needs of integration. For example, UML and SysML aim to be general modeling languages that cover as many modeling aspects as possible, while the AADL [5] originally from the avionics and the EAST-ADL [26] from the automotive represent solutions for domain specific needs.

The AADL [5] has a background in the aerospace domain and has been applied to embedded and safety critical control systems. It addresses the integration of software and hardware entities, being supplied from different sources. The AADL modeling language can be used to describe the composition of these entities, the analysis of system level properties, and also to support glue code generation and platform binding.

The EAST-ADL [26] is a UML2 [118] and SysML [109] based Architecture Description Language for automotive embedded software and systems. It was defined by the EAST-EEA consortium [26] and is currently further developed in the ATESST project [8]. The purpose of EAST-ADL is to integrate system information on different levels of abstraction and for different automotive application domains. It is not a tool, but an information structure that can be used within a tool and for model exchange. Domain-specific tools may be used for different modeling and analysis purposes, but the system model in EAST-ADL representation is then used as the model structure where all information is integrated and/or referenced. The EAST-ADL system model is structured in several abstraction layers. A complete system description is contained on each level, allowing integration on each abstraction level, with adequate level of detail. The focus for EAST-ADL is software design, but hardware architecture modeling is included because of the tight interdependencies. Aspects covered include system structure, behavior, requirements, variability, V&V and environment modeling.

The UML (Unified Modeling Language) was proposed by the Object Management Group (OMG) to provide modeling based on a collection of graphical notations and various supporting mechanisms. The UML can assist with the specification, visualization and documentation of models of software systems, including their structure and behavior [118]. Since its introduction, the OMG has delivered several new versions of the UML [118].

-25-

The current version UML2 supports 13 graphic views of a system, which can be grouped into two categories: structural aspects and behavioral aspects. To describe system structure, the composite structure diagram is often used. Other structure diagrams are the Class Diagram, Object Diagram, Component Diagram, Package Diagram, and Deployment Diagram. These structure diagrams depict the static structure of objects that is irrespective of time.

UML uses Behaviour Diagrams, which are the Use Case Diagram, Activity Diagram, and State Machine Diagram, to express general system behaviours. Derived from these general behaviour diagrams, Interaction Diagrams, i.e., the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram, are also used. The choice and usage of diagrams varies due to purpose, convention, and preference.

There are two fundamental assumptions about behaviour in UML: first, it is either passive or active; second, it is either event-driven or time-discrete. Based on these two assumptions, three types of behaviour formalisms are given by UML2, activity, state machine and interaction, where the emphases are condition and coordination of behaviour, the communication of instance, and the states respectively [117].

The UML is focusing on software and has an object-oriented tradition. One deficiency of UML is its inability to deal with continuous time modelling. This spurred an effort by BMW [15] to integrate UML and ASCET-SD [38] into an automotive modelling language (AML) [20]. Other commonly raised criticisms against the UML include its vague semantics and vague relations between the various diagrams. To counter these limitations there are several efforts that aim at tailoring the UML to specific purposes while providing improved semantics. The UML extension mechanisms are then often used to customize the language. Examples of such extensions include:

• The Systems Modeling Language (SysML), extending the modeling scope from software to systems. The SysML in particular introduces systems engineering information such as requirements and ways of representing constraints and continuous time systems [109].

• The MARTE [81] (Modeling and Analysis of Real-Time and Embedded Systems) intends to be a UML2 profile for defining timing, quality of service and fault-tolerance concepts. It will replace the SPT (Schedulability, Performance and Time) profile [85]. It focuses on all kinds of real-time software systems instead of supporting generic system modeling.

4.6 Model integration platforms Selected approaches are Fujaba, Eclipse/EMF[29], MODELWARE, GeneralStore, ToolNet, SystemWeaver, MIC, ModelCenter, OPHELIA (Open Platform and methodologies for devELopment tools in a distributed environment), GENESIS (Generalised eNvironment for procEsS Management in cooperative Software

-26-

Engineering), Cheops [99][98](Component-based Hierarchical Explorative Open Process Simulator), and “APosteriori”[14].

Fujaba [21] was developed by software engineering researchers for solving the problems of variety of notations and tools in the development process and for providing data consistency management in tool integration, particularly at the meta-level. Fujaba supports bi-directional associations between meta-models for different tools that are developed and compiled in separation, such as UML and SDL (Specification and Description Language). To keep models consistent, Fujaba supports automatic consistency checking on model change events. Consistency rules are defined with graph grammar rules. Like Eclipse [16], services are extended and integrated via a plug-in mechanism in Fujaba. Fujaba supports code generation.

The Eclipse Modeling Framework (EMF) [29] is a XML/Java framework for generating applications/tools from EMF models. EMF can be considered as a “Java implementation of a core subset of the MOF API”. An EMF model can be created in different ways: e.g., using Java interfaces, using XML Schema, or from XMI documents either created directly or exported from other modeling tools. The EMF provides support for java code generation and good interchangeability between tools. In EMF, modeling objects can be saved as XML documents for interchange with other applications. EMF models can be created and/or imported from Java code, XML document or other modeling tools such as Rational Rose. Java classes can be obtained from these models. Updates are treated in bidirectional way: changes in models will be retained during the regeneration of code and also modification in code will change the model that the code is associated to. Aligned with MOF, EMF can be considered as a Java implementation of a core subset of the MOF API.

The Eclipse platform on the other hand is an open development environment aiming tool integration at the file level, supporting multiple OS (operating systems) environments and programming languages. To meet the principal aim of seamless tool integration, Eclipse platform is developed based on a plug-in mechanism. All Eclipse platform functionalities including the aspects of platform itself are located in plug-ins, which provides good flexibility to extend, e.g., by integrating new tools. However, Eclipse does not provide data integration. Tools share data through files by means of import/export mechanism. Therefore a tool must be adapted to the specific file formats used by other tools in the integration process. Another shortcoming is from that user interfaces of the tools being integrated have to be redesigned since only tools specially designed for Eclipse environment are supported.

MODELWARE [69] is a project with the aim of providing MDD solutions for software systems development to increase productivity and ensuring the adoption of proposed solutions in industry. In the context of MODELWARE, two main actions are taken place: the automation of code generation and the capitalization and reuse of existing models and tools. It includes the development of modeling technologies, process and

-27-

methodologies, tools infrastructure (tool integration platform), and adoption of developed results in industry. An open source model transformation tool, SmartQVT, has been newly released on http://smartqvt.elibel.tm.fr/. The ModelWare project is finished but there are some follow-up projects that are related to it, e.g., the Eclipse MDDi project [27] and Eclipse GMT project [28].

GeneralStore [93][67] is an integrated environment enabling automatic prototype generation from model via code generation, with the aim to allow integration of multiple formalisms in embedded system development. UML is used as a basis for defining a meta-model with defined transformation rules for three domains: time-discrete, time-continuous, and software. The coupling between sub-models is also defined using the meta-model. A database is used for implementing the platform with MOF (Meta Object Facility) as the database schema. XML (eXtensible Markup Language) is used for data interchange. The platform supports configuration management. The GeneralStore tool environment is commercialized and further developed by AQUINTOS [4].

ToolNet [40][1] is an integration platform, managing the integration of different tools used in different phase of embedded software systems development. It leaves the data at the tools being integrated and reference objects are used to represent object within the platform. Consistency relationships are specified and stored in a relation repository formed by a so-called VirtualObjectSpace. Data integration is performed by creating instances of relationships and storing them in the repository. Standardized APIs are used to access corresponding tools by requesting XML-export of data. Navigation and design is supported by a graphical user interface. Examples of currently integrated tools include Doors, Simulink, and Borland Together ControlCenter.

SystemWeaver [108] aims to provide configuration management for complex systems. The need is motivated by the insufficiency of traditional document-based specifications for large systems. A system information model defines a complete system. Through a defined API or XML file exchange, the platform supports the development of user specific clients (views) and the integration of domain tools.

The MIC [68] approach is developed for model-centric software systems development. It describes a system development process in three levels: meta-level (defining metamodel for domain models), domain modeling and integration level (providing tool-suits including model editor, interpreters, and analysis tools), and application level (software applications). Some works were presented in [54], which introduces a model-transformation based approach to the integration of different engineering tools (e.g., fault modeling tools, diagnostics engines, FMECA (Failure Model Effect and Criticality Analysis) database). The transformations are implemented through a mapping of the meta-models of individual models. To support exchange of tool data, different tools are connected on the basis of CORBA/COM technologies. In the approaches presented in [54], the translations of semantics and syntax are separated. That is, while each tool has

-28-

an interface adapter that provides the data access (e.g., through a data file or COM interface) and syntax manipulation, the system provides a central semantic translation service for preserving the semantics of tool data being exchanged.

ModelCenter[64][65] is a visual integration environment for simulation based design, with the aim for process workflow management, distributed modeling and simulation, and trade-off analysis. It has a client-server architecture, where TCP/IP protocol is applied. Central repository on a server is adopted for data storage, where reusable components are encapsulated. Wrappers are used to parse and expose information in a common API. Examples of provided support by ModelCente include probabilistic analysis, performance analysis, cost analysis, and optimization.

OPHELIA[44][16] is a CORBA-oriented approach aiming to develop an open platform and methodologies for development tools integration in a distributed environment. By wrapping the data as a CORBA object, exposing interface methods, it defines standard interfaces to access and operate on the artifacts produced by individual tools. Integrated tools have to implement their corresponding module interface specification to be connected to the OPHELIA environment. It has the highlight on information management, and relationships between objects are defined as an essential part of the meta-data. OPHELIA supports both coarse and fine grain level data integration and workflow management.

GENESIS[16][53][77] (Generalized environment for process management in cooperative SW engineering) is similar to a PDM-like solution including the work-flow management. Its focus is on controlling the process in multi-site projects where each site is able to execute instances of a software process or sub-process which has software artefacts as process inputs and outputs. APIs are used to obtain information from integrated tools and communicate with the resource management engines where meta-data are extracted.

Cheops [98][99] is a co-simulation case of tool integration initiated from chemical process modeling, where mathematical models of chemical plants are constructed by various tools for numerical solutions. Wrappers are implemented to provide access to and translation of models to the internal representation. Through the transformation performed by wrappers, individual tools are connected. CORBA is chosen to implement the communication.

A-posteriori integration techniques described in [14] constructs a development environment for incremental development processes with feasible effort. One focus is to manage duplicated and/or dependent information existed in different documents. Three steps are included 1. Architecture modeling and refinement, 2. Modeling and construction of wrappers, and 3. Construction of executable models for incremental consistency management. The case study presented demonstrates the integration tool developed between Comos PT and Aspen Plus, supporting consistency management between flowsheets and simulation models. This approach has its roots in chemical

-29-

engineering, but this should not restrict its usefulness. Integration rules were defined in a meta-model which extends the UML meta-model. It is a bit unclear how this restricts the portability of the integration technique to other areas and tools.

4.7 PDM/SCM integration In the previous section, several tool integration platforms were introduced. One of the most important concerns of these platforms is information management. Such functionalities have traditionally been provided by PDM (Production Data Management) and SCM (Software Configuration Management) tools.

SCM is “the art of identifying, organizing, and controlling modifications to the software being built by a programming team [12]”. Traditionally, SCM deals with software products and its components.

To provide product data management support, PDM is developed to “control the evolution of a product and providing other procedures and tools with the accurate product information at the right time in the right format during the entire product life cycle [47]”. Traditionally PDM systems handle with hardware products information management.

In industry practice, hardware and software are not completely separated. Systems development has to take both into consideration. A combined usage of both PDM tools and SCM tool is desired. Due to the different development domains, PDM and SCM have fundamental difference in their visions, assumptions, and underlying technology. However, both providing overall support for information management and collaboration among stakeholders in systems development. PDM and SCM have similarities, for instance, supporting version control management, change management, release management, and workflow and process management during product life cycle [24]. The needs of an integration of both have been seen by industries and academia e.g., [24] and [37], where the challenge and possible approach have also been investigated based on industrial experience.

Many approaches introduced in 4.6 provided PDM or SCM similar functionality, for example, configuration management in the ModelCenter approach, version control in the GENESIS approach.

While information management is of great importance, a more detailed discussion is beyond the scope of this thesis; interested reader can refer to [24] and [34].

-30-

5 Framework and discussions In previous section 4, we have introduced the state-of-the-art techniques and approaches that target for model and tool integration. This section will discuss those selected approaches, identify typical integration scenarios, and synthesize a comparison framework. Detailed introduction and discussions can be found in [22] and [102].

5.1 Discussions on selected approaches The studied approaches are heterogeneous in nature. However, one common concern for all these approaches is the integration of information from disparate formalisms and tools, which are used for different aspects and modeling in different sub-domains of a complex system, in order to achieve an effective product development. Based on the study of these approaches, some central aspects of integration are identified including:

• View integration

• Model and information management

o Versioning

o Meta-modeling

o Consistency and traceability

o Data storage

o Structured information management

Dependencies definition

Information model

• Workflow management

• Basic mechanisms

These issues are closely related to each other, e.g., defining dependencies between objects provides support for consistency and traceability management, and dependencies could be defined in meta-models. The following section 5.1.1 discusses some of these issues and others are explained in the framework (given in section 5.3) drawn from this study. More detailed information can be found in the report [102].

Among the selected approaches, the exchange formats, model transformations, and PDM/SCM integration provide technical support for model and tool integration. The multi-paradigms modeling tools are closely related to integration platforms. Therefore the discussions in this section focus on two main categories: (1) system description languages in terms of two architecture description languages (AADL and EAST-ADL) and one general purpose modeling language (UML), and (2) multi-tool/model integration platforms. They are different but also closely related. On one hand,

-31-

languages specify meta-models and form the basis for tools; on the other hand, tools provide implementation and support for languages.

The language approaches provide explicit support for information management which has been maintained in individual domain specific tools. They provide well-defined concepts at different abstraction levels as well as in different lifecycle stages. Detailed discussion about languages approach can be found in [22].

The platform approach mainly focus on the tool interoperation and engineering support for information management. Two different strategies [56] and/or a hybrid of them have been adopted in these approaches for the purpose of integrating models constructed in different tools, including (1) integration of operations on models; and (2) integration of models by model translation. The first strategy can be exemplified by co-simulation in Cheops and coordinated code generation in Fujaba and GeneralStore. The second strategy can be exemplified by approaches such as Cheops, MIC, GeneralStore, and “A-Posterior”.

5.1.1 Discussion on central aspects of model and tool integration

5.1.1.1 View integration

View integration can be identified from two perspectives: product component integration and aspects integration. The former refers to a part-whole decomposition where the integration takes place between models that represents different parts of a product, e.g., through co-simulation in the Cheops approach. The later refers to the composition of different aspects of the same system. For example, GeneralStore supports integration between control functions aspects and software development aspects. Corresponding to these aspects, models, e.g., functional and hardware, are designed in parallel and integrated in allocation. View integration is supported by most of the approaches, for example, the ToolNet, MIC, Fujaba, Cheops, and GeneralStore.

During the integration of different aspects of the same system, it is inevitable to deal with duplicated information and handle data consistency. This issue is further discussed in the coming section 5.1.1.3. Another challenge when integrating multiple views is the heterogeneity of models and tools adopted in different domain areas. These models are commonly dependent on each other through various relationships. Proper model management and workflow management therefore become important and they are discussed in the following sections.

5.1.1.2 Structured information management

In an integrated environment information is shared and exchanged across tools, where models normally have different syntax and semantics, a common understanding is thus necessary. Moreover, there are complex dependencies between models involved in the system development, e.g., refinement, composition, duplication, communication &

-32-

synchronization, allocation, and so on. These dependencies have to be managed properly in order to provide support for structured information management.

One solution is in providing an information model for the entire system. For example, the Fujaba, GeneralStore, Cheops, ToolNet, and “A-Posteriori” approaches all use MOF based meta-modelling to define the information models. However, they differ from each other. E.g., both GeneralStore and Cheops use a single integrated system model, but for the purpose of analysis and synthesis GeneralStore uses the original domain models together with appropriate wrappers, while Cheops uses the integrated system model.

ToolNet provides explicit support to define the relationships between object. The defined relationships then are stored in a relation repository, which can define new relation, govern information, and create instance of relations. The ToolNet also provides visualization support for analyzing the dependency structure of the integrated system. In Fujaba relationships between models are defined in the system meta-model.

5.1.1.3 Consistency and traceability management

One challenge for integration comes from the separated production information in disparate formalisms and supporting tools. When integrating separated views into a complete whole, consistency becomes a center of concern. Consistency support is concerned with the management of dependent information due to decomposition, refinement, and so on. Three major tasks are required for consistency management [43][2]:

Inconsistency avoidance: this is concerned with measures adopted to prevent overlapped information from conflicting. For example, the GeneralStore approach uses a single UML model to describe the system information, then partitioning it into domain specific sub-models.

Inconsistency checking: the detection of existing inconsistency needs complete understanding of all consistency rules. Therefore a consistency relationship repository is often used in the integrated development environment, e.g., the ToolNet and Fujaba.

Often the inconsistency avoidance and detection can be supported by meta-model restrictions like in GeneralStore or documentation support such as the XML report in ToolNet.

Inconsistency resolving: Once inconsistency is found, it should be decided whether this inconsistency is temporarily allowed or must be fixed immediately. This requires taking the process into account for supporting concurrent engineering. However, system developers sometimes prefer to change models freely, thus temporarily allowing certain inconsistency [13].

Related to the dependency management, traceability reflects the ability to manage information. In the platform approaches discussed in this work, dependencies are restricted by the meta-models of integrated tools and platform services. For example,

-33-

the ToolNet approach provides explicit support for dependency analysis. The language approaches however come with predefined abstractions and thus permit better traceability management and also provide good possibility to organize additional concerns spanning multiple quality aspects and refinement levels.

5.1.1.4 Central repository and local storage

Selected approaches have the aim to build a platform that integrates various existing tools to provide desired services that cannot be supported by individual tools. Different ways are used to store data. One way is to use a central repository for all individual tools. This repository is responsible for events management, change detection and providing common storage facility for all the involved tools. A central repository has its drawback regarding scalability, since the size of the repository increases significantly with the number of integrated tools. An alternative solution is to use a local storage mechanism, where a distributed infrastructure is created with the tools utilizing their own storage facilities where applicable. In this way, for example, the OPHELIA interfaces are implemented “not by the repository, but by the server counterparts of the tools.” [44]. In another way, the ToolNet approach leaves the data at the individual tools, and only stores reference objects with the data relationships in the repository. This technique seems more efficient than a central repository with all tools data. The choice between a central repository and a local repository depends on many practical issues such as extensibility and efficiency. For example, if there is a significant concepts overlap between integrated tools, e.g., when tools work on the same model with different aspects and share much information, a central repository would be a good choice like in the MIC approach.

5.1.1.5 Integration architecture

There are two possible alternatives for integration architecture:

Tight integration: This is a Peer-to-Peer integration, where tools are joined through a point-to-point connection. In this approach, one tool is connected to another tool using dedicated interfaces. It directly transforms a model in the source tool into a model in the target tool. Due to the involved tool specific issues, this kind of integration is rather tight and falls into the shortcoming of scalability, for example, if one tool needs to integrate with other new tools, it has to provide one integration solution for each of these tools. Therefore a peer-to-peer integration is applicable when well defined processes are available, where the workflow (the tool interaction sequences) is well-predefined. However, the maintenance is still difficult when products evolve.

Loose integration: This is a type of indirection transformation and integration. A third intermediate component such as “tool adaptor” or “wrapper” is introduced to obtain information from original model and send them to the destination tool. In this type of integration, intermediate models are created, by means of which, a loose integration approach has better flexibility than the peer-to-peer integration. Many of the selected

-34-

approaches, e.g., the OPHELIA, Cheops, ToolNet, and “A-Posteriori” approach, fall into this category.

5.1.1.6 Workflow management

By integrating a set of tools, some platforms can be considered as a collection of services provided by individual tools, each of which requests or responds for a service according to a certain protocol. Workflow management therefore becomes possible. For example, this is supported by the Genesis approach by defining event notifications and reactions. Fujaba and Eclipse, in another way, provide synchronization of tools through a plug-in mechanism.

5.1.1.7 Fundamental integration techniques

In most of these approaches, XML has been used as a common format for information exchange. MOF is adopted by most of them for meta-model integration and storage. CORBA is also widely employed in the implementation of these approaches and COM/DCOM is adopted in approaches of Fujaba, “A-Posteriori”, MIC and ToolNet.

5.1.1.8 Examples of comparison

In the following Table 1, Table 2, and Table 3 give some examples of a comparison of storage mechanisms, integration mechanisms and standard technologies, followed by introduction of integration scenarios given in the next section 5.2. Apart from these discussed aspects, there also some other interesting issues, such as fine grain management or coarse grain management, which are beyond the scope of the thesis.

Table 1 Comparison of data storage mechanism

Eclipse Data is stored in files. And also can be stored and shared in CVS repository for sharing project.

Fujaba Data is stored in local tools.

Toolnet Relation repository is used to handle information about the relation definitions, and store reference objects and relations between them.

MIC Integrated data model to represent all meta-models of integrated tools. Local tool storage is adopted

GeneralStore A database such as Oracle and MySQL

ModelCenter Reusable components are published by analysis server. The sever act as a data repository for tools to get and put results.

Ophelia Storage in domain tools. The distributed repository is formed by CORBA servers and broker. Varying data granularity allowed.

Genesis Meta-model data stored in a data base. OSCAR artefacts themselves are presented as XML documents containing both the meta-data and the artefact data

Cheops Centralized storage seems to be implied APosteriori Links are stored in a file.

-35-

Table 2 Comparison of integration mechanism

Eclipse Tool functions are realized by plug-ins. Tools integrate through extension points defined in the plug-ins. To integrate, a tool must provide files in a recognized format by other/another tool.

Fujaba Plug-in mechanism Toolnet A standardized API (ToolAdapter) allows the integration of any tool.

MIC Tool adaptor is adopted for syntax translation

GeneralStore Code generation plug-ins are available for each integrated tool

ModelCenter Wrappers are used to parse information and expose that information to a common API.

Ophelia Wrappers allow the integration of any tool subject to the data availability/openness in the integrated tool.

Genesis Artefacts needs to be accessible by the OSCAR artefact management system, e.g. through the file system.

Cheops Corba clients implement wrappers and analysis modules. Wrappers have to be implemented providing access to models and translation of models.

APosteriori Wrappers are created according to a pre-defined model of integration covering wrappers in many hierarchical levels.

Table 3 Comparison of standard technology

Eclipse Files import/export can be in format of Java and XMI Fujaba GUI configuration files are based on XML. Toolnet Data access by requesting an XML export. MIC CORBA and COM, GeneralStore Filters to import/export the different models uses XMI

ModelCenter Data acquisition across programs is carried out through APIs with Socket-based protocol. Tools communicate via TCP/IP.

Ophelia CORBA Genesis File system, XML Cheops CORBA APosteriori Focused on COM

5.2 Integration scenarios Typical integration scenarios can be identified from various engineering situations relating to information management, and activities during the system development such as design decision making, implementation, and V&V. Identified scenarios are described as following design cases. They were first introduced as inter-abstraction relationships in [33] and further investigated and evaluated in the state-of-the-art survey

-36-

introduced in section 4. To simplify the illustration, we take UML and Simulink models, representatives from software engineering and control engineering, as examples in the integration. More discussion on Simulink and UML integration scenarios are given in Paper A.

5.2.1 Allocation design

Allocation refers to the mapping of behaviour to structure, such as from functions to hardware or from software to hardware, where model entities in corresponding tools need to be related.

This design case is not explicitly seen from selected integration approaches, but it can be exemplified by the needs in embedded systems for relating control models to architecture model. Matlab/Simulink is widely adopted in the control design area for control specification and simulation. On the other hand SW/HW design uses other tools such as graphical model based development, e.g., UML and its profiles.

Line “a1” in Figure 3 indicates one example of this design scenario, illustrating the relating the design of control systems in Simulink to the embedded systems design in UML for example to evaluate the system performance. This integration can be realized in different ways; for example, by providing a centralized storage of the system model using an approach similar to the EAST-ADL; or by using an approach such as ToolNet. Given the models are related, several possibilities are provided, for instance, performing timing analysis or creating new views [34]. By means of analysis, assumptions such as the zero time delay in the ideal Simulink model could be refined and thus leads to optimized system design. However, to do timing analysis requires that timing properties in Simulink models, such as triggering and execution time, have to be transferred to analysis tools, and also UML models in the EAST-ADL approach. Hence a correct semantics and syntax translation between UML and Matlab/Simulink is desired to support the required model transformations. However, there is no ready common language that enables direct communication between UML and Simulink.

Figure 3 Scenarios of integration UML and Simulink

Structure Behavior

Design

Abstraction Level

System Content

Implementationr1.2

c1

UML

c3

Simulinkc2

a1r1.1

Behavior

Design

Abstraction Level

System Content

Implementationr1.2

c1

UML

Simulinkc2

a1 r1.1

-37-

5.2.2 Composition design

Composition establishes the parts-whole relationship as well as the communication relationships between system components concerning both the structure and behaviour aspects at different levels of abstraction.

In the development of complex embedded systems, it is common that functions/subsystems are developed concurrently by different engineering teams or integrated as COTS (commercial off-the-shelf). This is illustrated in Figure 3 as the traces c1 and c2, representing the concurrent development and the integration of structural information and behavioural information respectively. For example, in the Cheops approach, separately designed components are imported/exported and composed together within the Cheops platform. Trace c3 shows the case of composition of behaviour at the implementation level through code. An example of this can be seen from the GeneralStore approach, where code are generated from Simulink models and Artisan Real-time Studios UML models and integrated together.

This design case reflects the needs of integrating separately developed solutions and components. To enable the composition, it requires well-managed communication between system components, which brings the integration critical tasks of specifying complete interface and protocol.

5.2.3 Refinement design

Refinement refers to the activity of providing a system solution with more details or precision towards the final realization in an incremental development process, such as adding more constrains, and improving the exactness of attributes.

Refinement design often traverses abstraction levels, as shown in figure 3 with the traces r1.1 and r1.2. At an overall design phase, UML models might be used to capture the subsystems. For example, a vehicle system might be partitioned into driver subsystem, auxiliaries subsystem, transmission subsystem, driveline subsystem, chassis subsystem, brake subsystem, steering subsystem, and so on. In a later stage, these subsystems are further refined by putting more constraints such as adding non-functional aspects into consideration and improve the model resolution. At the same time, their behaviours are further refined by provided Simulink models.

In this design case, a system model somehow needs to represent the refinement for example in terms of models of different details. This is supported by approaches that provide information modeling, e.g., EAST-ADL. Moreover, ideally an automated refinement is preferred, where model transformations are desired. This is supported by some approaches, e.g., GeneralStore in terms of code generation and integration.

5.2.4 Duplicated/Overlapped information

Duplicated/overlapped information refers to abstractions that are replicas of each other. It is not uncommon to decrease the complexity by separating concerns in complex

-38-

embedded system development. For example, in the GeneralStore approach, the design of an embedded electronic system can be divided into closed loop design in Matlab, software development in UML, and discrete subsystems design in Statemate. However, the same subsystems/parts are often inevitably worked on by different specialists at the same time and thus shared information has to be considered. This shared information is often changed during the development in the specific area, and thus becomes inconsistent. One example is that the software structure is described in UML models and the same model will be used for safety analysis. Another example can be found in the GeneralStore approach where a UML tool is used to model system structure and the behaviour of the same system is modelled in Matlab/Simulink.

5.2.5 Dependent information

Dependent information refers to the scenario that one model is affected by another because its property relies on the other or it has certain assumption of the other model. In general this scenario can cover all others, e.g., code generated from models has strong dependency with the models. It is common to have some assumptions in the design of a controller, for instance, a traffic model. However, assumptions may become invalid, and thus the controller has to be changed correspondingly.

This scenario can be seen in all the selected approaches. One example could be taken from the ModelCenter approach, where a later action highly relies on information in the previous action to provide workflow support. Another example is from the ToolNet, where Simulink/Stateflow and Doors [112] are used for control modelling and requirement modelling; an object in Simulink/Stateflow model thus is linked to one or several requirement objects and has to satisfy the requirements specification.

As one comment requirement, an efficient and structured way for managing system information is desired, e.g., to handle the information traceability and keep consistency. Also associated engineering support for information detection, determination and correction is necessary. Different solutions have been adopted in the state-of-the-art approaches as discussed in section 5.1, and they will also be addressed in the comparison framework given in the following section 5.3.

5.3 Comparison framework A comparison framework must to be general enough so that aspects covered by it are not restricted to particular approaches or areas; meanwhile it needs to contain enough details to represent the characteristics of all existing approaches. To reach a balanced solution, we use a “Top-down Synthesis and Bottom-up Refinement” technique learnt from our previous work [22]. We studied the generic concepts of systems and model/tools integration; and based on the following fundamental questions, we define a set of factors which are used to characterize those integration approaches of interest. These fundamental questions are:

-39-

Q.1. Why is the particular approach needed?

Q.2. When and where should/could the approach be applied?

Q.3. What is intended to be integrated?

Q.4. How is the integration performed?

Q.5. How is the associated engineering work supported?

Question Q1 is related to the motivation behind a particular approach. Question Q2 covers the organization-, process-, and product-specific context in which the needs are derived and the solutions will be applied. Questions Q3, Q4 and Q5 are concerned with solution details of the approach. While question Q3 details what an approach specifically has the purpose to integrate, e.g., UML and Simulink models, question Q4 focuses on the adopted integration scheme in terms of its architecture, process, and implementation technology. Question Q5 highlights the additional engineering services that are necessary for applications developers and managers to acquire, assess, and handle disparate information and to organize the engineering work. These services fall into two main categories: technical and managerial services see e.g., [78]. The former category includes services for specifying, verifying, and executing a product, highlighting three factors: Definition of Integrated Product Structure, Product Analysis, and Product Synthesis. For the reasons of efficiency and correctness, such technical services rely on the managerial services, which are concerned with the support for both information and process management. Essentials in the information management include the services for ensuring the agreements of information (i.e., consistency support), for resolving information dependencies (i.e., traceability supports), for providing separation-of-concerns and abstraction (i.e., views/workspaces support), and for composing and recording decisions (i.e. Structuring and Management). The process management services provide support for work planning, design review, and resolution of process issues (i.e., workflow management).

Table 4 shows the comparison framework for tool platform approaches. It characterizes a tool integration platform from the perspective of the provided services and the implementation of these services. These perspectives are explained in the following together with factors part of the framework.

• The end-user services answer the questions of “What end-user services are provided by the platform?” and “how well are tools integrated?” The former question considers supported functions such as analysis, transformations, and configuration management. The answer to the latter question describes the quality concerns of provided services, e.g., configurability and flexibility of the platform.

o View integration: there are different views of a system including the core product and various aspects (e.g., safety and performance) with respect to the product.

-40-

• The implementation refers to the engineering support to implement provided functions, e.g., the information management mechanism and integration mechanism such as API and Wrapper. This is the interpretation of question “How are those provided services implemented?”

Table 5 gives an example where the framework is used to compare two of the platforms approaches.

-41-

Table 4 Interpretation of comparison framework for tool integration platform

Factors Definitions Examples Motivations Relating to problems to be solved. SW-HW Co-design

Product Relating to the type of product or its aspects under consideration.

Embedded SW, generic SW;

Stakeholders and organization

Relating to the people and organization that either apply an approach or are affected by the results of it.

Architects, managers; OEM, SME.

User Interface Means by which users interact with the system GUI

Integration Coverage

Relating to the targets of integration in terms of disparate models, tools, and files, and their relationships, e.g. refinement and/or communication

State Machines, Simulink; documents;

Analysis

Relating to explicit support for assessments of product functionality, feasibility, or other qualities, and for product integration and implementations in terms of either simulations or code generation.

Co-Simulation for analysis of control performance; Formal analysis

Transformation and Synthesis Relating to synthesis and transformation support Code generation

Product Composition Components that involved in the integration Discrete time model, View

Integration Aspect Composition Different views of the system Control function

view, software view Workflow Management Coordinated services provide by integrated tools

Configuration Management Relating to the tracking, record, control and other management tasks of system artifacts throughout the lifecycle.

Version control, access control, variant configuration

End-user Services

Quality of Services The configurability, adaptability, portability, extensibility, performance, security, scalability

Integration Mechanisms and Architecture

Relating to the ways of performing integrations, in terms of the adopted functions, communications, and process.

API, Plug-ins, Imperative languages, wrapper

Realization Relating to the adopted technologies, environment, and infrastructure for the integration.

PDM system, XMI, GME, EMF.

Definition of Integrated Product Structure

Relating to explicit support for creating the global product structure based on information acquired by disparate sources, including versions, variants,, product-family specification, and definition of dependency as well as rules for transformation or mapping-

A complete system model, for one or more product variants

Consistency Support

Relating to explicit support for handling the coherence and accordance of structurally or semantically related information of disparate sources, due to duplication, composition, refinement, or implementation, etc.

Type-checking, relationship rules

Traceability Support

Relating to explicit support for tracing the propagations of design decisions or faults across disparate models/tools throughout the product lifecycle such as to resolve conflicts or effects of changes.

Navigation based on defined relations between design entities, Impact of Changes.

Views/ Workspaces Support

Relating to pre-defined support AND/OR possibility for retrieving a subset of systems information from disparate sources, and then forming a user-defined design space for a particular design task.

Pre-defined views as well as stake-holder definable views.

Versioning and Storing

Relating to the composition and storage of global product development information from disparate sources as well as the support of access control, file and version management, and distribution.

Central repository

Event Management Relating to pre-defined support AND/OR possibility for generating events that support the coordination of work among several developers

Synchronized plug-ins. Event notification.

Implementation

Others For example: Support for concurrent and distributed engineering

E.g. web access

Process Support Relating to the platform/software development process and supported process.

Code generation and allocation.

-42-

Table 5 An example of platform approaches comparison

Factors Fujaba GeneralStore

Motivations

To integrate various tools and notation in a common environment and to manage inconsistencies.

To assist integrated development process from modelling to code with tool integration management

Product software systems Embedded control systems (one focus is automotive applications)

Stakeholders and organization

Software designer, system integrator Software designer

User Interface GUI is provided e.g., FSA A system browser is available

Integration Coverage

Data and notations in tools like UML and SDL. Graphical features like menus and toolbars

software system, time-discrete, time-continuous, and discrete-event models

Analysis Depending on the integrated tools e.g., SDL Rapid prototyping for early verification

Transformation and Synthesis Code generation Rapid prototyping for final synthesis.

Code generation and integration. Product Composition Support Support Data

Integration View Composition Support Central system view in UML and

domain views Control Integration New plug-in can be added Supported by code integration

Configuration Management NA User authentication, transaction management, and configuration management

End-user Services

Quality of Services

Only tools specially developed for the Fujaba environment can be integrated

Adapters for Artisan Rea-time studio and Matlab/Simulink/Stateflow and, With code generator and meta-modeling in UML, new tools can be added.

Integration Mechanisms and Architecture

Plug-in mechanism in a modular platform with XML configuration files

An object repository stores all tools (meta) data and manages their mappings; A CASE-tool integration environment with 3-tiered architecture

Realization

Java code XMI based interchange of (meta) data. MOF is used as database schema. ORACLE/MySQL for database management. Adapters are developed for CASE tools

Definition of Integrated Product Structure

System structure can be defined by instantiating the integrated/extended meta-model, which also defines relation rules based on MOF

The whole system concept is defined as an instance of one particular metamodel in one UML notation with subsystem development in domain specific tools

Consistency Support

Meta-model restrictions and dedicated consistency services

A central systems model in UML with support for model-level white-box mapping across domains and support for cross-reference

Traceability Support

NA The data repository keeps track of the usage and refinements of elements; A unique identification number for each domain block; A system hierarchy browser and domain specific hierarchy browsers.

Views/ Workspaces Support Via plug-in mechanism Central system view in UML and domain views

Versioning and Storing

Data is stored in local tools

A database such as Oracle and MySQL is adopted. An interim project file is created once a check-out happens. Further versioning is supported

Event Management Synchronization of tool features.

Support concurrent engineering in a top-down paradigm. It controls the access to models.

Implementation

Others NA NA

Process Support Focusing on software and implementation design.

Entire development process.

-43-

6 Case studies This section describes two case studies. The first one focuses on one particular aspect of model and tool integration, the integration of subsets of Matlab/Simulink with UML2 with respect to the technical possibilities and challenges. The cross-domain information flow, the implications on model transformations and potential solution approaches are elaborated. Some open issues are discussed and a preliminary mapping strategy is also presented together with a proof-of-concept implementation in Eclipse environment. The details of this work are mainly described in Paper A. In the second case study, a safety analysis tool, HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies) [89], is integrated with a UML tool used for architecture design and modelling to enable safety analysis during system architecture design. This work is mainly described in Report B.

6.1 Background These two case studies are mainly performed in the context of the ATESST (Advancing Traffic and Efficiency and Safety through Software Technology) project [8] , where an architecture description language EAST-ADL2 is developed as a UML2 profile to facilitate the development of automotive EE (electrical/electronics) systems. The focus of EAST-ADL2 is to provide structured system information management for complex automotive software development. This is done by defining modeling constructs at different abstraction levels, from abstract function specifications to operational software code. Figure 4 shows the five abstraction levels that are defined in EAST-ADL2: the vehicle level, analysis level, design level, implementation level, and operation level [9]:

- the vehicle level describes system model in terms of features from an end user’s perspective;

- the analysis level gives a top level description of functions that realize those vehicle features;

- the design level specifies those functions in terms of functional contents;

- the implementation level describe a system with respect to software components, middleware, and hardware platform;

- the lowest operational level model of a system describes the deployment, i.e., how software are allocated into hardware.

Given the defined constructs at these levels, a single information model for the entire system can be created using the EAST-ADL2 supporting the integration design scenarios that are identified in section 5.2. For example, domain specific models are represented in the information model and thus subsystems composition and overlapping information can be more easily managed. Also, system architecture design becomes easier because of the information model. Subsystems can be refined

-44-

in corresponding areas and information in the subsystem can be easily traced into the system architecture.

Figure 4 ATESST electrical/electronics architecture (taken from [9])

The EAST-ADL2 adopts the UML2 composite structure diagram for structural representation. One reason for this is that the composite structure diagram was introduced into UML with the explicit purpose to show logical relationships between elements of a complex class and to identify their collaborations [45]. Activity diagram is currently chosen for behavioural modeling, and other diagrams are under investigation.

Figure 5 shows the tool-chain in the case studies. The UML modeling is based on the Eclipse UML2 environment and using the open source UML graphical tool Papyrus developed in the ATESST project.

Two Eclipse plug-ins have been developed, of which the Simulink plug-in parses an mdl file that stores the Simulink model and transform to corresponding UML2 models (see also Figure 5). The safety analysis plug-in extracts error information from a model designed using EAST-ADL2 and transfers them into a hip file, then invokes HiP-HOPS using this file as an input for safety analysis in terms of FTA (Fault Tree Analysis) [48] and FMEA (Failure Modes and Effects Analysis)[88].

System Behaviour:

Activity diagram

HiP-HOPS

Eclipse UML2

EMF

Papyrus

Simulink

.mdl

System Structure:

Composite Structure diagram

EAST-ADL2 User model

.hip

Figure 5 Tool-chain in the case studies

-45-

6.2 Integrating Simulink and UML2 Matlab/Simulink is a very common tool for model-based control system design and simulation, whereas the design of embedded systems software is increasingly based on the evolving UML and its derivatives. Both have been widely used in electrical system design [32]. Matlab/Simulink is widely used in control engineering mainly for the design and simulation of advanced automatic control functions. It describes system behaviours in terms of mathematical relationships with graphical notations. Simulink provides support for embedded system design at code level but does not directly support their software/hardware implementation. Several extensions have been adopted to cover this for the purposes of code generation or directly reasoning about implementation effects [115][92]. The coverage of UML and Matlab/Simulink technologies is illustrated in Figure 6, where the “Internal” and “External” in Figure 6 (b) refer to the system content and the embedded systems environment respectively.

(a) (b)

Figure 6. Qualitative depiction of the use of UML and Simulink in embedded systems modeling

Given that UML and Simulink are used to represent different views/concerns related to the product, the integrated system design requires a combined usage of both, where several transformation scenarios are identified in Paper A:

- UML for systems engineering and Simulink for control function development.

In this scenario, a single UML model contains the complete system model and Simulink is considered as a specific system view. This is the way that the ATESST approach proposes. A bidirectional transformation between UML and Simulink is thus desired for both structural and behavioural mapping depending on the purpose.

- Simulink for functions design and UML for software design.

One design case for this scenario is to impose, e.g., functional structures as the basis for software structures or vice versa, where a structural transformation is necessary. Another possible case is to analyze the software design through simulation, where a transformation of behavioural aspects to Simulink from UML models is required.

Abstraction Level

System Content

Design

Implementation

Structure Behavior

UML

Tool boxes

Simulink

Abstraction Level

System Content

Design

Implementation

Structure Behavior

UML

Simulink

System ContentStructure Behavior

External

UML

SysML

UMLInternal UMLSimulink

System Boundary

-46-

- Composition of subsystems developed in both UML and Simulink.

This design can be realized in different ways, e.g., through code integration. However, given different purposes, model transforms may be necessary, e.g., when an overall system model is required, Simulink models need to be transformed and integrated with UML models, as done in the GeneralStore approach and in this case study.

Following sections introduce the structural and behavioural mapping between UML2 and Simulink and discuss the integration strategies and preliminary results.

6.2.1 Structural and behavioural mapping

Structure Mapping:

From a systems engineering viewpoint, the system structure represents concrete solution elements to which system functions are allocated. In modeling, a different logical structure can also be imposed on both behavioural 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.

As mention before, in the structural mapping we focus on the composite structure diagram in this work. The detailed mapping design and discussion are given in Paper A; and more information about the implementation is given in Report B. Figure 7 and Figure 8 give an example result produced from the developed prototype tool. A vehicle model is designed in Simulink, shown in Figure 7 (a) (the picture shows only a simplified model). Four subsystems are illustrated in the picture, namely HMI, Vehicle environment, Perception and Vehicle application respectively, each of which consists of subsystems as well. Figure 7 (b) shows the design of HMI subsystem. Figure 7 (c) shows the UML2 model transformed from the Simulink vehicle model in a composite structure diagram, and Figure 8 gives a tree description of the produced UML2 model.

The transformation is performed by first generating the class definition of all structure entities and then considering the compositional and communication relationships. A block/subsystem in Simulink, “HMI”, is represented by a UML2 class, “HMI”, and instantiated as a property of the class “vehicle” as indicated in Figure 8. An outport in block “HMI”, “acc_enable”, which is actually also a block with the type outport, is represented by a provided-port of class “HMI”. This provided-port is defined by an interface. A line in Simulink connecting two blocks is represented by a connector.

-47-

acc_enable [0/1]

accelerator_pedal_request [Nm]

measured_wheel_speed (4) [km/h]

vehicle_speed [km/h]

rain_intensity [%]

acc_mode [0/1]

moderated_torque_request [Nm]

Vehicle application

engine_torque [Nm]

acc_enable_button [0/1]

desired_target_distance [s]

wheel_speed (4) [km/h]

rain_intensity [mm/h]

Vehicle Environment

wheel_speed (4) [km/h]

rain_intensity [mm/h]

measured_wheel_speed (4) [km/h]

mean_vehicle_speed [km/h]

rain_intensity [%]

Perception

acc_enable_button [0/1]

desired_target_distance

acc_enable [0/1]

Pedal acc torque request [Nm]

HMI

(a) Simulink view of a model

(b) Simulink view of the subsystem “HMI”

(c) UML2 composite diagram of the example system

Figure 7 An example of mapping Simulink and UML structure

1 acc_enable [0/1] Input Output

button_sensor vehicle_speed [km/h]

acc_mode [0..3]

desired_target_distance [s] Gauges

4 acc_mode [0..3]

3 vehicle_speed [km/h]

2 desired_target_distance [s]1

1 acc_enable_button [0/1]

-48-

Figure 8 UML tree view of the example system

Behavioural Mapping

The behavioural aspects refer to different models of computation and communications (MoCCs). Basic elements to describe behaviours include 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 like client-server.

Three overall types of MoCCs can be modelled by Simulink: continuous-time, discrete-time, and event-triggered. Data-flow is also supported by Simulink and can be considered as a special variant of the event-triggered communication. Simulink uses different types of blocks, e.g., continuous-time blocks and discrete-time blocks for the corresponding MoCCs, as shown in Table 6. Primitive blocks are pre-defined in the Simulink library. Compositions of primitive blocks form subsystems which are virtual or non-virtual.

The fundamental unit for behavioural description in UML2 is a set of actions. A number of primitive actions such as the reading of and writing are predefined. The concept of OpaqueBehavior with attributes (body, language) [117] is introduced for user-defined behaviors given in terms of a specific language (e.g., C-code, text, reference to an external file, or an equation). Based on the basic actions, there are three kinds of behaviour formalisms in UML2: activities, state machines and interactions. Behaviours described by these formalisms are essentially restricted to discrete-time and event-triggered MoCCs.

Because both UML2 and Simulink are rich languages, the study of mappings is delimited to focus on a subset of UML2 behaviour, mainly the activity diagrams. For Simulink we do not include the Stateflow behaviour. Since mathematical relationships

-49-

described in Simulink are mainly data-flow and control-flow, it is natural to map the Simulink behaviour to UML2 activity diagrams, which are described by connected executable nodes (action nodes), control nodes and object nodes. The use of activity diagrams for mathematical equations has been explored in [17].

Table 6: MoCCs and examples of support1

MoCCs Simulink UML Client-server No direct support Sequence FSM Stateflow State machine2 Event-triggered and data-flow

Conditionally executed subsystem and data-flow blocks

Activity

Discrete-time Sampled blocks Activity3 Continuous-time Continuous-time- blocks Activity

Detailed discussions on mapping and the representation of behaviours in terms of different MoCCs, i.e., Client-server, Event-triggered, Data-flow, Discrete-time, and Continuous-time, are given in Paper B. An example of mapping Simulink primitive blocks with UML2 concepts is given in Figure 9, which shows a Simulink model (Figure 9a) and a corresponding UML2 model (Figure 9b) of the expression

( )tuxx +=•

2 (Eq. 1)

Blocks such as Sum and Integrator are in UML2 represented by actions, e.g., Add and Integrate over time. The proposed strategy is to define such actions as part of a model library of a UML2 profile, i.e., a dedicated package where types are defined, which are available when later applying the profile to a model. To do so, one could make a list of them in terms of OpaqueActions referencing functions available in another language, e.g., Simulink, via a pair of (body, language) attributes. If needed, more elaborated actions could be defined, made out of sequence of calls to such Simulink-based OpaqueActions and other calls.

1 See detailed discussions in Paper B 2 The mapping between Stateflow and State machine is not straight forward, and it is beyond the scope of this thesis. 3 Discrete-time can be described by activity diagram in terms of triggered by time-event.

Figure 9 Simulink model and UML2 activity diagram for numerical solution of Eq. 1

(a)

(b)

-50-

6.2.2 Integration implication and discussion

The transformation between Simulink and UML2 models implies correct semantics and syntax mapping between them. However, due to the richness of languages and the various usages, it is impossible to provide a general solution that gives a unique mapping. The mapping strategy varies depending on the actual needs. UML describes both behavioural and structural aspects, but all behaviours are attached to structural entities. However, Simulink essentially describes system behaviours, i.e., with a main emphasis on “what the system does” although a logical model structure can be imposed on the behaviours. 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 UML2 structural diagrams for information management purposes or a behavioural description of one class representing the subsystem for behaviour 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 UML tools with slightly different implementations of the UML. In this study we focus on the UML2 standard although the option to explore profiling to enable certain mappings is discussed.

The behaviour in Simulink can be interpreted in two ways: either from the language viewpoint or from the viewpoint of the observable simulation behaviour. The simulation behaviours of a Simulink model depend on the precise ordering of the blocks during simulation. This ordering is determined by the simulation engine and depends among other things on the MoCCs involved. Therefore the mapping strategy has to take the purpose of mapping into account, such as for system behaviour specification or detailed simulation behaviour description. For example, the mapping shown in Figure 9 can be useful for system representation purposes. It is not however always adequate to represent the intended semantics in terms of the ordering of the actions. This is because the graphical view of the Simulink model in Figure 9 may not represent the exact execution ordering. In Simulink many blocks contain states, e.g., the integrator in Figure 9 . The simulation behaviour in the above Simulink model will in fact start at the output of the integrator, taking into account its initial value, and then continue with the Gain and Sum blocks. In the activity diagram of Figure 9, the Add action will instead be provided with a default value and run before the Integrate over time. The difference in execution order may lead to different simulation results. Indeed one could refine the first UML2 activity diagram in several versions to account for the different solver strategies used by Simulink.

6.3 Integrating HiP-HOPS and system architecture design This section describes a case study integrating a safety analysis tool, HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies), to the Eclipse

-51-

platform, where an architecture design model is developed using the EAST-ADL2. The case study includes two main stages of work:

- Error modelling stage: This phase defines possible failures in the system (both functional failures and component failures), the propagation, and other failure data needed to produce the fault tree and perform analysis. The result of this process is a hierarchical model (user model) annotated with failure data. This stage in fact contains three steps of work: 1) defining safety concepts in the ATESST domain concepts modeling; 2) defining the EAST-ADL2 profile; and 3) modeling a particular system using the profile, i.e., a user model.

- Tool development stage: This second phase produces dedicated plug-in. It examines the user model, captures its failure data and transfers them to the HiP-HOPS and invokes the analysis.

The following section will introduce main concepts for safety analysis support in HiP-HOPS and EAST-ADL2, followed by presentation of the conceptual mapping and the implementation of integration.

6.3.1 Safety analysis and HiP-HOPS

System safety is considered as one important factor of automotive embedded systems. Normally safety is defined by system-safety engineers “in terms of hazards and risk”[62], where a hazard is a state that potentially can lead to an accident, and a risk is described by several factors such as the possibility of hazards and accident occurring, possible hazards effects and the severity of possible accidents [62].

In order to assess hazards and risks of developed systems, provide proof of confidence, and propose improvements, safety analysis has to be applied in the system development lifecycle by identifying, eliminating and controlling hazards to avoiding or lessening accidents severity. Many different safety analysis techniques have been proposed addressing different aspects of system safety at different stage of system development. For example, Functional Failure Analysis (FFA) [105] is applied at the system top level and Failure Modes and Effects Analysis (FMEA) [88] can be used in the system decomposition.

Based on the classical techniques such as FFA, FMEA, and FTA [48], a new safety analysis method called HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies) [89] was developed by University of York. This method aims to enable an integrated safety analysis from abstract functional level to low level component failure modes based on a hierarchical system description. The analysis process starts from an FFA analysis and produces a hierarchical system model in which possible system hazards are identified. Failure behaviours of components in this model are then further analyzed considering both the local failures of an individual component and its reactions to failures caused by other components. Finally, HiP-HOPS performs a fault-tree synthesis determining faults propagation in the entire system. Currently HiP-

-52-

HOP supports Matlab/Simulink model analysis by using a toolbox which produces failure-modes annotation and needed failure data.

6.3.2 Implementation design and realization

The ATESST approach supports safety analysis by provides a hierarchical system analysis model that consists of failure semantics at each abstraction level, which is introduced in the section 6.1. Main constructs defined in the EAST-ADL2 include ADLFunctionalPrototype, ErrorBehavior and ErrorModel. Table 7 explains these concepts and shows a brief conceptual mapping between EAST-ADL2 and the HiP-HOPS. Detailed design can be found in Report B.

Table 7 EAST-ADL and HiP-HOPS concepts for safety analysis [9]

EAST-ADL2 concept Explanation HiP-HOPS concept

ADLFunctionType It represents basic entities

ADLFuntionPrototype

FunctionalDevice

These two are specializations of ADLFuncitonType

Abstraction Function

ErrorBehavior It defines the Specification of error logic. Properties such as failure logic, propagationport, handling status, and failure effects are defined in ErrorBehavior.

Functions failures, effects, severity

Component failures

ErrorModel It defines the ErrorBehaviors that a entity can have given a specific context

Implementation of a component that synthesis and analysis to take place

ErrorPropagation It defines the relationships between errors of components which can cross abstraction levels.

Propagations of failure and fault

PropagationPort It defines the port that an faulty event can go through

Failure data port

The implementation is performed using EMF (Eclipse Modeling Framework) APIs and Eclipse UML2 APIs. The result is an Eclipse plug-in that loads the system analysis model (in .uml format) chosen by users, captures required failure data and executes the HiP-HOPS tool.

Figure 10 gives an example of analysis results obtained from HiP-HOPS, where (a) shows the top-events and cut set (a cut set in fault tree is a collection of component failures that leads to the system failure), and (b) shows component failures with their direct effects.

-53-

(a) Example of top-events

(b) Example of FMEA direct effect

Figure 10 Output of HiP-HOPS safety analysis

6.3.3 Discussion

The case study included two main stages of work, defining a particular system model annotated with failure data and developing an Eclipse plug-in that transfer the failure data to HiP-HOPS for safety analysis. The first challenge came from the language definition. As the first step of plugin development, a good knowledge of the UML profile details is required. In the project, several profiles existed during the language development. The management of dependencies among them have brought difficulties. Furthermore, the safety analysis tool, i.e., HiP-HOPS, has a very strict syntax on the input format that captures the error behaviours. For instance, the expression for failure logics in EAST-ADL2 has to be translated into specified terms required by HiP-HOPS. Therefore the transformation needs to be robust and allow variations of that expression in the user model designed using EAST-ADL2.

6.4 Experience and lessons learned Development of complex embedded systems normally requires various specific views. We have studied the integration between safety analysis and architecture design using EAST-ADL, as well as the integration between Matlab/Simulink and UML2. Two prototype plug-ins have been developed based on the Eclipse environment for model transformation and tool integration.

-54-

Developing plug-ins in the two experiments requires good knowledge of Eclipse including EMF and UML2 APIs. However, there is a lack of clear explanations for the large amount of APIs which leads to difficulties in properly using them.

UML diagrams are often used to visualize a system. Although these diagrams are supported by Eclipse with different solutions such as the GMF (Graphical Modeling Framework) [30]and other plug-ins, e.g., the Papyrus used in this work, the transferring of graphical information is still a challenge. For example, when a model is transformed into a UML2 model and needs to be visualized, two situations may be met: 1) There is no graphical diagram for the original model. In this case, creating a diagram requires additional information which is difficult to be managed automatically. 2) There is a graphical diagram for the original model and the corresponding information is captured. However, it is common that the number and size for blocks may change after transformation and it is not an easy task to determine layout of blocks automatically, e.g., the positions and style of connecting lines.

Another lesson is that it is difficult to efficiently manage the large amount of plug-ins which are used in studies, especially when different versions of Eclipse platform are used.

The developed transformations so far are not really scalable. A systematic approach for efficient development of model transformations is desired to standardize the design process and reuse developed transformations. To this end, future studies will be carried out to develop guidelines for model and tool integration and to provide support for structured information at both meta level and instance level.

-55-

7 Conclusion and future work The development of advanced embedded systems inevitably requires integration of multiple views from various domains. In practice domain specific tools have been developed for specific needs, which commonly only support handling of a limited number of aspects. A strong need can be seen to systematically manage information represented in different model/tools, to coordinate heterogeneous domain specific tools, and to support various types of analysis (e.g., safety and reliability). To enable the system architecting and seamless integration of different views, an approach that provides information management at the system level and information exchange between tools is required.

We have studied different model and tool integration approaches, where we investigate the motivations, engineering context, integration coverage, integration techniques, and engineering support. We particularly performed a case study for the integration between Matlab/Simulink and UML2, and a case study for integrating a safety analysis tool with a UML tool. We developed a framework, identified scenarios, and discussed possible solutions.

Embedded systems behavior is normally described by different models of computation and communications with different tools and languages, e.g., in Simulink and UML. A preliminary mapping strategy is developed to integrate subsets of Simulink models and UML2 models. However, the strategy of correct mapping and integration between them is highly relying on the purposes, e.g., for system composition or overall system information management. The behavioral mapping is still seen as a challenge with many open issues, such as the simulation method, selection of solvers and timing, as discussed in the case study. In future work, these issues will be further studied. To represent the correct time information and correctly define action behaviors, action languages in UML modeling are also one of the important concerns in the further consideration.

The current implementation of mapping Simulink to UML2 is limited to single direction mapping, bi-directional transformation is considered in the future development. In the developed tool, transformation is based on .mdl files which contain Simulink models. In the further development, the Matlab APIs will be used for interactions between Simulink model and UML2 models.

The parsing and transformation of .mdl files are currently performed by a specific developed parser. Further study will be performed on transformation languages and related tools, for example, the ATL [10] and XSLT [123].

From the automotive perspective, one important work is to have a way to relating Autosar and Simulink. The former focuses on a low level software/hardware implementation, and particular emphasis is put on non-functional issues such as software modularity. The latter has the focus on function development and simulation of

-56-

control systems. Thus a correct concept mapping between Autosar and Simulink would be fruitful.

The development of complex embedded systems requires numerous specific views. We have studied the integration between Matlab/Simulink and UML2, and between EAST-ADL2 and a safety analysis tool. There are also many other domain-specific models and tools involved in the development, for example, requirement modelling tools such as Doors [112], which is considered in the future integration platform. In order to provide efficient model management, connecting to a PDM (Product Data Management) systems is also of consideration in future and is planned as an industrial case study.

To verify the product quality at an early stage, analysis is important for error checking and refinement support. The study of integration analysis tools, e.g., safety analysis tool with UML tool, is in progress. However, it is still in a very early stage. More work on this will be performed in the future work with integrating more analysis tools such as the timing analysis with the platform.

A further investigation of current practices on model and tool integration in automotive industry is planned. Based on experiences learned, a guideline for model and tool integration will be developed. The developed platform will be tested and verified through further industrial case studies.

-57-

References [1] Adamsson, N. “Mechatronics engineering-New requirements on cross-functional

integration”, Licentiate thesis, Machine Design, KTH, TRITA-MMK 2005:04, ISSN 1400-1179, ISRN/KTH/MMK/R-05/04-SE, 2005.

[2] Altheide, F., H. Dörr, A. Schürr, "Requirements to a Framework for sustainable Integration of System Development Tools", Proc. of the 3rd European Systems Engineering Conference (EuSEC'02), Toulouse: AFIS PC Chairs, 2002, pp. 53-57.

[3] Alanen M., T. Lundkvist, and I. Porres, “A Mapping Language from Models to XMI[DI] Diagrams”, TUCS Technical Report, No 676, April 2005.

[4] AQUINTOS, http://www.aquintos.info/de/.

[5] Architecture Analysis & Design Language (AADL), SAE standard AS5506, issued November 2004. http://www.aadl.info.

[6] ARTEMIS Strategic Research Agenda, Design Methods and Tools, available on www.artemis-office.org, accessed in 2007.

[7] ATESST project Deliverable D6.1.1 - Elicitation of overall needs and requirements on the ADL – Part II. M. Törngren (editor). By the ATESST consortium. EU IST project contract number: 2004 – 026976. Available from www.atesst.org.

[8] ATESST project, http://www.atesst.org, accessed in 2007.

[9] ATESST Report: the Modelling approach in ATESST – Overview, available on http://www.atesst.org, accessed in 2007.

[10] ATL, Atlas Transformation Language, http://www.sciences.univ-nantes.fr/lina/atl/, accessed in 2007.

[11] AUTOSAR, http://www.autosar.org, accessed in 2007.

[12] Babich, W.A., “Software Configuration Management: Coordination for the productivity”, Reading, MA: Addison Wesley, 1995.

[13] Balzer, R. “Tolerating inconsistency”, In Proceedings of the 13th international conference on Software engineering, PP.158 – 165, ISBN:0-89791-391-4, 1991.

[14] Becker, S.M., T. Haase, and B. Westfechtel, “Model-based a-posteriori integration of engineering tools for incremental development process”, Software and Systems Modeling, Volume 4, Issue 2, 10 November 2004, Spring-Verlag 2004.

[15] BMW company, http://www.bmw.com/.

[16] Boldyreff, C., D. Nutter, R. Stephen, M. Smith, P. Wilcox, R. Dewar, D. Weiss, and P. Ritrovato, “Environments to support collaborative software engineering”, 2nd Workshop on Cooperative Supports for Distributed Software Engineering Processes, 25-28 March 2003, Benevento, Italy.

[17] Bock, C. “SysML and UML 2 support for activity modeling”, Systems Engineering, P160-186 Vol.9. 2006.

[18] Brown, A.W., D.J. Carney, E.J. Morris, D.B. Smith, P.F. Zarrella., Principles of CASE Tool Integration. 1994, Oxford New York: Oxford University.

-58-

[19] Brown, Alan W., Control integration through message passing in a software development environment, Technical Report, CMU/SEI-92-TR-035, ESD-TR.92-35, Carnegie Mellon University, 1992.

[20] Braun, P. and Rappl, M., A Model-Based Approach for Automotive Software Development, Proceedings of OMER Workshop – Object-oriented Modeling of Embedded Real-Time Systems, 2002, available at http://www.forsoft.de/automotive/.

[21] Burmester, S., H. Giese, S., J. Niere, M. Tichy, J.P. Wadsack, R. Wagner, L. Wendehals, and A. Zündorf, “Tool integration at the meta-model level: the Fujaba approach”. International Journal on Software Tools for Technology Transfer, Springer Berlin Heidelberg, 11.11.2004, vol. 6, no. 3, pp. 203-218.

[22] Chen, D., M. Törngren, J. Shi, Sebastien Gerard, Henrik Lönn, David Servat, Mikael Strömberg, and Karl-Erik Å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. 2006.

[23] Czarnecki, K. and S. Helsen, “Classification of Model Transformation Approaches”, in proceedings of the OOPSLA'03 Workshop on the Generative Techniques in the Context Of Model-Driven Architecture, Anaheim, California, USA, 2003.

[24] Dahlqvist, A.P. “Product Data Management and Software Configuration Management Integration”, Licentiate Theses, Mälardalen University, 2005.

[25] dSPACE, http://www.dspace.de.

[26] EAST-EEA Consortium, “Embedded Architecture and Software Technology”, http://www.east-eea.net.

[27] Eclipse Model Driven Development integration (MDDi) project, http://www.eclipse.org/mddi/, accessed in 2007.

[28] Eclipse Generative Modeling Technologies (GMT) project, http://www.eclipse.org/gmt/, accessed in 2007.

[29] Eclipse Modeling Framework (EMF), http://www.eclipse.org/modeling/emf, 2007.

[30] Eclipse Graphical Modeling Framework (GMF) www.eclipse.org/gmf/, 2007.

[31] EDIF, available: http://www.edif.org.

[32] Electronic Weekly & Celoxica “Survey of System Design Trends 2005”, http://www.celoxica.com, 2005.

[33] El-Khoury, J., D. Chen, M. Törngren, “A survey of Modeling approaches for embedded computer control systems”, Technical report, Trita-mmk 2003:36 ISSN 1400-1179, ISRN KTH/MMK/R-03/11-SE, 2003.

[34] El-Khoury, J. “A Model Management and Integration Platform for Mechatronics Product Development”, Doctoral Thesis, Trita-MMK 2006:03, ISSN 1400-1179, ISBN 91-7178-268-0. Royal Institute of Technology, KTH, Stockholm, 2006.

[35] Eppinger, Steven D., Vesa K. Salminen, “Patterns of Product Development Interactions International Conference on Engineering Design”, Glasgow, Scotland, August 2001, http://web.mit.edu/eppinger/www/pdf/Eppinger_ICED2001.pdf.

[36] Ernst, J. Introduction to CDIF, available: http://www.eigroup.org/cdif/intro.html.

-59-

[37] Estublier J., J-M. Favre, and P. Morat, Toward SCM / PDM Integration? In Proceedings of the SCM-8 Symposium on System Configuration Management SCM8, Brussels, 1998. In LNCS 1439, Springer Verlag.

[38] ETAS, ASCET-SD, available at: http://www.etasgroup.com.

[39] Frankel, R. The ToolTalk Service. Sun Microsystems Inc., Mountain View, CA, 1991. 8.

[40] Freude, R. and A. Königs, “Tool integration with consistency relations and their visualization”, Workshop at ESEC/FSE 2003, 9th European software Engineering Conference and 11th ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 6-10, 2003, Helsinki.

[41] Frischkorn, H. “What is new at SAE 2003”, Automotive Engineering International Online, http://www.sae.org/automag/whatsnew/2003/tuesday.htm. Accessed in 2007.

[42] Fromme, B.D. "HP Encapsulator: Bridging the Generation Gap," Hewlett-Packard journal, Vol. 41, no. 3, june 1990, pp. 59-68.

[43] Grundy, J.C., J. G. Hosking and W. B. Mugridge, “Inconsistency management for multiple-view software development environments” IEEE Transactions in Software Engineering, 24(11) 1998, pp.960-981.

[44] Hapke, M., A. Jaszkiewicz, K. Kowalczykiewicz, D. Weiss and P. Zielniewicz, "OPHELIA-Open Platform for Distributed Software Development”, http://www.cs.put.poznan.pl/dweiss/site/publications/download/hapke-osic-2004.pdf.

[45] Holt, J., “UML for Systems Engineering: watching the wheels”, The Institute of Electrical Engineering, London, 2004.

[46] Harel, D. "Statecharts: A visual Formalism for complex systems", The Science of Computer Programming, 1987, 8, pp.231-274.

[47] Hyowon, S. Concurrent Engineering and PDM [IE553], Lecture Note, 2006 Fall.

[48] IEC 1025: Fault Tree Analysis (FTA). International Electrotechnical Commission, 1990

[49] IEEE-Std-610, Configuration Management. IEEE Standard Glossary of Software Engineering Terminology (corrected edition). IEEE Standards Collection--Software Engineering, 1993 Edition, Institute of Electrical and Electronics Engineers, Inc., New York, 1993.

[50] International workshop on Graph and model transformation 2006 (GraMoT), UK. http://tfs.cs.tu-berlin.de/gramot/Gramot2006/schedule.html

[51] JMI, Java Metadata Interface, http://java.sun.com/products/jmi, accessed in 2007

[52] Jézéquel, J.M. “Model transformation techniques”, course slides, available at http://www.pst.ifi.lmu.de/~kochn/mdwenet/teaching_material/ModelTransfo-Jezequel.pdf, accessed in 2007.

[53] Johansson, B. “Model management for computational system design”, PhD thesis no. 857, ISBN: 91-7373-791-7, Department of mechanical engineering, Linköping University, 2004.

[54] Karsai, G., A. Lang, S. Neema, “Design patterns for open tool integration”, Software and Systems Modeling, Volume 4, Issue 2, 10 November 2004 , Spring-Verlag 2004, pp. 157-170.

-60-

[55] Kappel, G., G. Kramler, E. Kapsammer, T. Reiter, W. Retschitzegger, W. Schwinger, “Towards a Semantic Infrastructure Supporting Model-based Tool Integration”, International Conference on Software Engineering archive Proceedings of the 2006 international workshop on Global integrated model management, Pages: 43 – 46, ISBN:1-59593-410-3, Shanghai, China, 2006.

[56] Klaus, D., G. Müller, G. Frick, E. Sax, and M. Kühl, “Multiparadigm Modeling in Embedded Systems Design”, IEEE Transactions on Control Systems Technology, Vol. 12, No. 2 (March), 2004, pp. 279-292.

[57] Kruchten, P. “Architectural Blueprints—The “4+1” View Model of Software Architecture”, IEEE Transactions on Software Engineering, 12 (6),November 1995, pp. 42-50.

[58] Kurtev, I. Alignment of ATL and QVT, lecture slides, http://www.modelware-ist.org/index.php?option=com_content&task=view&id=93&Itemid=140, 2007.

[59] Königs, A. and A. Schürr, "Tool Integration with Triple Graph Grammars - A Survey", Proceedings of the SegraVis School on Foundations of Visual Modelling Techniques, London: Academic Press, 2005; Electronic Notes in Theoretical Computer Science.

[60] Larses, O., and Chen, D., “The Monty Model for Engineering of Mechatronics systems”, Technical Report, TRITA-MMK 2003:11, ISSN 1400-1179, Royal Institute of Technology, KTH, Stockholm, 2003.

[61] Lee, Edward A. “Overview of the Ptolemy Project”, Technical Memorandum No. UCB/ERL M03/25, University of California, Berkeley, CA, 94720, USA, July 2, 2003.

[62] Leveson, N. G. “Software safety in embedded computer systems”. Communications of the ACM, Volume 34 Issue 2, February 1991.

[63] Maier, M.W, Emery, D., and Hilliard, Rich, “Software Architecture Introducing IEEE Standard 1471”, available at http://ieeexplore.ieee.org/iel5/2/19820/00917550.pdf.

[64] Malone, B. and M. Papay, “ModelCenterTM: An Integration Environment for Simulation Based Design”, http://www.phoenix-int.com/library/papers.php.

[65] Malone, B., “A Simulation Based Design Environment for Network Centric Warfare Using Distributed Analysis”, http://www.phoenix-int.com/library/papers.php.

[66] Malvius, D. “Information Management for Complex Product Development”, Licentiate thesis, TRITA-MMK 2007:09, ISSN 1400-1179, Department of Machine Design, KTH, August 2007.

[67] Muller-Glaser, K.D., C. Reichmann, P. Graf, M. Kuhl, and K. Ritter, “Heterogeneous Modelling for Automotive Electronic Control Units Using a CASE-tool Integration Platform”, Computer Aided Control Systems Design, 2004, IEEE International Symposium on 2004, pp. 83 – 88, 2004.

[68] Model-Integrated Computing approach for software systems design, available at http://www.isis.vanderbilt.edu/Research/mic.html, accessed in 2007.

[69] MODELWARE, http://www.modelware-ist.org/.

[70] Model transformation in practice 2005, http://sosym.dcs.kcl.ac.uk/events/mtip05/, accessed in 2007.

-61-

[71] Mathworks Automotive Advisory Board (MAAB), http://www.mathworks.com/industries/auto/maab.html.

[72] Matlab/Simulink ®, product of Mathworks, www.mathworks.com, accessed in 2007.

[73] Modelica modeling language, http://www.modelica.org/, accessed in 2007.

[74] M2M project, http://www.eclipse.org/m2m/atl/.

[75] Modcomp project, http://www.md.kth.se/RTC/modcomp/.

[76] Meta-model, http://www.metamodel.com; 2007.

[77] Nutter, D., C. Boldyreff, and S. Rank,, “An Artefact Repository to Support Distributed Software Engineering”, In: 2nd Workshop on Cooperative Supports for Distributed Software Engineering Processes, 25-28 Mar 2003, Benevento, Italy.

[78] Oliver, D.W., T.P Kelliher, J.G. Keegan Jr., “Engineering Complex Systems with Models and Objects”, McGraw-Hill, 1996.

[79] Ohlin, M., D. Henriksson, A. Cervin, TrueTime 1.5—Reference Manual. Manual, Department of Automatic Control, Lund University, Sweden, January 2007.

[80] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-01.

[81] OMG, UML Profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE), http://www.omg.org/cgi-bin/doc?realtime/2005-2-6.

[82] OMG: OMG/RFP/QVT MOF 2.0 Query/Views/Transformations RFP, version 1.1.

[83] OMG, XML Metadata Interchange, Available at http://www.omg.org.

[84] OMG, XMI[DI], Diagram Interchange version 2.0, July 2003. OMG document ptc/03-07-03. Available at http://www.omg.org.

[85] OMG SPT profile: UML Profile for Schedulability, Performance and Time (SPT), version 1.1.

[86] Petri Net, http://www.petrinets.info.

[87] Ptolemy II, the Ptolemy project, http://ptolemy.eecs.berkeley.edu/ptolemyII/index.htm.

[88] Palady, P. “Failure modes and effects analysis”. PT Publications, West Palm Beach, FL, 1995. ISBN: 0-94545-617-4.

[89] Papadopoulos, Y., J. A. McDermid. Hierarchically Performed Hazard Origin and Propagation Studies. SAFECOMP 1999: 139-152.

[90] Ramesh, B. “Process knowledge management with traceability”, IEEE Software, Volume 19, Issue 3, May-June 2002 Page(s):50 – 52.

[91] Rechtin, E. and MW Maier, The Art of System Architecting, CRC Press, 1997.

[92] Reuter, J., “Analysis and Comparison of 3 Code Generation Tools”, SAE World Congress 2004. Detroit, MI. March 8-11. 2004. SAE 2004-01-0702.

[93] Reichmann, C., 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," ecbs, pp. 225 - 232, 11th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS'04), May, 2004.

[94] Reiss, St.: Interacting with the FIELD Environment, in: Software Practice and Experience 20, S1, 89-115, John Wiley & Sons, New York (1990).

-62-

[95] Sage, Andrew P. and Charles L. Lynch, “Systems Integration and Architecting: An Overview of Principles, Practices, and Perspectives”, Systems Engineering, Volume 1, Issue 3, 1998, Pages 176 – 227.

[96] SAVE and SAVE++ project, http://www.mrtc.mdh.se/SAVE/.

[97] Saber product, http://www.synopsys.com/products/mixedsignal/saber/saber.html.

[98] Schopfer, G., A. Yang, and W.Marquardt, “Tool-Integration in Chemical Process Modelling”, Workshop at ESEC/FSE 2003, 9th European software Engineering Conference and 11th ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 79-83, 2003, Helsinki.

[99] Schopfer, G., A. Yang, L. Von Wedel, W. Marquardt, CHEOPS: A tool-integration platform for chemical process modeling and simulation, International Journal on Software Tools for Technology Transfer (STTT), pp.186-202, November 10, 2004.

[100] Schürr, A., H. Dörr, Introduction to the special Software and Systems Modeling section on model-based tool integration, Software and Systems Modeling, Volume 4, Issue 2, Spring May, 2005.

[101] Siegers, R. “The ABCs of AFs: Understanding Architecture Frameworks”, Proc. INCOSE International Symposium 2005. Rochester, NY. July 10-15. 2005.

[102] Shi, J., M. Törngren, J. El-khoury, O. Redell, “Model and tool integration in embedded systems development – a survey of state of the art”, Technical report, TRITA-MMK 2007:11, ISSN 1400-1179, ISRN/KTH/MMK/R-07/11-SE.

[103] Schatz, B., Peter Braun, Franz Huber, and Alexander Wisspeintner, “Consistency in Model-Based Development”, 10th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS'03), pp.287, 2003.

[104] SDL: Specification and description language, ITU-T Recommendation Z.100. Available: http://www.sdl-forum.org

[105] Society of Automotive Engineers Inc, Aerospace Recommended Practice (ARP), 4761: Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment, 1996.

[106] Soni, D., R.L. Nord, and C. Hofmeister. Software Architecture in Industrial Applications. Proc. of the 17th International Conference on Software Engineering. 1995. Seattle, WA.

[107] Sum, S. and C. Ibold, “Information Technology Support for Concurrent and Simultaneous Engineering - Tool Integration in a Meta Framework”, TENCON '94. IEEE Region 10's Ninth Annual International Conference. Theme: 'Frontiers of Computer Technology'. Proceedings of 1994, 22-26 Aug. 1994 Page(s):1068 - 1073 vol.2, Digital Object Identifier 10.1109/TENCON.1994.369155.

[108] SystemWeaver: http://www.systemite.com – accessed Feb. 2006.

[109] Systems Modeling Language v1.0, http://www.sysml.org.

[110] SystemWeaver: http://www.systemite.com – accessed Feb. 2006.

[111] Standard for the Exchange of Product model data, http://www.steptools.com/library/standard/, accessed in 2007.

[112] Telelogic DOORS, http://www.telelogic.com/products/doors/doorsanalyst/index.cfm.

-63-

[113] Tratt, L. “Model transformation and tool integration”, 10 November, Springer-Verlag 2004.

[114] Törngren, M. 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: 1905209320. August 2005.

[115] Törngren, M., D. Henriksson, O. Redell, C. Kirsch, J. El-Khoury, D. Simon, Y. Sorel, H. Zdenek and K-E. Årzén Co-design of Control Systems and their real-time implementation - A Tool Survey. Technical report, TRITA-MMK 2006:11, ISSN 1400-1179. ISRN/KTH/MMK/R-06/11-SE, Dept. of Machine Design, KTH, August 2006.

[116] Törngren, M., Axelsson, J., DeJiu, C, Malvius, D., “Model-Based Development of Automotive Embedded Systems”. Invited chapter in the forthcoming “Automotive Embedded Systems Handbook”. Editors Nicolas Navet and Francoise Simonot-Lion. Taylor and Francis CRC Press - Series: Industrial Information Technology. ISBN: 9780849380266. Publication Date: 1/30/2008.

[117] UML2 specifications, available from www.omg.org, accessed in 2007.

[118] Unified Modeling Language 2.0, http://www.omg.org, accessed in 2007.

[119] VHDL-AMS: IEEE 1076.1. Available at http://www.vhdl.org/analog.

[120] Wasserman, A.I. “Tool integration in software engineering environments”, Proceedings of the international workshop on environments on Software Engineering Environments, Chinon, France, pp. 137 – 149, 1990, ISBN:3-540-53452-0.

[121] Wikander, J., M. Törngren & M. Hanson (2001). Mechatronics Engineering - Science and Education, Invited Paper. IEEE Robotics and Automation Magazine, Vol 8, No. 2, 2001.

[122] Wieringa, R. “A survey of structured and object-oriented software specification methods and techniques”, ACM Computing surveys (CSUR), Vol 30(4), Dec, 1998.

[123] XSLT, XSL Transformations, http://www.w3.org/TR/xslt, accessed in 2007.

[124] XML, EXtensible Markup Language, http://www.w3schools.com/xml/, accessed in 2007.