Model and Tool Integration in High Level Design of Embedded Systems

Transcription

1 Model and Tool Integration in High Level Design of Embedded Systems JIANLIN SHI Licentiate thesis Department of Machine Design Royal Institute of Technology SE Stockholm TRITA MMK 2007:10 ISSN ISRN/KTH/MMK/R-07/10-SE

2 TRITA MMK 2007:10 ISSN 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

3 Mechatronics Lab Department of Machine Design Royal Institute of Technology S Stockholm SWEDEN Author(s) Jianlin Shi Title Model and Tool Integration in High Level Design of Embedded Systems TRITA - MMK 2007:10 ISSN ISRN/KTH/MMK/R-07/10-SE Document type Licentiate Thesis Date Supervisor(s) Martin Törngren, Dejiu Chen 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

4

5 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 -I-

6 -II-

7 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 "Objectoriented Modeling of Embedded Real-time Systems", Paderborn, Germany, Oct 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 , 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. -III-

8 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 , 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 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 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 , ISRN/KTH/MMK/R-07/11-SE, IV-

9 Table of Content Acknowledgement...I List of Appended Publications...III Other Publications...IV Table of Content...1 Abbreviations Introduction Background Outline of the thesis Basic concepts definition Problem Formulation System integration: interpretations, purposes and solutions Delimitations Requirements and challenges Research goals, questions and approaches Aim and purpose Research questions Research approaches Contributions Validity The state-of-the-art approaches Related early work on tool integration Multi-paradigm modeling Model transformations Standard exchange formats Systems modeling languages Model integration platforms PDM/SCM integration Framework and discussions Discussions on selected approaches

10 5.2 Integration scenarios Comparison framework Case studies Background Integrating Simulink and UML Integrating HiP-HOPS and system architecture design Experience and lessons learned Conclusion and future work...55 References

11 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 -3-

12 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 -4-

13 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 -5-

14 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 lifecycle 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 -6-

15 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 -7-

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

17 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. Organization Integration EE team supplier hardware software Product Integration IT team analysis test implementation Process Integration Figure 1 Integration in terms of Organization, Product and Process 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]: -9-

18 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 -10-

19 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 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. -11-

20 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]. -12-

21 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 -13-

22 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. -14-

23 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: -15-

24 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: -16-

25 State-of-the-art solutions: Section 4 and section 5.1. Scenarios: section 5.2. Framework: section 5.3. Prototype tools: 3.5 Validity o Integrating Simulink with UML2: section 6.2 and Paper A. o Integrating safety analysis with architecture design section 6.3 and Report B. 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. -17-

26 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 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]. -18-

27 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. Data Integration database files file window manager GUI Triggers Message server Control Integration Presentation Integration Figure 2 Tool integration dimensions in [18] and [120] 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 -19-

28 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 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 multiparadigm 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 Multi-paradigm modeling tools Matlab/Simulink: Simulink is a graphical modeling/programming platform for simulation and modelbased 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. -20-

29 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 -21-

30 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 metamodel 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 -22-

31 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 metamodel 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 However, it is developed mainly for mechanical engineering, for example for exchange data between CAD tools. -23-

32 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]. -24-

33 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 -25-

34 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 -26-

35 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 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: timediscrete, 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 toolsuits including model editor, interpreters, and analysis tools), and application level (software applications). Some works were presented in [54], which introduces a modeltransformation 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 -27-

36 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 metadata 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 -28-

37 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]. -29-

38 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 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, -30-

39 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 Discussion on central aspects of model and tool integration 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 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 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 & -31-

40 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 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, -32-

41 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 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 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 wellpredefined. 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 -33-

42 approaches, e.g., the OPHELIA, Cheops, ToolNet, and A-Posteriori approach, fall into this category 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 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 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. Meta-model data stored in a data base. OSCAR artefacts themselves are Genesis 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. -34-

43 Table 2 Comparison of integration mechanism Eclipse Fujaba Toolnet MIC 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. Plug-in mechanism A standardized API (ToolAdapter) allows the integration of any tool. Tool adaptor is adopted for syntax translation GeneralStore Code generation plug-ins are available for each integrated tool ModelCenter Ophelia Genesis Cheops APosteriori Wrappers are used to parse information and expose that information to a common API. Wrappers allow the integration of any tool subject to the data availability/openness in the integrated tool. Artefacts needs to be accessible by the OSCAR artefact management system, e.g. through the file system. Corba clients implement wrappers and analysis modules. Wrappers have to be implemented providing access to models and translation of models. 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 Socketbased 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 -35-

44 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 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. Abstraction Level c1 Design UML a1 Implementation Simulink c2 a1 r1.1 c3 r1.2 Structure System Content Behavior Figure 3 Scenarios of integration UML and Simulink -36-

45 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 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 nonfunctional 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 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 -37-

46 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 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 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: -38-

47 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. -39-

48 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. -40-

49 Table 4 Interpretation of comparison framework for tool integration platform Factors Definitions Examples Motivations Relating to problems to be solved. SW-HW Co-design Relating to the type of product or its aspects Embedded SW, Product under consideration. generic SW; Relating to the people and organization that Architects, Stakeholders and either apply an approach or are affected by the managers; organization results of it. OEM, SME. User Interface Means by which users interact with the system GUI End-user Services Integration Coverage Analysis Transformation and Synthesis Product View Composition Integration Aspect Composition Workflow Management Configuration Management Quality of Services Relating to the targets of integration in terms of disparate models, tools, and files, and their relationships, e.g. refinement and/or communication 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. Relating to synthesis and transformation support Components that involved in the integration Different views of the system Coordinated services provide by integrated tools Relating to the tracking, record, control and other management tasks of system artifacts throughout the lifecycle. The configurability, adaptability, portability, extensibility, performance, security, scalability State Machines, Simulink; documents; Co-Simulation for analysis of control performance; Formal analysis Code generation Discrete time model, Control function view, software view Version control, access control, variant configuration Implementation Process Support Integration Mechanisms and Architecture Relating to the ways of performing integrations, in terms of the adopted functions, communications, and process. Realization Relating to the adopted technologies, environment, and infrastructure for the integration. Definition of Integrated Product Structure Consistency Support Traceability Support Views/ Workspaces Support Versioning and Storing Event Management Others 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- 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. 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. 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. 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. Relating to pre-defined support AND/OR possibility for generating events that support the coordination of work among several developers For example: Support for concurrent and distributed engineering Relating to the platform/software development process and supported process. API, Plug-ins, Imperative languages, wrapper PDM system, XMI, GME, EMF. A complete system model, for one or more product variants Type-checking, relationship rules Central repository Navigation based on defined relations between design entities, Impact of Changes. Pre-defined views as well as stakeholder definable views. Synchronized plugins. Event notification. E.g. web access Code generation and allocation. -41-

50 Table 5 An example of platform approaches comparison Factors Fujaba GeneralStore End-user Services 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 Software designer, system organization integrator Software designer User Interface GUI is provided e.g., FSA A system browser is available Data and notations in tools Integration Coverage like UML and SDL. software system, time-discrete, timecontinuous, and discrete-event models Graphical features like menus and toolbars Analysis Depending on the integrated tools e.g., SDL Rapid prototyping for early verification Transformation and Rapid prototyping for final synthesis. Code generation Synthesis Code generation and integration. Product Data Composition Support Support Integration View Central system view in UML and Support Composition domain views Control Integration New plug-in can be added Supported by code integration Configuration Management NA User authentication, transaction management, and configuration management 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 metamodeling in UML, new tools can be added. Implementation Process Support Integration Mechanisms and Architecture Realization Definition of Integrated Product Structure Consistency Support Traceability Support Views/ Workspaces Support Versioning and Storing Event Management Plug-in mechanism in a modular platform with XML configuration files Java code System structure can be defined by instantiating the integrated/extended meta-model, which also defines relation rules based on MOF Meta-model restrictions and dedicated consistency services NA Via plug-in mechanism Data is stored in local tools Synchronization of tool features. An object repository stores all tools (meta) data and manages their mappings; A CASE-tool integration environment with 3-tiered architecture XMI based interchange of (meta) data. MOF is used as database schema. ORACLE/MySQL for database management. Adapters are developed for CASE tools The whole system concept is defined as an instance of one particular metamodel in one UML notation with subsystem development in domain specific tools A central systems model in UML with support for model-level white-box mapping across domains and support for cross-reference 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. Central system view in UML and domain views A database such as Oracle and MySQL is adopted. An interim project file is created once a check-out happens. Further versioning is supported Support concurrent engineering in a top-down paradigm. It controls the access to models. Others NA NA Focusing on software and Entire development process. implementation design. -42-

51 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 -43-

52 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. Simulink HiP-HOPS.hip.mdl System Behaviour: Activity diagram EAST-ADL2 User model Eclipse UML2 Papyrus System Structure: Composite Structure diagram EMF Figure 5 Tool-chain in the case studies 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]. -44-

53 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. Abstraction Level Design Implementation Structure UML Simulink Tool boxes System Content Behavior System Boundary Internal External UML SysML Structure Simulink System Content Behavior (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. -45-

54 - 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 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. -46-

55 acc_enable_button [0/1] acc_enable [0/1] acc_enable [0/1] accelerator_pedal_request [Nm] acc_mode [0/1] desired_target_distancepedal acc torque request [Nm] HMI measured_wheel_speed (4) [km/h] wheel_speed (4) [km/h] mean_vehicle_speed [km/h] rain_intensity [mm/h] rain_intensity [%] Perception measured_wheel_speed (4) [km/h] vehicle_speed [km/h] moderated_torque_request [Nm] rain_intensity [%] Vehicle application acc_enable_button [0/1] desired_target_distance [s] engine_torque [Nm] wheel_speed (4) [km/h] rain_intensity [mm/h] Vehicle Environment (a) Simulink view of a model 1 acc_enable_button [0/1] 3 vehicle_speed [km/h] 4 acc_mode [0..3] 2 desired_target_distance [s]1 Input Output button_sensor vehicle_speed [km/h] acc_mode [0..3] desired_target_distance [s] Gauges 1 acc_enable [0/1] (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 -47-

56 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, discretetime, 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 eventtriggered 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 -48-

57 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 support 1 MoCCs Simulink UML Client-server No direct support Sequence FSM Stateflow State machine 2 Event-triggered and dataflow Conditionally executed subsystem and Activity data-flow blocks Discrete-time Sampled blocks Activity 3 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 x = + 2 x u () t (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. (a) (b) Figure 9 Simulink model and UML2 activity diagram for numerical solution of Eq. 1 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. -49-

58 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 -50-

59 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 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- -51-

60 HOP supports Matlab/Simulink model analysis by using a toolbox which produces failure-modes annotation and needed failure data 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 ADLFuntionPrototype FunctionalDevice ErrorBehavior ErrorModel ErrorPropagation PropagationPort It represents basic entities These two are specializations of ADLFuncitonType It defines the Specification of error logic. Properties such as failure logic, propagationport, handling status, and failure effects are defined in ErrorBehavior. It defines the ErrorBehaviors that a entity can have given a specific context It defines the relationships between errors of components which can cross abstraction levels. It defines the port that an faulty event can go through Abstraction Function Functions failures, effects, severity Component failures Implementation of a component that synthesis and analysis to take place Propagations of failure and fault 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. -52-

61 (a) Example of top-events (b) Example of FMEA direct effect Figure 10 Output of HiP-HOPS safety analysis 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-ADL 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. -53-