The overall objective of work package 5 is to implement commercially applicable solutions based on the iFEST integration framework and further to extend the associated technologies to demonstrate economic benefits for embedded system development. The evolution changes for embedded systems are manifold, and can be considered as a multi-dimensional process. Design evolution, architecture evolution and code/models evolution are running in parallel.
WP5 aims at developing an integrated solution approach for management of the entire engineering lifecycle from the product inception to phase-out and the support of the architectural diversity of platforms. This will be done by considering the development of customizable and composable tool chains throughout the entire lifecycle and for HW and SW, which we commonly refer to as HW/SW co-engineering (HW/SW co-requirements, co-design, co-integration, co-verification and co-validation).
WP5 will deliver an operational and open source implementation of the integration framework. Close collaboration with the projects CRYSTAL and MBAT is planned and joint standardization initiatives will be initiated. At the end of the EMC² project, there will be an advanced state-of-the-art regarding Tool Integration and interoperability, extending Hardware/Software collaboration from co-design to co-engineering and transversal services.
One way to classify interactions between engineering work products and tools is as either data- or control-oriented. There are for example needs to trace from requirements to design models and code. Tracing represents data integration. When introducing new engineering tools, for example for verification and validation, it is highly desirable that existing information can be readily reused. Such information transfer represents another case of data integration. Control integration represents a further type of interaction where certain tools need to use (“control”) the functionality of other tools. For example, as illustrated in the figure below an orchestrator tool may perform a sequence of actions on other tools, based on some user-defined workflow (represented in dashed lines). Tool integration also encompasses further aspects such as platform and presentation integration; the integration framework encompasses all these aspects and their interdependencies.
The WP5 approach to tool integration aims to facilitate the communication processes and the availability of correct, timely and useful information during the development of embedded systems and to remedy the highly fragmented nature of incompatible tools for embedded systems development, with particular emphasis on hardware/software (HW/SW) co-design and lifecycle aspects.
WP5 is structured into 5 tasks.
The aim of Task 5.1 is to elicit stakeholder requirements and develop requirements for system design flow platforms, tools, models and interoperability. The breadth of the EMC² AIPP will be exploited such that tool integration requirements from several domains are covered. Interactions with the technical WPs and LLs are expected to provide a large covering of tool usage scenarios, in cross-domain applications and in a cross-partners manner.
The objective of Task 5.2 is to develop a tool integration framework which will be used to establish well-functioning tool chains supporting HW/SW co- design of embedded systems and life cycle support. The integration framework shall enable the integration of tools which are used throughout the engineering lifecycle of complex embedded systems.
Key components will include:
The integration framework will build upon and promote interoperability standards, in addition to combining the best of emerging tool integration technologies and research results (such as Crystal, MBAT and CESAR).
Aim of Task 5.3 is to develop cross-cutting services that support the HW/SW co-engineering activities, by generating relevant management information from across the tools in the tool-chain, leading to an informed decision making process throughout the entire development lifecycle.
Transversal services build upon the functionalities and data available from the already-integrated tools of a tool-chain, in order to conceive and provide additional higher-level functionalities. Transversal services are similar to basic services (such as process orchestration and traceability management) in that they are crosscutting tools whose functionality requires interactions with the other integrated tools in the tool chain. However, basic services are standard functionalities that can be expected to be needed by almost all industrial cases through a uniform functionality. Transversal services on the other hand are specialized services that may be deployed for very specific and customized needs, and generally built upon data and features provided by basic services.
Such services can be practically introduced by implementing its functionality as a tool and then integrating it into a tool-chain. Such a transversal tool would then consume the services of the other needed integrated tools, in order to provide the expected functionality to its end-user.
Task 5.4 is focused on the implementation of the integration building blocks required to develop and integrate Tool Chains assets (consisting of integrated Engineering Tools with Basic & Transversal Services) based on the Framework Specifications provided by T5.2.
The main input of this task consists in the Framework specifications which define the Integration Interfaces for achieving interoperability between Engineering Tools and Basic & Transversal Services that are required for instantiating and deploying Tool Chains fulfilling the needs and integration scenarios from the EMC² Living Labs Use Cases.
This task aims at providing the minimal set of features and services required for developing and integrating these Tool Chains. It provides:
Task 5.5 will investigate how the WP5 outcomes can contribute to existing and emerging standards or to what extent new standards need to be defined. It will do this in close collaboration with other running projects such as MBAT and CRYSTAL and will interact with existing standardization bodies such as the UML OMG., OASIS, OSLC etc.