RE SEARCH EMBEDDED SYS TEMS

RESEARCH PROJECT VERDE – CROSS PROCESS TOOL PLATFORM FOR EMBEDDED SYSTEMS The research project Verde has the aim of providing a universal tool platform for the verification- and validation-orientated development of embedded systems. Verde is the abbreviation for “verification-oriented & component-based model driven engineering for real-time embedded systems”. The focus is on the integration of the tools which are already in use at the industrial partners. Verde develops new tools and methods in the areas where there are gaps in existing tool-chains and procedures. Itemis GmbH is one of the research partners and represents the cross industry project, sponsored by the BMBF, in this paper.

AUTHORS

ANDREAS GRAF

is Business Development Manager Automotive at itemis GmbH in Pforzheim / Stuttgart (Germany).

MICHAEL KRAUTER

is Software Architect at itemis GmbH in Pforzheim / Stuttgart (Germany).

50

1

BENEFIT

2

TARGET PLATFORM ECLIPSE

3

REQUIREMENTS FOR THE IMPLEMENTATION

4

STRUCTURE OF THE REQUIREMENT PROFILES

5

IMPLEMENTATION PLANNING

6

ANALYSIS

7

CODE GENERATION

8

OUTLOOK

1 BENEFIT

The rising complexity of embedded systems presents growing challenges to projects. For the implementation of features it is no longer sufficient to design and develop individual components in each case. Only the interaction of several components realizes the required functionality. The emerging communication networks and their relations quickly become unclear. With it, not only are the technical structures a challenge since systems get implemented in cooperation with many organizational units. This also affects, according to Conway, the technical features and the approach. Often embedded systems emerge as part of a product line so that the developers must in parallel correctly develop, validate and maintain the different versions of the software. Therefore it is necessary to understand the requirements and the product and above all to be able to track, thus making statements about the quality. Especially with changes to the system this gives benefits to the developers: The impact of requirement changes on the system and back are easier to analyse. Therefore development standards for safety-critical systems like e.g. Automotive Spice demand univer-

sal traceability. In this case gaps in the tool chains and in the methodology complicate the work. The research project Verde, ❶, wants to close these gaps. 2 TARGET PLATFORM ECLIPSE

Still only a few years ago it would have been difficult to define a heterogeneous research project with a common platform. Tools are based on several programming languages (Java, C or C++) and use different libraries for the user interface or data storage in such a way that they do not seamlessly work together. This problem is known to many companies in the process chain. Therefore Eclipse [1] established itself in recent years as an open tool platform with a powerful infrastructure. All Verde industry partners already use both commercial and internally developed tools based on Eclipse. 3 REQUIREMENTS FOR THE IMPLEMENTATION

In order to track the requirements, they must be associated with the other artefacts. In contrast to design, implementation and tests the tooling landscape for requirements coverage and management is still sparse in Eclipse. Ideally therefore implemented within the framework of an appropriate infrastructure like Verde. This covers: : the definition and processing of the structure of the requirements (different requirement types, their attributes and relationships among one another) : the content of the requirements. To address the limitations of descriptions in natural language, the focus lies specifically on the connection of early models and the support of domain-specific notations for requirements

❶ Scope of the research project Verde

06I2010

Volume 5

51

RE SEARCH EMBEDDED SYS TEMS

4 STRUCTURE OF THE REQUIREMENT PROFILES

“LEAD CUTS PAPER” A weight is a kind of value. 10 kg specifies a weight. Everything has a weight. A thing usually has weight 1 kg. A container has a weight called breaking strain. The breaking strain of a container is usually 50 kg. Definition: A container is bursting if the total weight of things in it is greater than its breaking strain. A lead pig, a feather, a silver coin and a paper bag are in a room called the Metallurgy Workshop. The paper bag is a container with breaking strain 2 kg. The lead pig has weight 50 kg. Every turn when a container (called the sack) held by someone visible (called the chump) is bursting: say “[The sack] splits and breaks under the weight! [if the player is the chump]You discard[otherwise][The chump] discards[end if] its ruined remains, looking miserably down at [the list of things in the sack] on the floor.”; now all of the things in the sack are in the location; remove the sack from play.

❷ “Controlled Language”: readable and machine analysable

Preset: studies (FIELD PRESCRIPTION) Prescribed: patients (FIELD PRESCRIPTION) Accumulated: patients (FIELD ACCUMULATION) s: studies no_field dom (Preset s) p: patients no_field dom (Prescribed p) dom (Prescribed p) = dom (Accumulated p)

❸ “Controlled Language“: readable and machine analysable

To benefit from a continuous workflow to the greatest possible extent, the users too want to access the requirements from the integrated tool. As tool chains for requirements management are established with industry partners, the main focus of development lies on import and export of requirements as well as tracking. Consequently Verde only implements a basic tool for editing. The tool implements the exchange standard “ReqIF”, which is currently standardized by the OMG. The ReqIF standardization group models the meta model of the requirements in UML. Thereby the entrance of model-based software development keeps within a limit. A special generator creates the EMF model from this UML model and also the necessary infrastructure for Eclipse. Thus the requirements can already be edited by Eclipse. To increase comfort, a special user interface analyses the data model at runtime and dynamically presents to the user the convenient input masks. New versions of the standard, which are not yet finalized versions, can be adapted quickly without further manual efforts as a tool. The requirements import constructs the foundation for the traceability and connection to the models. 4.1 FORMAL NOTATION AND MODELS

Traditionally requirements are expressed in natural language. However the natural language suffers the disadvantage of not being precise enough and impedes (mechanical) analysis. Accordingly, requirements typist recommend to find clearer wording by means of formal notations. The typist can directly write down the requirements in formal language or replenish them with models. Here a great clearance arises, beginning with the usage of specially structured sentences (patterns). A requirement can for example in a mandatory way be derived from the structure “Conditions”, “Actor”, “Shall”, “process”. A higher degree on formality is accomplished by using “Controlled Language”. This builds a bridge between “readable” and “mechanical usable”. An example from the authoring software “Inform 7” shows readable text, which is analysed and interpreted from a utilization logic, ❷. At the “formal” end of the range lie methods like the z-specification, which are often too formal for stakeholders and do not match the language, used in the domain, ❸. 4.2 STRONG FORMAL NOTATIONS

❹ Language definition with Xtext

: the traceability of the requirements to other artefacts in the development process. In this case it is not the relationship between requirements but between the requirements and further artefacts ike models, code and tests are considered. : the automatic generation of traceability during code generation.

52

With domain-specific languages, a method from software development, the suitability for the project can be improved. A DSL is a specific machine-processed language which is designed to characterise specific aspects of a system in a special domain. The concepts and notations used correspond to the way of thinking of the stakeholder concerned with these aspects. Domain-specific languages can thereby be graphical or textual. The advantage of DSLs has long be known. The best modelling language has only limited use if there is no tool support. The increasing spread of DSLs also is founded in that in the recent years low cost, powerful tool support has become available. Thus, their use on a broader basis is possible. Modern age “Language Workbenches” build from a language specification complete development environments with integration, syntax highlighting and navigation. In the Verde requirements editor the open-source tool Xtext is adopted. The editor for the domain-specific languages integrates itself directly into the requirements tool. The grammar in ❹ describes a language that allows both free text, that must be formulated in “Shall” form, and also a more formal notation for general conditions.

❺ shown right is the automatically generated editor with syntaxhighlighting. The fourth line is not the grammar (“must” instead of “Shall”) and is marked accordingly. Already established is the use of models as an extension for natural languages. Thus requirements frequently become completed and connected with state machines, sequence and class diagrams. With the integration of Xtext the connection is one step more powerful: Since both requirements text and model are formally available, it is possible to refer to the respective inner structure. While the user enters a requirements text, he has full access in the editor, for example to the UML models and the references are more fine-grained: From the formal text of a textual requirement with Xtext the model elements of additional models can be accessed (for example, the system model in SysML), ❻.

4.3 TRACEABILITY

To assure that the requirements are fully implemented in the system, it is necessary to trace this during the whole development process. This enables validation and verification. On changes to the requirements the effect on the software can easily be tracked down. Vice versa in later phases on changes it is easy to analyse which requirements were affected by the changes. Therefore it is necessary not only to assign requirements to artefacts but also to relate artefacts of earlier phases with artefacts of later phases. This generalization is reflected technical-

❺ Integrated DSL

ly in an generic solution for the traceability of EMF based elements. Centre of the implemented solution is a mapping table with three elements: origin element, target element and additional information like description et cetera. The elements are defined over an identifier, the so called “Tracepoint“, ❼. The exact structure of a tracepoint at the same time depends on the corresponding model. A UML model element for example is identified by an unique ID, a C source file in contrast is identified by file path and name. The basic implementation does support the assignment of model elements with a simple user interface: the origin element gets selected in the according tool and thereafter marked in the window for assignments. After this, the target element is marked in the according tool and the connection is im-

❻ Fine-grained references 06I2010

Volume 5

53

RE SEARCH EMBEDDED SYS TEMS

❼ Extendible traceability solution

printed in the assignment window. Similarly the assigned elements can be evaluated from every single element and can be navigated to. A more user friendly adoption to model types is possible over extensions. These provide more information on tracepoints to the tracing kernel: : A readable name. This is necessary since the element defining identifiers are often cryptic to the human user and thus barely usable for an oversight. : Information on the design of the model element. This could be information e.g. on diagrams, editors etc. Thereby the required view in Eclipse is restored on navigation to a corresponding element, ❽. Technical solutions of other tools are often based on the import of requirements into the target model. In this the requirements are imported with the stereotype “Requirement” similar to the UML and traceability is enabled by means of modelling. However, this

has the constraint that not all models support suchlike extensions. Autosar for example does not have such an extension concept and also the traceability to code is not considered. 5 IMPLEMENTATION PLANNING

Beside this traceability alongside the development artefacts there is the possibility to correlate project management data with the artefacts. In the development process the software is implemented in different release states/integration levels with growing functionality. For coordination and project planning it is crucial to trace what function is implemented in which milestone. If the milestones also are included in EMF, this assignment is traceable with the same mechanisms as the traceability to other artefacts. 6 ANALYSIS

The information from the artefacts are necessitated in various ways – as documentation, in addition to the specification sheet or interactively for better understanding of the system and for cost estimation. By the close integration to Eclipse these requests can easily be created even model and tool comprehensive. Reports in the project are generated among others by means of the model-to-text transformation engine Xpand. Xpand takes a number of (EMF) models as input and builds up a textual output. Developers of the reports can therefore rely on a single technology for all models/artefacts. 7 CODE GENERATION

❽ The basic user interface of the traceability tool

54

In the model-based software development a great percentage of runable code is generated automatically. But also in the automation it is necessary to create the references to artefacts of earlier

phases. It seems likely here to take advantage of the abilities of the code generator without needing to manually adapt the code generators. Here too it is not the point to include the tracing information directly into the code (even though it can be a sensible enhancement), since the mechanism should be independent of the generated code, so not to be in need of having knowledge on comments etc. Verde extends the open-source code generator Xpand by this functionality. Xpand is a pattern-based code generator which can be adjusted by the users in various ways, so that the mechanism does not need to rely on a specific output format. A pattern-based generator uses an origin model as input and a generating pattern at code generation. This is processed into a combined textual output file. Xpand is now able to create another protocol file while writing to the output file, in which information is stored on what parts of the output file, which model elements and what patten parts where applied. This not only enables tracing of the requirements through the development chain but also incorporates the used tools (patterns) in development. Hence Eclipse offers the chance to illustrate continuous traceability. It is planned to provide the achievements as open source to the Eclipse Modelling Platform. In this Eclipse working group different companies discuss a cooperation to collectively define an infrastructure for a collaboration platform. This includes frameworks for rights management, bulk models, distributed work and versioning management. 8 OUTLOOK

The activities for supporting requirements with domain specific languages and for traceability indicate the start of the Verde process chain. With the integration of DSLs and models, project partners like FZI Karlsruhe can test new concepts for formulation of requirements, in particular non-functional requirements as memory usage and timing fast and iteratively. To accomplish this the initial preliminary work is done, for example by implementing the timing specification from the UML real-time profile “Marte” with Xtext in a comfortable editor. With the lightweight tooling support, changes in the approach can quickly be realized and tested. Also on abstract levels these concepts are attached. Thus we introduce domain-specific languages in a project to declare the scenarios, ❾. The existing and acquired methods and tools are merged into an integrated platform. To check statements on non-functional attributes of the system early on, Verde analyses existing target platforms to define an interface with execution and communication semantics. Based on this, adapters for available target platforms of the project partners are integrated. Here lies a special focus on the execution model of SystemC, the Autosar standard as well as the integration of heterogeneous simulator combinations. Verde accomplishes corresponding activities for analysing tools. Since the methods have to be applied to existing systems it is necessary to provide a reverse engineering solution to transform established systems (semi-)automatically into the Verde concept. Parallel during the project, which is running until 2013, the Verde solution is extended by model-based testing. Within research projects, according to the rules of promotion,no “products” but rather solutions and concepts are developed, which can subse06I2010

Volume 5

❾ Domain-specific languages scenario description

quently be used for product development. Correspondingly the requirements tool cannot be looked on as a commercial product. Due to the integration of Eclipse it offers various possibilities, which itemis is willing to pursue on several tracks. The project BIRT (Business Intelligence and Reporting Tools) offers extensive functionality to create reports in different formats. It could be a good solution for creating printed documents out of requirements. In the project Verde, project leaders were confronted with the challenge that the requirements for the project had to be consolidated from ten different project partners. Especially the detection of duplicates can be a very time-consuming task. For simpler arrangement of the requirements to groups, they were linguistically analysed by means of a Perl library. For that purpose the requirements where broke down, filler words (“the”, “this”, “shall”) were filtered and the word stem for the left words was build. This way e.g. the terms “simulation”, “simulated” and “simulator” are mapped to the word stem “simul” which in turn got assigned all occurrences in the requirements. This way it is quite simple to find thematically similar requirements in the whole. The Lucene project provides a solution for a search engine which can be supplemented by linguistic analysis. Accordingly the concepts can be adopted for Eclipse tools. Not covered are the user rights issues, versioning, bulk models and distributed work. On these topics the working group “Eclipse Modelling Platform” forms up in the context of the Eclipse foundation, which is busy on generic frameworks matching these topics. As soon as results are available, they will be integrated into the Verde requirements. Together with the companies Validas AG, Symtavision, BMW and the innovation centre “Imes” and the TU Munich, itemis finds itself in the proposal phase for the research project Imes, which deals with the model-based development and documentation of requirements in early phases of the function development. Here the topic of cross company repositories is also addressed, so that the research projects gain profit from synergies.

55