A Modular Tool Integration Approach Experiences from two Case Studies Matthias Biehl, Carl-Johan Sj¨ostedt, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,carlj,martin}@md.kth.se

Abstract. In the model-driven development process of automotive embedded systems a number of specialized tools are used to support various development tasks. Each tool needs to work seamlessly with artifacts created by other tools to increase the efficiency of development. We identify desirable properties for integrating the data of different tools. We then propose an approach for decomposing the data integration into modular steps that fulfill these properties. We report our experiences from applying this approach to integrate simulation capabilities and functionality for safety analysis into a model-based development environment. Key words: Tool Integration, Model Transformation

1

Introduction

Model-based development is an approach that uses models as primary artifacts for describing a system. During development a series of different models is created, refined, analyzed and transformed. The tools that are used to manipulate and develop the models are highly specialized and have their strength in supporting a particular development task or phase. Different tools are used to work with the modeling data, and often the output created by one tool needs to be the input to another tool. The tools need to be aligned in such a way that they form a tool chain. Not only tools for creating and designing models need to be integrated, but also tools for analysis and simulation. Some of the tools are proprietary and closed, thus they cannot be modified to support a particular integration scenario. The tools and their modeling data need to be integrated to realize the vision of a seamless model-based development approach. While it is possible to achieve an ad-hoc integration between two tools with some manual work, the focus of this paper is on working towards a systematic solution for model-based tool integration. In this work we extract a modular tool integration approach from the commonalities we have identified based on the experiences from several point-to-point integration approaches. This work has been carried out in the context of developing EAST-ADL [3], a modeling language for automotive embedded systems. We report on experiences from two case studies involving tool integration between EAST-ADL and the simulation

tool MATLAB/Simulink [11] as well as between EAST-ADL and a reliability analysis tool HiP-HOPS [13]. The remainder of this document is structured as follows. In section 1.1 we introduce some basic terms and technology. Section 2 describes the requirements for data integration. Section 3 introduces our modular approach for data integration fulfilling the previously identified requirements. In section 4 we describe two case studies using our proposed approach. In section 5 we introduce related work and conclude in section 6.

1.1

Terms and Technology

The technical space of a model concerns the technology used for representation of the model [12]. Typical technical spaces are EMF (Eclipse Modeling Framework) or XML. The technical space comprises all modeling levels M0-M3 by the OMG. Each technical space has its own metametamodel and its own set of tools and technologies to interact with the models. Model transformations describe the relationship between models, more specifically the mapping of information from one model to another one. A model transformation involves two models: a source model and a target model, where source and target models can have the same or different metamodels. A model transformation description is written in a special purpose language, a model transformation language. The transformation description is usually given by a set of model transformation rules, describing how a model in the source language can be transformed into a model in the target language [10]. The model transformation descriptions are interpreted by a model transformation engine which produces the target model-based on the transformation description and information from the source model. Model transformations are based on concepts of the metamodels, thus they can map any model that corresponds to the metamodel. In this work we use two different model transformation engines, a model-to-text and a model-to-model transformation engine. In the following paragraphs we introduce these engines. OpenArchitecureWare (OAW) integrates a number of tools for model transformations into a coherent framework [5]. OAW provides a workflow specification language and the transformation language Xpand. The Xpand transformation language is a template-based, imperative language for model-to-text transformations. The ATLAS Transformation Language (ATL) is a hybrid model transformation language [8]. It includes both declarative and imperative constructs and supports both programming styles. However, the preferred style is declarative, which allows a cleaner and simpler implementation for simple mappings. ATL is integrated in the Eclipse development environment and can handle models based on EMF.

2

Needs for Data Integration

There are several dimensions of tool integration, Wassermann [15] classifies them into the dimensions of data integration, control integration, process integration, platform integration and presentation integration. In this paper we mainly focus on one dimension of tool integration, which is data integration. The data of model-based tools is represented by models. However, these models adhere to different metamodels which determine the structure of the data and the models are represented using different technical spaces. Goals and desired properties for the integration solution are simplicity and understandability, maintainability and evolvability (i.e. if tools change their interface, the tool integration to change the interface as well), exploiting advantages of different model transformation paradigms. When data needs to be integrated between Tool A and Tool B, the data of Tool A has to be expressed in such a way that it can be used by Tool B. In this process, some properties of the data need to be changed, while other properties need to be preserved. In the following sections we identify these properties. 2.1

Changes of Properties for Data Integration

The following properties of the data might need to be changed for data integration: – Change of the abstract syntax: The structure or syntax of the data might need to be adapted to the target tool. The information of the source tool needs to be rearranged to adhere to the structure expected by the target tool. For example one tool might represent data in a nested tree structure, while another represents the same information as a list. Syntactic changes or restructuring of the information is the domain of model transformations. This part deals with the selection of appropriate information from the source model and restructuring it appropriately. The mapping is based on the information in the metamodel of both source and target model. This step is independent of the technical space used by the target tool. – Change of the technical space: Models can be represented using different technical spaces. The information needs to be represented by the technical space expected by the target tool. Even if the information is structured as expected by the target tool, it can be represented using different technical spaces. The same structure can be represented using e.g. XML, an EMF model, a text-based format or a proprietary format. The above mentioned properties are orthogonal to each other and can be changed independently. It is for example possible to change the technical space while preserving the abstract syntax. 2.2

Preservation of Properties for Data Integration

The following properties of the data might need to be preserved for data integration:

– Preservation of the concrete syntax and graphical layout: Models are often presented to the user in a graphical form. The user can convey information by the graphical placement of model elements. It can e.g. be expressed that certain elements belong together by placing them close to each other on the drawing canvas. In a textual concrete syntax, similar grouping can be expressed e.g. by the proximity of variable declarations. – Preservation of the semantics: If the integrated tools are similar, a mapping can be found that is semantics preserving, i.e. the meaning of the two models is the same, even though it is represented in a different technical space or using a different abstract syntax. Semantics-preserving transformations change the way computations are performed without changing the values computed. – Approximation of the semantics: If the integrated tools have fundamentally different assumptions, it might be difficult to completely preserve the semantics when bridging the gap between tools. Instead the mapping between the tools can approximate a preservation of the meaning of the model. Approximation can preserve the essential properties of the model. An example is the mapping from a complex state machine to a simplified state machine or the mapping between a nonlinear mathematical function and a linear mathematical function.

3

A Modular Approach for Data Integration

In our solution we use the principle of separation of concerns to structure the data integration in such a way that the two issues identified in section 2.1 remain independent. That way we achieve a modular solution, having advantages for maintenance, evolution, understandability and reuse.

Fig. 1. Technical Space Bridges and Structural Bridges

Fig. 1 presents our approach for data integration of three different tools. Each of Tool A and Tool B use different metamodels to represent their data and different technical spaces. Neither tool uses EMF as their technical space. EMF is the adopted technical space for integration. This requires that each tool represents the relevant data in the technical space of EMF. A third tool - Tool C - already represents its data using EMF-models and hence does not require an intermediate model or technical space bridge. Its data can be mapped using a structural bridge. This can for example be the EMF-based modeling environment Papyrus. For both Tool A and Tool B there is an associated intermediate model (see section 3.1), that stores the relevant tool data in EMF, the adopted technical space for integration. A technical space bridge (see section 3.2) crosses the technical space between the tools and EMF to import or export the relevant data. A structural bridge (see section 3.3) links the elements of the intermediate models and changes the abstract syntax so that the semantics is preserved (or approximated). 3.1

Intermediate Model

Intermediate models are the tool-specific models that represent tool data in the technical space for integration. These intermediate models are syntactically aligned with the tool data, meaning that the intermediate data is structured in the same way. The difference between the intermediate model and the tool data is the technical space. In a tool chain, the tool data is first represented as an intermediate model using a technical space bridge, then a structural bridge is used to map concepts to the intermediate model of the target tool, finally the technical space bridge of the target tool represents the concept in a tool specific way. The intermediate model usually focuses on a certain subset of the tool data that is considered relevant in the context of integration. Thus the intermediate model is a simplification of the tool data. In Fig. 1 this is illustrated by a smaller circle for the intermediate metamodel. Irrelevant data, such as certain parameters, details or redundant data are left out. The amount of data that needs to be included in the intermediate model depends on the use case. If complete roundtrip integration is required, the intermediate model needs to be complete. However the limitation on a relevant subset of the tool data allows the transformation to stay small and maintainable. 3.2

Technical Space Bridge

Technical space bridges have the purpose of transitioning data between the external representation of the tool and the intermediate model in the technical space chosen for integration. Technical space bridges can be used in two directions, as extractors and as injectors. Extractors read proprietary tool-specific data and represent this data in the technical space of integration. Injectors deal with representing model data in a tool specific way. Since we propose that the

intermediate model is as small as possible, the extractor leaves out irrelevant data, whereas a injector adds missing information in the form of default values. Technical space bridges are trivial when the tool already processes models of the adopted technical space for integration. Otherwise, technical space bridges are specific to each tool that is integrated. They are hard to generalize and hence we survey the different mechanisms for injecting or extracting data from proprietary tools: – Reading and writing files are the usual way to exchange data. Parsers can be used as extractors and model-to-text transformations can be used as injectors. – For injection of data into legacy tools we can use program parameters and stdin when calling the tool, for extraction we can use stdout. – An application programming interface (API) can be used to inject and extract data from the tool. – A component infrastructure (e.g. CORBA, DCOM) or web service can be used for bidirectional data exchange, if the tool provides these facilities. – The scripting language or macro inside the target tool can be used for injection or extraction of tool data. The first few mechanisms are similar, as all of them use external means to get hold of the data, while the last mechanism uses the internal capabilities of the tool to make the information available. 3.3

Structural Bridge

Structural bridges map corresponding data elements of different tools. Model transformations describe the relationship between models and thus they can be used as a mechanism for structural bridges. Structural bridges can assume that relevant tool data is available as an intermediate model in a common technical space for integration, which is EMF in our solution. However, a large number of model transformation languages, engines and tools exist, which have different characteristics that can be relevant for certain integration tasks. An overview and a classification of the transformation tools is provided in [12, 4]. Picking the right model transformation tool for the task at hand is a challenge. The selection of the model transformation tools is dependent on the technical space that is involved and on other properties offered by the transformation tool, such as bidirectionality, traces and programming paradigms. In the case of a common technical space, a declarative language such as ATL can express the mappings in a simple and concise way [7].

4

Case Studies

To validate our integration architecture, we performed two case studies. Both case studies are based on the architecture description language EAST-ADL [3], a language for modeling the architecture of automotive embedded systems.

4.1

Integration of a Reliability Analysis Tool

During the model-based development in EAST-ADL, the reliability of the developed system has to be determined. We chose HiP-HOPS as a tool for reliability analysis, as it supports fault tree analysis and failure modes and effects analysis [13]. We integrated HiP-HOPS with EAST-ADL as described in earlier work [1]. This integration is unidirectional and the data from EAST-ADL is exported to HiP-HOPS for analysis.

Fig. 2. Export from EAST-ADL to HiP-HOPS

The tool for developing EAST-ADL models, the Papyrus UML editor, does not require a specific technical space bridge, as it produces compatible EMF models in the technical space of integration already. In this case, the intermediate model is equal to the tool data. The reliability analysis tool HiP-HOPS expects textual input, which can be synthesized from the EAST-ADL model by a technical space bridge and a structural bridge. We used the integration architecture described in section 3. Intermediate Model As shown in Fig. 2 we introduce an intermediate model which serves as the interface between technical space bridge and a structural bridge. The intermediate model conforms to a HiP-HOPS Ecore metamodel that is aligned with the HiP-HOPS grammar. Structural Bridge The structural bridge transforms an EAST-ADL model that was created in the Papyrus UML modeling environment into an intermediate model. The transformation is called M2M Trafo in Fig. 2. The structure of the intermediate model resembles the HiP-HOPS grammar, so it is close to the structure of the desired output. This stage performs a semantics-preserving mapping between the domains of EAST-ADL and that of HiP-HOPS. However, this stage is not concerned with the actual representation of the data. The purpose of the structural bridge is to map concepts from EAST-ADL to HiP-HOPS in a way that preserves the semantics of the original model, even though the structure of the model must be changed heavily. EAST-ADL models and HiP-HOPS

models are structurally different. This can be demonstrated by the following example. EAST-ADL follows the concepts of declaring types first and referencing to the declaration from each point of use. In HiP-HOPS on the other hand, the declaration and usage of a type is coupled, types are declared at the same point as they are used. Thus the declarations have to be inlined into every point of usage, when transforming from EAST-ADL to HiP-HOPS. Technical Space Bridge The purpose of the technical space bridge for HiPHOPS is the generation of a textual description based on the intermediate model. The technical space bridge takes the intermediate model as input and creates the tool-specific file for the HiP-HOPS program. This step is mainly concerned with the representation of the information according to the concrete syntax required by HiP-HOPS. No structural changes are required in this transformation. The focus is on serializing the model as text. The technical space bridge is realized as a model-to-text transformation and can be classified as an endogenous, horizontal, model-to-text transformation. We choose the Xpand language of OpenArchitectureWare to implement the technical space bridge. Xpand is a template-based model transformation language, which incorporates the output in the form of templates into the control structure. 4.2

Integration of a Simulation Tool

The tool-suite MATLAB/Simulink is a simulation tool used at various stages of automotive product development for different purposes, e.g. control design, code generation, hardware-in-the-loop testing, etc.. We have developed a bidirectional tool integration between Simulink and EAST-ADL. The first version of the tool was presented in [14]. The current version presented here follows the same approach to separate the technical space bridge from the structural bridge. The integration is bidirectional and supports import from Simulink to EAST-ADL (see Fig. 3) and export from EAST-ADL to Simulink (see Fig. 4).

Fig. 3. Import from Simulink to EAST-ADL

Fig. 4. Export from EAST-ADL to Simulink

Intermediate Model Simulink has an extensive set of tool data using a large number of different element types and parameters. Not all of the details contained in the tool data are relevant for the integration with EAST-ADL. A large intermediate model would make the structural bridge more complicated and harder to maintain. That is why we create an intermediate model from only the relevant subset of the tool data (see Fig. 5)

Structural Bridge The purpose of the structural bridge is to map concepts between EAST-ADL and Simulink in such a way that the semantics of the original model is preserved. For example, Simulink Lines correspond to EASTADL FunctionConnectors; Simulink Inports and Outports both correspond to the same concept FunctionFlowPorts in EAST-ADL, only differentiated by the value of the direction attribute. We use ATL for implementing the structural bridge.

Technical Space Bridge We have evaluated two ways of accessing Simulink model data, first by parsing the .mdl files using a metamodel of the Simulink data file (as presented in [14]), and second by using the MATLAB API. Using the MATLAB API more data is available but the downside is that it provides too much information: A regular Simulink block has more than 120 blockparameters, of which many of them are rarely used. The large number of exceptions for certain parameters and block-types resulted in an unmaintainable and inefficient solution. Hence, the current solution is a combination of using the API and .mdl files. We store all modeling elements inside .mdl files, so they can be used in model reference blocks. The Simulink library mechanism works in a similar way and could possibly also be used in a future version of the technical space bridge. By using Simulink’s native .mdl format for storing the system containment, it is ensured that valid models are produced, and most Simulink constructs can be used. The ports and connections between these model reference blocks are translated so it is possible for model reference blocks to contain other model reference blocks.

Fig. 5. Intermediate Metamodel for Simulink

5

Related Work

Karsai et al. identify two patterns for tool integration [9], one with an integrated data model and a second pattern based on process flows. Our approach is similar to the second pattern, however it does not require the extensive backplane solution. While Karsai describes a pattern, our approach is a concrete solution for the automotive domain. ModelBus is an integration infrastructure [6], providing services such as model storage and version management. Tool adapters are connected using web services. Since the ModelBus infrastructure does not constrain the modularization of the connected services, the approach proposed in this paper is orthogonal to the ModelBus infrastructure, allowing both approaches to be combined. Cuadrado et al. survey different techniques for the modularization of model transformations. The work differentiates between internal and external composition of model transformations and proposes a phasing mechanism for internal composition [2]. Our approach uses external composition as it allows us to use different model transformation languages and engines that are fit for the particular purpose.

6

Conclusion

In this work we have analyzed the needs for exchanging data for tool integration. Whereas some aspects of the data need to be changed such as technical space and the abstract syntax, other aspects need to be preserved such as semantics and layout. We present a modular tool integration approach that uses separation of concerns to modularize and separate the identified changes in technical space and abstract syntax. Technical space bridges bring tool data into the technical space of models and represent the data as an intermediate model. The tool-specific

intermediate metamodel is a simplification of the tool data. The intermediate metamodel is designed to comprise only the subset of the tool data that is relevant for the integration. Structural bridges translate between concepts of different intermediate models. We applied this approach for integrating two external tools within a development environment for EAST-ADL and identified the following properties of our solution: – Our solution separates two different concerns of the tool integration: (1) the structural bridge between the domains of EAST-ADL and that of HiPHOPS/Simulink and the (2) technical space bridge for representation in the technical space of the tool. – Each part is a separate, self-contained module, which can be developed, changed and tested independently. This decomposition into two separate modules allows us to parallelize the work on the two transformations and reduce development time. It also allows the two transformations to evolve independently without affecting each other. – As the HiP-HOPS tool is evolving, it is being updated and with it its external data representation. The tool introduced an XML representation of its input data. When integrating this new version of HiP-HOPS we needed to adapt our transformation. Due to the modular organization of our model transformation the necessary changes could be localized to the technical space bridge only, leaving the structural bridge unaffected, thus ensuring maintainability and evolvability. – The solution allows us to select an appropriate tool for each concern. A declarative model-to-model transformation language was chosen for the structural bridge and a model-to-text transformation languages for the technical space bridge. – Due to the intermediate metamodel, which is a subset of the tool data, the transformation is comparably simple. Since we chose appropriate tools for each steps, the resulting model transformation source code is simple and concise. When we compare these properties to the goals put forward in section 2, our approach is able to fulfill them. 6.1

Future Work

We plan to connect the transformations described in our case study with tool integration infrastructure such as ModelBus. Also, we would like to create a tool chain, in which we can replace a specific tool by another tool. The reduce the dependence on a particular tool and mitigates the risk of vendor lock-in. Acknowledgements We would like to thank Jad El-Khoury for his comments on earlier versions and Alex Schenkman for his programming efforts. This work has been funded by the European Commission under grant agreement no. 224442.

References 1. Matthias Biehl, Chen DeJiu, and Martin T¨ orngren. Integrating safety analysis into the model-based development toolchain of automotive embedded systems. In Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), pages 125+, April 2010. 2. Jes´ us Cuadrado and Jes´ us Molina. Modularization of model transformations through a phasing mechanism. Software and Systems Modeling, 2009. 3. Philippe Cuenot, Patrik Frey, Rolf Johansson, Henrik L¨ onn, Yiannis Papadopoulos, Mark-Oliver Reiser, Anders Sandberg, David Servat, Ramin T. Kolagari, Martin T¨ orngren, and Matthias Weber. The east-adl architecture description language for automotive embedded software. Model-Based Engineering of Embedded Real-Time Systems, 2010. 4. K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, 45(3):621–645, 2006. 5. Sven Efftinge, Peter Friese, Arno Haase, Clemens Kadura, Bernd Kolb, Dieter Moroff, Karsten Thoms, and Markus Voelter. openarchitectureware user guide. Technical report, openArchitectureWare Community, 2007. 6. C. Hein, T. Ritter, and M. Wagner. Model-driven tool integration with modelbus. In Workshop Future Trends of Model-Driven Development, 2009. 7. Philipp Huber. The model transformation language jungle - an evaluation and extension of existing approaches. Master’s thesis, Technische Universit¨ at Wien, May 2008. 8. F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev. ATL: a model transformation tool. Science of Computer Programming, 72:31–39, June 2008. 9. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 10. Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture—Practice and Promise. Addison-Wesley, 2003. 11. Mathworks. Introducing matlab 7 and simulink 6. Signal Processing Magazine, IEEE, 21(5):122, September 2004. 12. Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci, 152:125–142, 2006. 13. Yiannis Papadopoulos and John A. McDermid. Hierarchically performed hazard origin and propagation studies. In Massimo Felici, Karama Kanoun, and Alberto Pasquini, editors, SAFECOMP, volume 1698 of Lecture Notes in Computer Science, pages 139–152. Springer, 1999. 14. Carl-Johan Sj¨ ostedt, Jianlin Shi, Martin T¨ orngren, David Servat, DeJiu Chen, Viktor Ahlsten, and Henrik L¨ onn. Mapping simulink to uml in the design of embedded systems: Investigating scenarios and structural and behavioral mapping. In OMER 4 Post Workshop Proceedings, April 2008. 15. Anthony I. Wasserman. Tool integration in software engineering environments. In Fred Long, editor, Software Engineering Environments, International Workshop on Environments Proceedings, Lecture Notes in Computer Science, pages 137–149. Springer-Verlag, September 1989.