Integration and Analysis of Design Artefacts in Embedded Software Development

Abstract

In model-based development of embedded software product lines, artefacts, i. e. the requirements document, implementation model, and tests, often become extremely complex w. r. t. size and dependencies. Moreover, the interrelationships among the artefacts are not obvious and information about development, design decisions as well as variability-related aspects are missing. Hence, engineers have to thoroughly analyse such dependencies to incorporate changes during evolution of the product (line) to assure quality. As this task is time-intensive and error-prone such analysis efforts have to be automated. This paper presents a comprehensive and extensible framework under development which provides (1) artefact integration and (2) analysis functionality to address these issues by following an approach based on a central database. Keywords-embedded software development, artefact analysis I. MOTIVATIONIn the automotive industry the development process for embedded software is highly driven by market demands. Since these demands are very dynamic concerning the need for innovation and rapidly evolving technology, the same holds for the embedded software development in this domain. Engineers need to react on frequent changes of requirements while keeping or even increasing software quality and decreasing time to market. To do so, they need to analyse the relationships among requirements, implementation and tests and to identify dependencies. In Section II the state of the art and the evolving challenges are substantiated in more detail from a technical point of view. Subsequently, we will present related work to tackle the challenges in Section III. Section IV will explain our approach before summarising the preliminary results in Section V. Finally, we will conclude the paper giving a short summary and describing the outstanding steps in Section VI. II. CHALLENGESMost of the challenges concerning quality assurance and decreasing time to market are related to the well-known problem of tool isolation described by Broy et al. [1] since the tools used for the different artefacts, i. e. here IBM Rational DOORS [2] and MATLAB/Simulink [3], unfortunately cannot interact deeply enough. Although links among requirements in IBM Rational DOORS and blocks in MATLAB/Simulink can be created it is not possible to automatically identify them. Moreover, inconsistency among the artefacts can occur in the sense that requirements are not fully implemented or tests are not adapted to changed requirements.A further aspect, which complicates further development and evolution, is missing or scattered meta information about the development process and evolutionary or variability aspects. In the context of software product lines, for example, parts of the implementation model, i. e. subsystems of the Simulink model, should be annotated with information about which production series they are relevant for, which change request affected them and which release they belong to. As [4] points out, 50% of development costs are needed just to understand l...