Model Integration in the development of Embedded Control Systems a characterization of current research efforts

Transcription

1 5 Model Integration in the development of Embedded Control Systems a characterization of current research efforts DeJiu Chen, Martin Törngren, Jianlin Shi, Sebastien Gerard, Henrik Lönn, David Servat, Mikael Strömberg, Karl-Erik Årzen Abstract The design of advanced embedded control systems requires a systematic approach in handling their increasing complexity and in particular integration of the different aspects and parts of a product worked on by different experts. Several variants of model-based approaches are today advocated to facilitate systems integration. This paper describes a number of representative efforts that address multiple concerns or views including modeling languages such as AADL and EAST-ADL as well as model integration environments such as GeneralStore, ToolNet, and Fujaba. We present a characterization of the approaches and thereby highlight their commonalities and differences regarding basic integration mechanisms and engineering support. We conclude with a prospect for future work. T I. INTRODUCTION, FOCUS AND AIM HE design of advanced embedded control systems requires a systematic approach in handling their increasing complexity due to the increasing functionality that is implemented in embedded systems and also because of the stringent (and sometimes conflicting) requirements placed upon such systems. For example, consider the design of an embedded automotive ABS braking system. One obvious concern is that of the core motion control functionality, especially the control logic and algorithms and the dynamic behaviour of the system. However, this is only one out of several aspects. Other aspects include safety, security, network communication, mechanical design, IO, power, etc. These aspects and components are in addition typically handled by different specialists, employing different modeling languages and tools, and moreover belonging to different organizational entities. Approaches to support systems architecting and integration therefore become very important. Integration in general refers to the process of combining parts into a whole, and as such it is relevant to talk about integration in many dimensions including the product Manuscript received February 29, This work was supported in part by the European Commission through the ARTIST2 NoE and the ATESST projects, and in part by the Swedish Governmental Agency for Innovation Systems Vinnova through the ModKomp project. DeJiu Chen, Martin Törngren, and Jianlin Shi are with the Dept. of Machine Design at the Royal Institute of Technology, SE Stockholm, Sweden ( chen@ md.kth.se). K.E. Årzen is with the Dept. of Automatic Control at Lund University, Lund, Sweden. S. Gerard and D. Servat are with the CEA-LIST, Paris, France. H. Lönn is with Volvo Technology Corporation, Gothenburg, Sweden. M. Strömberg is with Systemite AB, Gothenburg, Sweden. (composing components, behaviors, and quality related aspects and views into a consistent whole), the process (aligning e.g., mechanical and control engineering processes) and within the organization (supporting the communication among related engineering teams) [1]. In this paper we focus mainly on the product dimension of integration and target approaches that address design information integration throughout product development. We additionally focus on efforts that take a model-based approach, in which models forms the basis for comprehending the design and the relationships within or across engineering domains and phases, for evaluating functionality and qualities of concern, and for supporting information management as well as product realization. Given this delimitation, we still find many and heterogeneous integration approaches. We have attempted to select a number of representative research efforts, including those that represent domain specific approaches (e.g., AADL [3] ) as well as more general embedded systems approaches (e.g., Fujaba [5]). We have also included approaches with an origin in information management (i.e., SystemWeaver [6]) in which database techniques play a key role for structuring, storing, and provisioning of information. Some of the approaches explicitly address the integration of domain specific CASE tools (e.g., GeneralStore [7-8]) and provide explicit support for the model transformations (e.g., IDM [11]). The included approaches are far from exhaustive, but they do represent complementary efforts. We have deliberately excluded narrower efforts that address mainly one integration concern, for example those addressing cosimulation. This is for example the case with the Ptolemy approach developed at Berkeley [12]. Although very interesting, it focuses on one aspect of integration, namely that of modeling and integrating heterogeneous MoCs (Models-of-Computations). We have also excluded approaches that are very recent with little information publicly available. The main aim of the paper is to characterize and relate these approaches to each-other. We identify basic (and common) mechanisms for integration as well as differences among the approaches. In the following, in Chapter 2 we briefly describe current state of practice in integration and emerging model integration efforts. In Chapter 3 we propose a framework for characterizing and comparing the approaches. Using this framework, we compare and discuss

2 the approaches in Section 4, and conclude in Section 5. II. STATE OF PRACTICE AND RESEARCH EFFORTS There are several traditional ways by which developers try to manage the integration of embedded control systems, essentially applying separation of concerns at different levels and for different aspects, including; Hardware level integration. The interfaces are here standardized at the hardware level, where one typical example can be taken from automotive systems where integration typically takes place at the network level, integrating black box electronic control units (ECUs). Software level integration. Here the unit of composition is black or white box software components which are commonly code-generated from different modeling tools. The actual integration takes place at the software level where the software platforms then have to be standardized [13]. Model level integration. The key concept is here that models, of system parts or aspects, are developed and integrated throughout the development, hence enabling incremental development. While the hardware level integration considers system modularity in terms of ECUs, it is not resource efficient because new functions often imply additional hardware resources. Moreover, since the units of integration are black box products normally unavailable at early lifecycle stages, it is problematic to perform early verification and validation (V&V) of an integrated system. This is problematic for distributed control functionality, e.g., to evaluate distributed control functionality with respect to the implementation with specific time-varying delays and fault propagation. A problem for the software level integration is that the traditional specification of software interfaces is not enough for many embedded systems including control applications. The behavior of a complete system will also depend on the hardware, the environment, and the integration of algorithms within components, leading to emergent behaviors that thus can not be subject to early V&V. Many research efforts are today investigating how to model software components to facilitate their integration, thus promoting component-based software development [13]. In computer science, advanced modularization mechanisms that help to overcome a range of problems associated with inadequate separation of concerns have been developed including aspect-oriented programming [14] and subject-oriented programming [15]. A major limitation of such approaches is that they only concern the software aspects of the embedded system. In relation to these integration paradigms, state of the art control design tool chains have to be mentioned [16]. Such tool chains provide powerful environments with support including simulation, code generation, rapid control prototyping against real processes, formal analysis using control theory, and software/hardware in the loop simulation. In recent years, toolboxes that support the codesign of the control systems and their real-time implementation have also been developed in academic research. These tools support e.g., the ability to create a model of a distributed computer systems jointly with the closed loop system model, in order to evaluate the effects of for example time varying delays on the control performance [17]. These tools have however not yet been fully integrated with industrial tool-chains. Furthermore, although such toolchains are of great value, they focus on control qualities like performance and robustness, and fail to address many other issues such as cost, reliability, and integration of software and hardware. There exists a range of model based integration approaches; we here briefly introduce the ones selected for the survey in the following sections: AADL, EAST-ADL, Fujaba, GeneralStore, IDM, SystemWeaver and ToolNet. The AADL [3] has a background in the avionics 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 [4] is a UML2.0 [18] and SysML [19] based Architecture Description Language for automotive embedded software and systems. It was defined by the EAST-EEA consortium and is currently further developed in the ATESST project [20]. 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. Domainspecific 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. An 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 of the language is on software design, but hardware modeling is included because of the tight interdependencies. Aspects covered include system structure, behavior, requirements, variability, V&V and to some extent environment modeling Fujaba [5] 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

3 graph grammar rules. Like Eclipse [21], services are extended and integrated via a plug-in mechanism in Fujaba. Fujaba supports code generation. GeneralStore [7, 8] is a platform enabling an integrated development process running from models to executable code, in which heterogonous CASE tools (e.g., Matlab/Simunk, and ARTiSAN RT Studio) and their associated code generation facilities are integrated. In particular, while using UML models for overall system design, this approach supports the transformations of subsystem models in time-discrete and time-continuous domain. This is achieved by providing meta-level definitions of CASE data in UML, and then integrating the metamodels in a MOF (Meta Object Facility) object repository. The data interchange between CASE tools is supported by XML (extensible Markup Language). GeneralStore provides support for configuration management. ToolNet [9, 10] is an integration platform, managing the integration of domain tools targeting specific design phases or aspects of embedded software systems, such as DOORS, Matlab/Simulink, and Borland Together ControlCenter. This approach leaves the domain data at their respective tools. Data integration is achieved by specifying a VirtualObjectSpace in terms of relationships and consistency constraints of domain tool data, which is then stored and managed in a relation repository. Standardized APIs are used to support tool access and XML based export of tool data. ToolNet provides graphical user interface for navigation. SystemWeaver [6] aims to provide configuration management for complex systems. The need is motivated by the insufficiency of traditional document-based specification 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 IDM (Integrated Data Model) effort [11] is essentially a model-transformation based approach to the integration of different engineering tools (e.g., fault modeling tools, diagnostics engines, FMECA 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 IDM, the translations of semantics and syntax are separated. That is, while each tool has 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. III. A COMPARISON FRAMEWORK To form a basis for profiling and relating different integration approaches of interest, a framework, based on our earlier work, has been developed and tailored to specifically address integration [13]. It highlights a set of factors, based on the following fundamental questions. In Table 1, these factors and their definitions are listed together with examples. Q.1. Why is the particular approach needed? Table 1. An overview of factors for comparison. Factors Definitions Examples Motivations (Q.1.) Relating to problems to be solved. SW-HW Co-design Process Relating to the intended design activities and stages. Code Generation and Allocation. Engineering Contexts Product Relating to the type of product or its aspects under consideration. Embedded SW, Generic SW; (Q.2.) Relating to the people and organization that either apply an approach Architects, Managers; Stakeholders and organization or are affected by the results of it. OEM, SME. Integration Coverage (Q.3.) Relating to the targets of integration in terms of disparate models, tools, State Machines, Simulink; and files, and their relationships, e.g. refinement and/or communication Documents; Tool Interfaces. Dependency Definition and Relating to the definitions and descriptions of dependency as well as Information-Models, CDIF, OCL, Formalisms the rules for transformation or mapping, XML. Integration Integration Mechanisms and Relating to the ways of performing integrations, in terms of the adopted API, Plug-ins, Imperative Techniques Architecture functions, communications, and process. Languages, Repository (Q.4.) Realization Relating to the adopted technologies, environment, and infrastructure PDM database, XMI, GME, for the integration. EMF. Engineering Relating to explicit support for creating the global product structure A complete system model, for Definition of Integrated Product based on information acquired by disparate sources, including versions, one or more product variants Structure and variants, and product-family specification. Techniques (Q.5.) Product Analysis and Synthesis Relating to explicit support for assessments of product functionality, feasibility, or other qualities, and for product integration and implementations in terms of either simulations or code generation. Co-Simulation for Analysis of Control Performance; Formal analysis, Code generation Relating to explicit support for handling the coherence and accordance Type-Checking, relationship Consistency of structurally or semantically related information of disparate sources, rules due to duplication, composition, refinement, or implementation, etc. Relating to explicit support for tracing the propagations of design Navigation based on defined Traceability decisions or faults across disparate models/tools throughout the relations between design Information product lifecycle such as to resolve conflicts or effects of changes. entities, Impact of Changes. Management Relating to pre-defined support AND/OR possibility for retrieving a Pre-defined views as well as Views/ Workspaces subset of systems information from disparate sources, and then forming stake-holder definable views. a user-defined design space for a particular design task. Relating to the composition and storage of global product development Configuration management, Structuring and information from disparate sources as well as the support of access Product structure management management control, file and version management, and distribution. Relating to pre-defined support AND/OR possibility for generating Synchronized plug-ins. Event Workflow Management events that support the coordination of work among several developers notification. Others For example: for concurrent and distributed engineering E.g. web access

4 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 motivations 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, as interpreted by the authors. 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 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., [2]. 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 ), for resolving information dependencies (i.e., Traceability s), for providing separation-of-concerns and abstraction (i.e., Views/Workspaces ), 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). Obviously, many of these services are strongly related to each-other and will interact in some way, for example the case with consistency support and work-flow management services. IV. DISCUSSION AND COMPARISON Originating from different research communities and industrial domains, many of the studied approaches are heterogeneous in nature. Appendix 1 provides an overview and summary of the comparison. One common driver behind all these approaches has been the need for integration of information from disparate formalisms and tools, which are used to cover different aspects and sub-domains of a complex system, in order to achieve an effective product development. While the integration-of-concerns forms a common theme, the approaches under consideration are motivated by different aspects of the integration. The studied approaches may be divided into two main categories: (1) system description languages in terms of two architecture description languages (AADL and EAST- ADL), and (2) multi-tool/model environments (all others). The language approaches mainly target the technical complexity of engineering and provide explicit support for the identification and standardization of related product information traditionally maintained in loosely coupled domain models or CASE tools. Approaches like AADL and EAST-ADL have evolved with very specific target systems under consideration, such as embedded control systems in AADL and automotive embedded control software in EAST-ADL. To cope with the technical complexity, each of these languages provides a well-defined system concept, covering issues like system decomposition, levels of abstraction, as well as the cross-cutting properties. The integration environment approaches often target the same problem but focus on the tool interoperation and information management aspects in an engineering environment. For example, approaches like Fujaba, GeneralStore, SystemWeaver, and IDM provide built-in support for the integration of tool interfaces (e.g. menus) and operations. These approaches instead provide general means for defining essentially any modeling language or information model (i.e. they provide basic support on the meta-meta level). Among the integration environments, we identify two main architectural styles, and also hybrids combing aspects of both. These two main styles are (a) repository based integration, as exemplified by SystemWeaver and (b) Peer-to-peer integration, as exemplified by the IDM approach. A central issue in integration-of-concerns is the definition of the interdependencies and transformations of information. The AADL employs a more traditional source code based composition of domain models into the software architecture. One common approach to model-level information integration and transformation is to employ system meta-models, such as in Fujaba, Generalstore, and SystemWeaver. It is worth noticing that the meta-models in these environment approaches often only cover the predefined syntactical or structural aspect of information, while leaving the semantics or behavior definitions in the associated original tools. For example, in GeneralStore, only the structural aspect of MATLAB/Simulink models is transformed into software objects and class models and maintained in UML tools. Central techniques, part of all integration environments, include information models, transformations, tool integration and exchange formats. These techniques do correspond to the techniques that one finds adopted in the mechanical engineering umbrella standard STEP supporting model exchange and tool integration [24]. In most of the studied approaches, the XML has been used as a common format for information exchange. Most of them also use the OMG XMI technology (XML Metadata Interchange) for exchanging information, where the MOF forms the basis for meta-model integration and storage. Approaches like Fujaba and ToolNet, on the other hand,

5 employ their own solutions to manage the interchanges and also support API based integration of tool functionality through COM/DCOM. Compared to XML, the ADL languages themselves also constitute a more application and product specific common information exchange format. Such languages could potentially be used to link multiple models and tools and to support process automation. The AADL and EAST-ADL explicitly define the concerns of a system and provide structuring support for organizing such concerns such as in terms of decomposition hierarchy, design levels and aspects. Such approaches also provide additional artifacts for design information such as relating to traceability and quality constraints. Compared to these, the environment approaches provide rather weak or only very generic support in respect to the detailed and precise identification and structuring of systems concerns. Analysis provides a means for verifying the correctness of solutions with respect to the required product qualities before the final product has appeared, as well as for identifying the dependencies of solutions. Depending on the types of analysis and the adopted techniques, either partial or overall systems information is required and will be affected by the results. The language approaches provide analysis support through dedicated modeling constructs, particularly relating to the overall systems. For example, the AADL provides analysis support for software timeliness on a target platform. The environment approaches on the other hand mainly rely on the subsidiary models and tools for their analysis leverages. In the Fujaba, the analysis of functional behaviors is possible but depends on the integrated external tools such as SDL and Matlab/Simulink. Synthesis in terms of code generation is addressed by most of the studied approaches to meet the need of rapid-prototyping and to avoid semantic gaps between models and the final implementations. Most of the approaches perform the system building with the code generation support by dedicated domain tools (e.g., in AADL and GeneralStore) Consistency support is concerned with the maintenance of agreements and disagreements of overlapping design information. There are many reasons behind the overlapping, such as relating to separation-of-concerns (e.g., refinements and multi-views) and systems structuring (e.g., decomposition). In principle, four major tasks are involved in the consistency support: avoiding inconsistencies, detecting inconsistencies, resolving the conflicts, and handling inconsistencies. The avoidance support is concerned with measures adopted to keep overlapped information from being in conflict. In the AADL and the EAST-ADL, this is mainly supported by the common description of an entire system and by the languages such as in terms of predefined type systems and rules constraining the usage and connections of information. The detection is normally supported by parsing facilities and dedicated consistency services, such as to check the consistency of required connections of component ports. In the environment approaches, inconsistency avoidance and detection are normally supported through meta-model based restrictions, and further enhanced by tool integration features. Examples of this are the use of cross-references in GeneralStore and the use of meta-model and XML based report generation in ToolNet and SystemWeaver. To resolve conflicts, both technical support in terms of modeling, simulation, and quality analysis, and managerial support such as good traceability become necessary. The handling of inconsistency is concerned with the repair of mismatches and needs to take the process aspect of engineering into consideration. One reason for the process consideration is due to the fact that temporal inconsistency is often desired to cope with the needs of concurrent engineering. Some of the environment approaches, such as GeneralStore and SystemWeaver, have support for concurrent engineering by allowing the same information to be used by several developers for later merging (a typical functionality in software configuration management tools). Traceability relates to the management of dependencies across concerns and throughout the product lifecycle. It is essential for consistency management, change control, diagnostics, etc. Targeting common descriptions of overall systems, the language approaches provides a good basis for traceability management and for organizing additional concerns that span multiple quality aspects and refinement levels. For example, in AADL, a software component can be traced with respect to hardware mapping decisions due to its binding-specific attributes; partial and final specifications of execution flows can be traced by means of refinement connections. EAST-ADL offers good traceability supported by dedicated language constructs. In contrary, the environment approaches provide facilitates for relating information in general, but do not predefine the types of dependencies that are specific in a product. The development of embedded control systems involves decision-making that span over multiple abstractions levels and domains (e.g., control, software and hardware). This necessitates a multi-viewed system description approach. Both the AADL and EAST-ADL provide a separation between application and hardware views. The AADL also provides supports for extracting views relating to properties such as timeliness and reliability. The concept of multiple views can also be identified in some environment approaches in relation to the tools being connected. For instance, the GeneralStore provides an overall system description in UML, while relying on a fixed set of domain tools for function description. One interesting issue of the view/workspace support is concerned with component design. Design decisions normally require dedicated component views specifying the system-wide dependencies of an individual component and the integrity related constraints and freedom (e.g., a system parameter/variable can be of concern for several components). The basic information and mechanisms are provided by all approaches,

6 but explicit support seems to be lacking. V. CONCLUSION AND FUTURE WORK We have surveyed a number of model integration approaches claiming the same goal of integration but being quite diverse in nature. We have shown, in particular, that the modeling language and the environment approaches strongly complement each-other. For example, a modeling language such as the EAST-ADL could be used as an input (a pattern) for defining the information model of a repository. The modeling language approaches focus on technical aspects while the environment approaches mainly address information management and provide the enabling technologies for model/tool integration. A combined approach is required and has to consider the needs for the variety of domain specific tools. The variety of solutions proposed mirror the fact that the area has not yet converged. Experiences from mechanical engineering should be drawn model based integration is already fairly mature and used in practice [22]. To fulfill the requirements of multidisciplinary integration for embedded control systems, several questions must be clarified: which kind of integration is desired given different development contexts? What are the requirement/criteria for a model-based tool integration environment? What s the limitation of current efforts and existing tools/techniques? From an industrial perspective there are many challenges related to the adoption of model-based integration; needs of different users, the scope (e.g. for development only or across production and maintenance), and the way in which new tools are introduced have to be considered [23]. From a technical research point of view, there is a need for continued exploitation of advances in architecture description languages and technologies in order to provide better support for (1) model-transformations across heterogeneous modeling paradigms, analytical views (e.g., safety analysis methods in terms of FTA and FMEA), behavior models employing different models of computation, and domain specific CASE tools (e.g., ranging from requirements engineering tools, to code generation and diagnostics; (2) information management across lifecycle stages and engineering domains supporting concurrent and distributed engineering; and (3) dedicated workspaces/views for component-based development, variability handling, and process flexibility. REFERENCES [1] A. P. Sage and C. L. Lynch, Systems Integration and Architecting: An Overview of Principles, Practices, and Perspectives, Systems Engineering, Volume 1, Issue 3, 1998, Pages [2] D.W. Oliver, T.P. Kelliher, and J.G. Keegan Jr., Engineering Complex Systems with Models and Objects, McGraw-Hill, [3] Society of Automotive Engineers, SAE Architecture Description Language, SAE standard AS5506. Available: [4] EAST-EEA, ITEA-Project-No.00009, Embedded Architecture and Software Technology. Available: [5] S. Burmester, H. Giese, (et al.), Tool integration at the meta-model level: the Fujaba approach. Int. Journal on Software Tools for Technology Transfer, Springer Berlin Heidelberg, , vol. 6, no. 3, pp [6] Systemite AB, SystemWeaver. Available: [7] C. Reichmann, M. Kuhl, P. Graf, and K. D. Muller-Glaser. "GeneralStore - A CASE-Tool Integration Platform Enabling Model Level Coupling of Heterogeneous Designs for Embedded Electronic Systems," pp , 11th IEEE Int. Conf. and Workshop on the Engineering of Computer-Based Systems (ECBS'04), May, [8] K. D. Muller-Glaser, C. Reichmann, P. Graf, M. Kuhl, and K. Ritter, Heterogeneous Modelling for Automotive Electronic Control Units Using a CASE-tool Integration Platform, IEEE Int. Symposium on Computer Aided Control Systems Design, pp , [9] R. Freude and A. Königs, Tool integration with consistency relations and their visualization, Workshop at ESEC/FSE 2003, 9th European software Engineering Conference and 11th ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 6-10, 2003, Helsinki. [10] F. Altheide, H. Dörr, and A. Schürr, "Requirements to a Framework for sustainable Integration of System Development Tools", Proc. of the 3rd European Systems Engineering Conference (EuSEC'02), Toulouse: AFIS PC Chairs, 2002, pp [11] G. Karsai, A. Lang, and S. Neema, Design patterns for open tool integration, Software and Systems Modeling, Volume 4, Issue 2, 10 November 2004, Spring-Verlag 2004, pp [12] E. A. Lee, Overview of the Ptolemy Project, Technical Memorandum No. UCB/ERL M03/25, University of California, Berkeley, CA, 94720, USA, July 2, [13] M Törngren, DJ Chen, and I. Crncovic, Component-based vs. Model-based Development: A Comparison in the Context of Vehicular Embedded Systems. Proc. of 31st EUROMICRO Conference on Software Engineering and Advanced Applications, pp , [14] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, JM Loingtier, and J. Irwin. Aspect-Oriented Programming. Proc of the European Conference on Object-Oriented Programming (ECOOP), Finland. Springer-Verlag LNCS June [15] W. Harrison and H. Ossher. Subject-oriented programming (a critique of pure objects). Proc of the Conference on Object- Oriented Programming: Systems, Languages, and Applications (OOPSLA), September [16] H. Hanselman. Development Speed-Up for Electronic Control Systems. Distributed on the occasion of Convergence 98, October 19 21, 1998, Dearborn, USA. [17] M. Törngren, D. Henriksson, K.E. Årzen, A. Cervin, and H. Zdenek. Tool supporting the co-design of control systems and their real-time implementation: current status and future directions. To appear in Proc. of IEEE Int. Symposium on Computer-Aided Control System Design 2006, Munich, Germany. Oct [18] Object Management Group, Unified Modeling Language 2.0. Available: [19] SysML Partners, Systems Modeling Language v1.0. Available: [20] ATESST Project, EC Project Contract number: , Advancing Traffic Efficiency and Safety through Software Technology. Available: [21] Eclipse Community, Eclipse Platform Technical Overview. Available: [22] J.El-khoury. A Model Management and Integration Platform for Mechatronics Product Development. Doctoral thesis, Royal Institute of Technology (KTH). TRITA-MMK 2006:03, ISSN , ISRN/KTH/MMK/R-06/03-SE. [23] D. Malvius and O. Redell, "Introducing Structured Information Handling in Automotive EE Development", Proc. of the 16th Annual Int.l INCOSE Symposium. Orlando, Florida, [24] Overview of STEP (ISO 10303) Product Data Representation and Exchange. Available: /SC4_Work_Products_Documents/STEP_(10303)/

7 Factors AADL EAST ADL Fujaba SystemWeaver GeneralStore ToolNet IDM Motivation To support architecture description and analysis. Process Model-driven system engineering Product Stakeholders and organization Integration Coverage Dependency Definition and Formalisms Integration mechanisms and architecture Realization Others Definition of Integrated Product Structure Product Analysis and Synthesis Consistency Traceability Views/ Workspaces Structuring and Management Workflow Management Automotive embedded real-time software systems System architect Behaviors in Simulink, SDL, ESTEREL, LUSTRE, and UML. Rules and permissions governing the mapping between AADL specification and source text depend on the applicable programming or modeling language standard. Importation of source code in Ada 95, C, or Java; XML/XMI for interchange between commercial and in-house tools; UML 2.0 profile integration with UML. Open Source AADL Tool Environment (OSATE) based on Eclipse; Extensible AADL front-end with XML generation. Extensions can take the form of new properties and analysis specific notations of components. Modeling of application software, execution platform, and mapping. standard control and data flow mechanisms Analysis relating to timing, fault and error behaviors. code generation. A common system description; Compilers and external plug-ins for consistency check. Language constructs for design information in terms of implementation binding and refinement. Separation between application and hardware views. To promote consistency and completeness for OEM-Supplier interchange and work sharing; To allow analysis and synthesis Software development through all process phases Automotive embedded real-time systems Software designer, system integrator, requirements engineer, control engineer. Behaviors in Simulink, Ascet or UML. Integration of models and results from analysis and synthesis. Run-to-completion semantics for the behavior of system elements A UML2/SysML based metamodel allows model exchange and manipulation based on XML/XMI Metamodel specification and XML DTD To integrate various tools and notation in a common environment and to manage inconsistencies. Focusing on software and implementation design. Software Software designer, system integrator Data and notations in tools like UML and SDL. Graphical features like menus and toolbars. Interdependencies rules in an integrated meta-model; XML-based GUI configuration files. Plug-in mechanism in a modular platform with XML configuration files Coded in JAVA. N/A Extensible with other tools. A global (or partial) system structure representing the software and electronics part of the vehicle with separated software and hardware concerns and abstraction layers. Synthesis support for scheduling, software-to-hardware allocation, communication, OS and Middleware configuration Consistency can be enforced based on meta-model restriction and by dedicated consistency services Requirements are associated, system elements are associated between abstraction levels System model is organized in abstraction level and aspect (application vs. platform) ; views for analysis and synthesis covering can be defined. Possible with XML transformation Metamodel specification, XML DTD N/A Assuming a model-refinement process. Organization-specific - EAST ADL provides means to describe the results of process steps, but does not prescribe a process Others N/A N/A N/A A global (or partial) system structure can be defined by the users by instantiating the integrated/extended meta-model Depending on the integrated tools e.g., SDL. Meta-model restrictions and dedicated consistency services N/A Appendix 1 Not specific, but different views can be implemented. Synchronization of tool features. To support model-based, architecture development in large projects Meta programmable - supporting many aspects like architecture development and project control Engineering of complex computerbased systems, Product and architecture development organizations at large Generic interface to client tools (views). Linking to external (model) files like Simulink. Integrated meta model, not overridable by user model in class or instance level. Enforced model integrity API and XML based interchange between model repository and tool clients. WebDAV interface to 3:rd party models stored in files. Borland Delphi, TCP/IP API and MS Windows COM API. Formal identification (URI) of model item s large, multi abstraction integrated architectures with variants and product line support. Specific meta modeling concepts to assure reusability of part models including components. Depends on specific meta model, but basic meta-meta model features support distinction between generic properties like component interfaces, and specific like connection of component interfaces. Integrated strong (always enforced) meta model. XML based report and consistency generation Built-in formal traceability between meta-model and user model. Interface to file repositories, file link integrated in model Separation of generic and context specific aspects. Abstraction layers and definitions of user roles XML interchange of chosen meta model and user model for issue/change managementautomatic global view refreshconcurrent "micro transaction" access Integrated fine grained configuration management (CM) To assist integrated development process from modelling to code with tool integration management Entire development process. Embedded control systems (one focus is automotive applications) To provide an Integrated Environment with keeping data consistent and consistency visualization Focus on data consistency management and visualization. Meta level tool support and data interchange on model transformation based tool integration. Focus on model transformation including separate semantics and syntax transformation. software Software systems systems and domain developers Software designer Software engineer Models of three domains: Objectoriented models for software system and components, time-discrete, timecontinuous, and discrete-event models for control functions. The whole system concept is defined as an instance of one particular metamodel in one notation, based on - UML metamodel - "Bidrectional transformation rule" 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 Various tools, currently it covers Stateflow, Doors, Simulink, DaimlerChrysler CTE and Borland Together ControlCenter Dependency between objects is instances of defined relations stored in repository. The creation of instance can be done manually or automatically by the framework The framework provides API, e.g., ToolAdaptor to access individual tool by requesting an XML-export of data. An information backbone connects tool via the adaptor. Specifications use UML, Data are represented and transformed by XML or XSLT. The components are realized in java. N/A Strong extensibility and flexibility N/A Utilizing the UML notations for an overall system design cycle, with subsystem development in domain specific tools (e.g., signal flow diagrams, state-charts, UML, etc.) Rapid prototyping for early verification and final synthesis. Code generation by disparate domain tools and integration via wrappers. A central systems model in UML with support for model-level whitebox 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 An interim project file is created once a check-out happens. Further versioning, and configuration management is supported concurrent engineering in a top-down paradigm. It controls the access to models. N/A N/A ToolAdaptor connects tool to the information backbone. Relation navigation, User can browse product structure and query data stored in any integrated tools. Graphical Visualization is provided. Virtual Object Space severs as a relation repository to store manually defined consistency relations between the data of tools. Reference objects are introduced for each object in tools. The relation between reference objects can help to find any related objects. Graphical visualization is provided. various domain views XML representation of relation repository and all individual tool data. It is possible to perform functionality call by request in a tool or the visualization component in the framework. Various tools used for different purpose, design, analysis, diagnostics, data storage, etc. A complete metamodel is used as union of all tools metamodel. Meta model of model transformation is expressed in UML. MOF is used as the meta-metamodel. Separation of Semantics and syntax translation. A backplane is used for communication with CMI protocol. Communication is implemented in CORBA, The Common Model Interface protocol is used for communicate and transfer data. No explicit definition of product structure. Not explicit in platform Yes, this is done in the meta models with constraints, but the consistency management is unclearly described. ed with the defined transformation rules, but unclearly described. Domain specific modeling is supported Individual tools are primary holder of documents, which means different technique could be used. Tools use adaptor to notice the next required tool. In the peer-to-peer transformation, it requires well defined process. Architecture is developed but implementation is still on-going.