Cornelia Heinisch
email: cornelia.heinisch@stz-softwaretechnik.de

Volker Feil
email: volker.feil@daimlerchrysler.com

Martin Simons
email: martin.simons@daimlerchrysler.com

Efficient

Stz Softwaretechnik

Martin Simons Daimlerchrysler

Efficient configuration management of automotive software

come

Introduction

The history of configuration management (CM) goes back to the early Fifties and has its roots in the aerospace industry. In the Apollo Space Program, thousands of changes were tracked using a defined configuration management process. At that time, the tracked changes belonged almost exclusively to hardware elements. For a long time, configuration management has been used also successfully for software. Elementary to Software Configuration Management (SCM) is the term configuration, where a configuration consists of configuration items (for example source code files, documents, executable system parts, etc.) and a tested configuration is called a baseline. SCM goes back to the mid Seventies and began with the introduction of the first SCM tools SCCS (Source Code Control System) [START_REF] Rochkind | The Source Code Control System[END_REF] and Make [START_REF] Feldmann | Make -A Program for Maintaining Computer Programs[END_REF]. Since that time the discipline of SCM has continuously evolved: RCS (Revision Control System) [START_REF] Tichy | RCS A System for Version Control[END_REF] replaced SCCS in 1985 and one year later RCS was extended to CVS (Concurrent Versions System) [START_REF] Berliner | CVS II: Parallelizing Software Development[END_REF]. A configuration was created by labeling or marking a particular version of each file belonging to the system. Today, tools like Rational ClearCase [START_REF] White | Software Configuration Management Strategies and Rational ClearCase[END_REF] support the developers in SCM. The basic functionality offered by these tools is still the same as in the predecessor tools RCS and CVS.

The term software configuration management is used in diverse areas ( [START_REF] Frühauf | Software Configuration Management: State of the Art, State of the Practice[END_REF], [START_REF] Mackay | The State of the Art in Concurrent, Distributed Configuration Management[END_REF]). According to [START_REF] Dahlqvist | Product Data Management and Software Configuration Management -Similarities and Differences[END_REF], the most relevant aspects in today's SCM tools are: version management, configuration selection, concurrent development, build management, release management, workspace management, and change management. In this paper, we consider software configuration management with respect to configuration selection, configuration verification, and configuration update, because we believe that these aspects are the most relevant to get an efficient configuration management of automotive software. For being efficient a configuration management must efficiently handle the increasing complexity of automotive software (see section 3.1). The key to success is to use hierarchical dependencies between configuration items for configuration selection, to define dependencies between configuration items to verify the correctness of a configuration and to use a configuration update concept which allows to update individual system parts.

Section 2 introduces configuration selection (section 2.1), configuration verification (section 2.2), and configuration update (section 2.3) precisely and section 3 discusses these three configuration management concepts as parts of an efficient configuration management for automotive software. The subsection 3.1 describes a way from a completely implicit configuration management to a completely explicit configuration management and subsection 3.2 discusses a prototypical realization of an efficient configuration management of automotive software. An outlook towards an efficient configuration selection is given in subsection 3.3. The paper concludes with a summary in section 4.

Configuration management concepts

In this section we introduce concepts for configuration selection, configuration verification and configuration update.

Configuration selection

Configuration selection (also known as configuration construction) determines which configuration items belong to a configuration. A configuration item (CI) is a physical entity (source code file, header file, documentation, executable, subsystem, etc.) which is subject to configuration control. A CI can be an aggregation of other CIs, organized in a hierarchy. Any member of this hierarchy can exist in several versions, each being a separate CI. This means, a CI is a version of a node in the hierarchy.

Typically, modern SCM tools allow a hierarchical composition of SCM components to build up an overall system baseline, where a SCM component is a set of related files and directories (the CIs) that are versioned and baselined as a single unit [START_REF] White | Software Configuration Management Strategies and Rational ClearCase[END_REF]. A CI can be atomic, like documents and modules, or composed, like libraries and systems. According to [START_REF] Bendix | Software Configuration Management in Software and Hypermedia Engineering: A Survey[END_REF], versions of a SCM component are also CIs at a higher level. A composed CI which forms an executable system part is called a runtime version. Depending on the complexity and on the fact whether a system under construction will be distributed or not, the system is fragmented into one or more SCM components. These SCM components can be composed to larger SCM components (subsystems) in a hierarchical structure. If a version of the overall software system meets the requirements of the customer it is released and called a software release. While the configuration management of the developers deals with the management of source code files, typically complete executable software systems are delivered to customers in the form of releases. These software systems contain executable components which have been generated from a configuration of source code files. Configuration selection (baselining) is performed by considering dependencies in hierarchies between father nodes and child nodes.

V2 SCM component D E V2 E V1 F V3 F V2 F V1 G V1 A V4 A V3 A V2 A V1 B V2 B V1 C V2 C V1 SCM component H
One characteristic of defining system baselines -by selecting specific atomic CIs and specific component baselines -is that all CIs belonging to a specific configuration have to be selected manually -there are no rules, that verify whether the selected configuration really is a valid configuration that can be built, deployed, and installed, and which is running correctly. Therefore configuration selection (baselining) is still a tough job, despite good tool support.

Configuration verification

Configuration verification uses dependency descriptions (consistency criteria [START_REF] Estublier | Software Configuration Management: A Roadmap[END_REF]) between composed CIs of a SCM component to verify the correctness of a configuration selection. Figure 2 shows dependencies used for configuration verification. Dependencies between composed CIs at the same level of a hierarchy, are used for configuration verification. These dependencies are used to verify whether a set of runtime versions forms a valid configuration. This verification can take place during configuration selection and after configuration selection, e.g., during system installation or at system start-up. Having selected a specific CI the configuration verification can assist configuration selection by suggesting all CIs which can or should be added to the configuration.

Dependencies between atomic CIs (source code level) are not in the scope of this paper. It would be too complex to describe the dependencies between these atomic CIs (source code files, documentation, header files, etc.) to assist configuration selection of a component baseline. The only relevant dependencies between atomic CIs would be those which exist between configuration items located in different SCM components. But these dependencies can also be defined between the composed CIs themselves one level higher in the hierarchy than the atomic CIs.

We distinguish between three types of dependencies used for configuration verification:

• Direct dependencies between runtime versions

• Dependencies between runtime versions by using interfaces

• Dependencies between runtime versions by using contracts

We describe each kind of dependency description in the following subsections.

Direct Dependencies between runtime versions

Runtime versions are composed CIs which are executable system parts. For example, automotive flashware modules are runtime versions. A flashware module can be seen as a piece of code that can be written into the flash memory (a non-volatile memory device) of an ECU. A flashware module can also contain data like a characteristic curve which is required during the execution of an ECU application. Depending on the flash memory of an ECU and the structure of the ECU application, the software of an ECU can be divided into 1 up to n flashware modules. Today, automotive software is distributed over dozens of interconnected ECUs and is either located in ROM (Read-Only-Memory) or in flash memory. Software located in ROM is inseparably connected with the hardware. Consequently, the complete ECU is a composed CI and forms a runtime version.

For each runtime version (e.g. a version of a flashware module) it has to be defined explicitly which other runtime versions it requires to run (see Figure 3).

Figure 3: Dependency description between runtime versions

The challenge is to define for each runtime version -for an automotive example that means for each version of a flashware module -which dependencies with other runtime versions exist. This procedure is not only timeconsuming but is also complex and very error-prone. An additional complexity is introduced by the need to express, if, for example, runtime version C V 1.0 requires A V 5.0 and B V 2.0 or runtime version C V 1.0 requires either A V 5.0 or B V 5.0. Figure 3 shows a possible additional notation to describe the restriction which states that runtime version A V 5.0 is a variant to runtime version B V 2.0 and therefore runtime version C V 1.0 does require just A V 5.0 or B V 2.0. Dependencies between runtime versions based on interfaces make the dependency description between CIs easier and allow a simple and unique notation of variants.

Dependencies between runtime versions by using interfaces

A runtime version can export an interface to indicate which services it provides and can import an interface to indicate which services it requires. An interface contains all call interfaces e.g. all object-oriented method declarations of that methods which are imported or exported, respectively. By using interfaces to describe dependencies between runtime versions it is not necessary that it is separately described by restrictions on which other runtime versions a runtime version is dependent -it is sufficient to declare which kind of runtime A flashware module -which is the typical representation of a runtime version considering automotive softwarecontains only application code and data and does not contain information about the services it provides and the services it requires. But this information can be added for the purpose of configuration management in the form of an additional information to the CI representing a flashware module. The additional information shows the dependency on an (import) interface or the implementation of an (export) interface. The limitation of an interface is, that it does not allow to describe in which order the methods have to be called, nor does it allow to describe which timing constraints should be granted. This limitation can be put behind by using contracts to describe dependencies between runtime versions.

Dependencies between runtime versions using contracts

Contracts provide mechanisms to describe behavioral aspects with the aid of assertions, i.e. pre-and postconditions and invariants (Design by Contract) ( [START_REF] Meyer | Object-Oriented Software Construction[END_REF], [START_REF] Tran | Managed Assertions for Component Contracts[END_REF]). Additional approaches exist to add synchronization and quality of service aspects to contracts [START_REF] Beugnard | Making Component Contracts Aware[END_REF]. A contract defines the rights and duties between the involved parties. A component providing a service guarantees that the post-conditions will be hold if the pre-conditions are fulfilled.

A pre-condition is a condition under which a call of a method is allowed. A post-condition describes the state of the system after the call of a method. The post-condition guarantees that after executing a method the state conforms to certain characteristics, provided that the pre-conditions have been hold before calling the method. Invariants describe certain properties which hold for all methods of a class and not only for individual methods.

If the service user guarantees that the pre-conditions will be fulfilled, the service provider guarantees, that the postconditions will be fulfilled after the service is executed. Then a contract explicitly defines under which conditions a component works correctly. A service user should test in advance, if it is able to fulfill the pre-conditions of the service contract. If this is true, the contract is valid and a valid configuration of components is found.

Configuration update

Configuration update aims to update an installed configuration (a software release) with a new configuration. The first step of updating an out-of-date configuration is to calculate the difference to an up-to-date configuration [START_REF] Hoek | Versioned Software Architecture[END_REF] and to provide instructions for performing the update from the out-of-date configuration to the up-to-date configuration. Consider the following example: software release A with the CIs a, b, c, d, and f is installed in a car and should be updated to configuration B with the CIs b, c, e, and g. The update instructions can be as follows: Delete a, d and f and install e and g, where e may be a new version of d. This additional information can be added to the update instructions and is especially useful in the case where some user defined data of the CI d to be deleted should be transferred to the new version of d which is configuration item e.

The update instructions together with the new CIs (in our example e and g) can be packed into an update package. The update package then contains everything required to update a specific installed configuration to a new configuration.

The second task of configuration update is to perform the update instructions. This can either be done during nonoperation (see section 2.3.1) or during operation (see section 2.3.2) of a system. Configuration update while a system is running is also known as dynamic change management and is additionally used for the migration of entities at runtime. In contrast to a runtime version which represents executable code such as flashware modules or software components an entity exists only at runtime. Typically an entity is instantiated from a runtime version. For example an entity (object, instance) is instantiated from a class file which represents a runtime version.

Updating configurations only during non-operation of the system

A configuration of a system can be updated safely, if the system is non-operating. The update package containing the new CIs and the instructions is unpacked and the instructions are executed. Before the update instructions are executed it has to be ensured, that the currently installed configuration is identical with the configuration the update package is generated for. Additionally it is important, that all update instructions are executed completely and correctly to gain a valid configuration and a correctly running system. An example of updating configurations during non-operation can be found in automotive industry. Flashware modules can be exchanged during the vehicle's lifetime e.g. in order to remove errors. These flashware modules can be only exchanged in a workshop during a vehicle diagnosis session. Then, the car is non-driving and therefore its systems are not normally operating but vehicle diagnosis can take place in this special system mode.

Dynamic change management

If there is a dependency between runtime versions as described in section 2.2.1, 2.2.2, and 2.2.3 the entities of these runtime versions can interact at runtime. Changing one interacting entity can lead to inconsistencies to all entities that are involved in the interaction. Examples for changes are the migration of an entity to a new environment (e.g. to balance load) as well as the update of an entity. For instance, if the entity is realized as a software component that consists of a set of objects, it can be dynamically updated by exchanging some old objects with new ones. However, what shall happen with the local variables of an obsolete method that are stored in the execution stack of the runtime environment? Which instruction shall be executed, if the instruction that is pointed from the instruction pointer of the runtime environment is no more existing? Familiar dynamic update management approaches ( [START_REF] Chen | Extending RMI to support dynamic reconfiguration of distributed systems[END_REF], [START_REF] Kramer | The evolving philosophers problem: Dynamic change management[END_REF]) avoid the dealing with these questions, because they prevent the changing of an interacting entity. Then, this update management is responsible for the monitoring of this prevention: Only operable entities are allowed to interact. Only non-interacting entities are allowed to become non-operable in order to get changed.

The concepts of dynamic change management (that includes dynamic update management) are relevant for managing long running, non-interruptible programs. For instance, such kind of programs run in satellites. However, for automotive software the update management in non-operational state is more interesting, because the vehicle's software running is interrupted at every drive break.

Concepts for configuration management of automotive software

In this section we apply the introduced basic concepts for configuration selection, configuration verification and configuration update to the management of automotive software and show a way to an efficient configuration management. The next subsection describes an evolution from an implicit to an explicit configuration management of automotive software.

From implicit to explicit configuration management

For managing the configurations of small systems, which consist of only a few software modules, it is sufficient to consider points in time where old runtime versions are replaced by new runtime versions. For example, if there is a new runtime version replacing an old one with the same functionality it is deployed to a specific server and made available for end-of-line production. Henceforth, the new runtime version is used in end-of-line production. Such a point-in-time-related configuration selection has the following consequence: Every time, once new runtime versions are deployed, vehicles with identical functionality will have a different configuration from vehicles manufactured before this point in time. If the number of configuration items to be managed is not very high and if no configuration update is performed over the lifecycle of a car, such an implicit configuration selection will be sufficient (see the bottom left quadrant in Figure 5). If software is exchangeable over the lifecycle of a car -for example in workshops where some flashware modules but also whole ECUs have to be exchanged because of damage, corrective maintenance or because of new functionality is ordered -it has to be verified which flashware modules/ECUs have to be exchanged additionally to get a valid configuration again. Consider the following example: In the case an ECU is damaged the complete ECU will be exchanged. If the old version of the ECU is no longer available an ECU with a newer version will be mounted. In this case it has to be ensured that the software within this ECU is still compatible with the software in the other ECUs. To solve this problem dependencies between runtime versions can be introduced. These dependencies describe which runtime version requires which other runtime versions and can be used in the workshops to verify if a configuration is still valid when a runtime version should be added or exchanged. By this way configuration verification is introduced using direct dependencies between runtime versions (see the upper left quadrant in Figure 5). To make the dependency description between runtime versions easier and more reliable interfaces or contracts can be introduced between runtime versions.

A further step is to introduce an explicit configuration selection. That means, valid software releases are defined explicitly. By this step the number of configurations which can be built into a car can be limited and a configuration verification has only to be executed during the configuration selection, when a new software release is defined. The number of distinct configurations built into vehicles can be limited, because only predefined software releases are allowed to be built or installed in a car and consequently only updates to predefined software and hardware releases are allowed. Possible other configurations which may be also valid considering the dependency descriptions are not allowed. In very large and distributed systems it is highly recommendable to reduce the delivered configurations by an explicit configuration selection in order to reduce possible sources of errors (see the right quadrant in Figure 5).

The explicit definition of software releases is also advantageous to perform updates. In the case it is known which software release is installed and to which software release an update should be performed, the difference between the installed configuration and the new configuration can be calculated and an update package can be automatically generated. This makes configuration update very efficient, because no configuration verification is required to perform an update of a configuration. If different parties or the customers themselves are allowed to install software on a single platform, it is not possible to easy determine which software release is installed. But if only one authority is allowed to manipulate a system it can be known in advance or easy determined which software release is inside a car.

The continuously increasing software volume in vehicles and the possibility to exchange software in vehicles over their lifetime requires an explicit configuration selection and the definition of dependencies based on interfaces or contracts to assist configuration selection. Furthermore the explicit configuration selection enables an efficient configuration update.

Prototypical realization of configuration management

In this section we discuss a configuration model in which automotive hardware and software releases are defined. This configuration model is used in a prototype to realize an efficient update management for automotive software.

Configuration model for automotive software

In section 2.1 we only discussed software-related CI (e.g. runtime versions). In this section we additionally introduce ECUs as hardware-related CI. A configuration of software-related CIs which is released is called a software release and a configuration of hardware-related CIs which is released is called a hardware release. In this section we introduce a configuration model in the form of an Entity Relationship Model (ERM). This configuration model defines automotive software and hardware releases (see Figure 6). Specific to automotive software is that the software is either located in ROM or in flash memory. As discussed in section 2.2.1, software located in ROM is inseparably connected with the hardware. This is the reason why in Figure 6 an ECU hosts 0 up to n flashware modules. Zero holds where the ECU software is located in ROM and 1 up to n holds where the software is located in flash memory. Vice versa one flashware module is executable in 1 up to n ECUs. Typically a flashware module can only be executed in exactly that hardware it is compiled for. But if there are two devices with changes in hardware that do not influence the controller architecture it is possible to have two distinct ECUs which are able to execute the same flashware modules.

Coding values are used to activate or deactivate a functionality which is implemented in a flashware module. That means if a specific functionality is not ordered by a customer it might just be deactivated by a specific coding value. These coding values are used, for example, in end-of-line programming or in workshops to adjust the ECU software to reflect the ordered functionality. A flashware module can be configured by 0 up to n coding values and vice versa a coding value can be used for the configuration of 1 up to n flashware modules.

A hardware release consists of n ECUs and a software release consists of flashware modules and corresponding coding values. The relationship between software releases and hardware releases describes which software release is executable on which hardware release. This is a relevant information for updating automotive software without exchanging hardware. This means a remote update of a software release is only possible, if the new software release is executable at the same hardware.

The discussed configuration model explicitly defines software and hardware releases and forms the basis for an update management which is implemented in a prototype and discussed in the next section.

Prototype

We implemented a prototype which enables the download and installation of new software releases into cars to maintain the car's software over its lifetime. The architecture of the prototype allows the transport of update packages to the car over various media as shown in The release management has to protocol which software release is installed in which vehicle and the update management has to calculate the difference between a new software release which has been assigned to a vehicle and the currently installed software release. An update package is generated consisting of flashware modules encapsulated in container constructs. In our prototype we used OSGi bundles as container constructs. These containers will be transferred to the vehicle, unpacked and the content -the flashware modules -will be installed in the destination ECUs.

Outlook: Towards an efficient configuration selection

For explicit configuration selection of large or/and distributed systems hierarchies are typically introduced according to section 2.1. If we consider distributed systems, the hierarchies are build by physical aspects. That means runtime versions (e.g. flashware modules) are composed to subsystems (e.g. ECUs), these subsystems are composed to larger subsystems (e.g. all ECUs connected to a vehicle sub-network). This cascading principle continues until the complete system is assembled. By introducing such hierarchies the complexity of configuration selection can be reduced significantly and each subsystem can be tested separately. This principle cannot be assigned to configuration management of automotive software straightforwardly.

Configuration management of automotive software has to consider that customers can choose within each production series from a large amount of optional equipment (the so-called features). Different features such as radar-assisted cruise control, heated front seats, etc., lead to different software releases. Consider the following example: When ordering a car, a customer has the option to equip the chosen vehicle with 0 up to 20 optional equipment features such as radar-assisted cruise control, heated front seats, Keyless-Go (the car can be unlocked without a key by carrying a chip card in the pocket and can be started by pressing a button), Teleaid (automatic call for help when an accident happens), etc.. Therefore, our customer has 2 20 (more than one million) possibilities to order a new car of a given production series. This also implies that more than one million software releases have to be defined, tested, and maintained.

In addition to variants which can be selected by the customer, there are further variants to consider, for example country variants. In the case of country variants, the look and feel (e. g. for a navigation system) as well as the hardware used can change dependent on the delivery market.

A customer selectable feature may require various CIs in different subsystems. As a consequence, for each subsystem containing a CI which is required for the feature, a variant has to be defined. If a lot of optional equipment features require CIs located in different subsystems a lot of variants of each subsystem have to be defined and tested. By this way the advantages of decomposing a system hierarchically into subsystems decrease and it seems to be more suitable to define software releases for the individual features.

In future work, we will tackle the challenging question whether runtime versions of automotive software should be decomposed into subsystems in a hierarchical manner or whether software releases for individual features should be defined or whether a combination of both is most suitable.

Summary

In this paper, we discussed configuration management with respect to configuration selection, configuration verification and configuration update. Explicit configuration selection reduces the number of configurations used in the cars due to the limited number of releases. Configuration verification uses either explicit or implicit dependencies between runtime versions, where implicit dependencies are specified by interfaces or contracts. Configuration verification is required if the number of configuration items is very high or a configuration update is performed during the lifecycle of a vehicle. If configuration selection is performed explicitly it is sufficient to execute a configuration verification during configuration selection. Moreover, configuration update profits from an explicit configuration selection -it can be performed efficiently by calculating the difference of the currently installed and the new software release. Update packages containing update instructions and runtime versions to be installed are generated automatically in order to be loaded into the car. These update packages will be installed by executing the associated update instructions. An OSGi-based prototype implementing such an efficient configuration update for automotive software has been discussed. Software and hardware releases are defined in a configuration model and update packages consisting of OSGi-bundles are generated automatically. OSGi-bundles are loaded into the car and the flashware modules encapsulated in the bundles are installed in the destination ECUs.

Figure 1

 1 Figure 1 shows a hierarchical structure of CIs. The atomic CIs (A V1, ..., A V4, B V1, B V2, C V1, C V2, E V1, E V2, F V1, ..., F V3, G V1) are grouped in two SCM components D and H. A SCM component consists of a tuple of CIs.

D

Figure 1 :

 1 Figure 1: A system baseline made up of component baselines For the SCM component D (A V1, ..., A V4, B V1, B V2, C V1, C V2), the component baselines D V1 (A V2, B V2) and D V2 (A V4, B V2, C V2) are defined, and for SCM component H (E V1, E V2, F V1, ..., F V3, G V1) the component baseline H V1 (E V2, F V2) is defined. Different versions of a SCM component (component baseline) are represented by different tuples. Two tuples are different, if they contain different combinations of CIs. A CI is a version of a node -in case of software a node is represented by a file. For example, the CIs (A V1, A V2, A V3, A V4) are different versions of a single file. Typically, a baseline contains just one distinct version of a file.

Figure 2 :

 2 Figure 2: Dependencies used for configuration verification

Figure 4 :

 4 Figure 4: Dependency descriptions based on interfaces Figure 4 shows a runtime version C which depends on (requires) a runtime version which implements interface X, version 1.0. Two runtime versions (A and B) implement interface X, version 1.0. Compared to an dependency description based on runtime versions this way of describing dependencies is much easier, because no knowledge about the specific runtime versions A and B is necessary. A further advantage: if a runtime version is added which also implements interface X, version 1.0, no additional dependency description has to be added to runtime version C.

Figure 5 :

 5 Figure 5: Relevance of configuration verification and configuration selection

Figure 6 :

 6 Figure 6: ERM for the definition of automotive software and hardware releases

Figure 7 :

 7 Transport may occur by wireless links such as GSM, GPRS, UMTS, or DAB directly out of the infrastructure, by wired links in a workshop, by wireless links such as Bluetooth or WLAN from a flashware access point (maybe also in a workshop), or via portable media such as CD-ROM or USB memory stick. The main components at the vehicle side -the Flashware-Reprogramming-Controller and the Installation-Configuration-Controller run within an OSGi-Service-Gateway (a compact component framework). The Flashware-Reprogramming-Controller contains the (re)programming logic to install flashware modules in ECUs connected to the various subnetworks and the Installation-Configuration-Controller is the vehicle side part of the update management. This component is responsible for executing the update instructions of an downloaded update package and for controlling the installation procedure. We present in[START_REF] Heinisch | Loading flashware from external interfaces such as CD-ROM or W-LAN and programming ECUs by an on-board SW-component[END_REF] a comprehensive description of those components and the architecture at the vehicle side.GSM, GPRS, UMTS,

Figure 7 :

 7 Figure 7: Main components of a software download architecture

  (Common Object Request Broker Architecture)[11] is a well-known example of a component-based system. The Object Management Group published the first standard for CORBA in 1991. In component-based systems, components publish their export interfaces (services) in a registry and use it to ask for an import service they require. Components typically run in the context of a framework, which may be distributed and which provides a runtime environment for software components. Another component framework which is more relevant for automotive applications is specified by OSGi (Open Service Gateway Initiative)[12]. Component frameworks as specified by CORBA or by OSGi use dependency descriptions based on interfaces to set up a complete running system. Nowadays, component frameworks can be found in cars of the luxury class. There, a powerful telematics ECU has the resources to integrate a component framework like OSGi. Software components that implement, for example, navigation based services can be loaded, installed, started, stopped and uninstalled dynamically.

version, i.e. which interface it requires. A runtime version which defines what is required and what is provided by the usage of interfaces can be called a software component. CORBA

-22 -23 January 2004

Acknowledgement

We would like to thank the master students Ralf Lohrmann, Qinghua Cheng and Volker Kugler for valuable discussions as well as our colleagues from Mercedes-Benz PKW Development and the Center for Diagnosis and Flash Technologies and in particular Prof. Dr. Wolfgang Rosenstiel of the University Tübingen and Prof. Dr. Joachim Goll of the University of Applied Science Esslingen.


Agusti Canals

Stéphane Lelièvre

Stéphane Lelièvre Tools

Tools collaboration for deployment of a requirements engineering process

Requirements Engineering vs Requirements Traceability

The first steps of the system and requirements engineering phases of any project are to define the management aspects (management plan, requirements engineering process, schedule management) and the project specifications, in the widest sense: collection, analysis and synthesis of the need expressions from all stakeholders, and definition of requirements to express this need. Then requirements will be allocated, changed, re-organized, and tracked during all the project lifecycle.

So the first priority is to have a process, even a simple one, then it's helpful to have this process supported by tools. A good process, even manual, is better than tools used without any process.

As there is often a confusion there, it seems important to distinguish 2 steps in a requirements management process :

• Requirements elicitation, identification and allocation : For this step there are a lot of publications, feedbacks and studies.

These requirements are usually formalized in 'Specifications' documents for the development teams or the subcontractors, • Once formalized, the requirements have to be implemented and tested by the hardware and software development teams. This is the 'requirements traceability'.

Requirements and implementation artefacts often change, and the impact of each change must be analyzed.

Solutions currently used by CS

For several years, the process used by CS to manage requirements was the following one : Each development tool included in the project development cycle is completed by a set of macros or scripts allowing input data traceability. The documentation produced by each development tool is stored in a repository (in our case the database of DOORS TM , the very well known tool provided by Telelogic). The import/export functions allow to extract traceability information from the input documents, store and manage it in a database, perform impact analysis and build traceability matrices.

This CS instrumented process was used by the project development teams, but also by the teams answering to invitations to tender. So this process was supposed to be used during the 2 majors steps defined above : requirements capture and definition, then traceability and impact analysis. We used only DOORS TM to support this approach.

Widely involved in the Airbus A380 program, CS also used REQTIFY TM , from TNI-Valiosys, for the A380 software projects. CS also selected REQTIFY TM for other Aerospace and Automotive projects. REQTIFY TM is a simple, easy to handle and easy to deploy tool that needs formalized requirements as inputs, then provides requirements traceability, bi-directional impact analysis and documentation generation. So, as several large groups today, we have 2 tools involved in our requirements management process : DOORS TM from Telelogic and REQTIFY TM from TNI-Valiosys.

Tools positioning analysis

Instead of defining a competition for the selection of only one tool for the group, we decided to analyze their real positioning in order to get the maximal added value from each tool and then to see what was the best approach :

• DOORS TM is very efficient to manage the requirements in the high-level system design phases, where several teams are discussing the customer need, what are the requirements,… At this level it is necessary to centralize the discussions in a database, manage change proposals about requirements definition (with the DOORS TM CPS -Change Proposal System).

The center of interest is the requirements definition, the center of the tool is the database, it's so consistent. The outputs of this approach are some formalized "Requirements documents", used as inputs for the next development steps. • For the development and tests phases, the use of DOORS TM was possible only thanks to more or less accurate internally developed macros and/or interfaces with the tools used during development. But we think that it's not the most effective way to use DOORS TM , for a very simple reason : the center of interest is no more the requirements definition, but their implementation and tests, which is disseminated across various development and test tools. It may be complex and expensive to try to centralize these artefacts in a database. The risk is to make the tool rejected by the development teams, but if the real problem would not be the tool but the way to use it. • REQTIFY TM is very efficient for development and tests teams receiving formalized specifications documents as inputs, outputs of a manual work for small projects or of a work supported by DOORS TM for larger projects. REQTIFY TM is provided including interfaces with various tools. But REQTIFY TM itself can't manage collaborative definition of highlevel requirements or system requirements. Its added value starts once the requirements have been defined, not before.

An original 2 tools based approach to maximize the added value

Following the positioning analysis, we concluded that the maximal added value is in the collaboration between these 2 tools instead of in a competition. This 2 tools based approach is described below :

• At system level the multi-team need analysis is centralized in a database, requirements are discussed, optimised with rigorous change decision process, upto their integration in one or several specifications documents. Clearly, this is not the positioning of REQTIFY TM , and this need is perfectly addressed by DOORS TM , • REQTIFY TM is used as soon as the specifications are produced, to capture requirements in documents and manage them across the whole development lifecycle for software.

Important note : Requirements can be captured directly in the database, but as teams usually work through document exchanges, such a direct import between tools creates a second channel and this duplication must be managed. If not, it must be preferred to keep the same reference as project teams, meaning specifications documents themselves,

• REQTIFY TM then manages requirements implementation and tests during all the development process, and provides coverage analysis, impact analysis of a change at any level and various reports. Results can be produced in a documentation format (Word, HTML,…) or directly inserted in the DOORS TM database for analysis by the system engineers.

A very important point is that the insertion of REQTIFY TM in our process was possible without any modification : neither of our requirements management approach nor of the work performed at high level with DOORS TM :

Such an approach has several major benefits :

• DOORS TM is used for its maximum added value, widely recognized and presented : requirements definition in a widely collaborative and iterative way,

• We provide development teams with REQTIFY TM as a light and efficient solution, more external than a database-based one, keeping the focus on the implementation, for traceability and impact analysis. As it has been designed for these tasks, REQTIFY TM offers a very pleasant user-interface to navigate in the traceability graph, • By solving our compatibility and interface problems (versions of various used tools), REQTIFY TM allows us to replace more and more macros and scripts by only one tool, supported by its editor. A simple 'Save' action leads REQTIFY TM to update the traceability analysis results, there's no need to synchronise the files or models with a database, • Each tool is a well-accepted solution at the appropriate level. This acceptance allows to widely deploy the requirements engineering process : This process, initially supported and defined with DOORS TM , is not modified by REQTIFY TM as this tool needs such a definition as input, • DOORS TM requirements can be easily captured by REQTIFY TM for development teams, and REQTIFY TM analysis results can be provided to DOORS TM in order to give a good view of the system implementation to the system engineers, using DOORS TM , • The global cost is much lower : the overall purchase cost of REQTIFY TM is lower, the training is very short and its administration is very simple as there's no database, • Most of all, this 2 tools based approach is an effective and economical solution to make the development teams play the game of the requirements management process.

As already said, this CS instrumented process is used by the project development teams, but also by the teams answering invitations to tender, or request for proposals. We also plan to combine the capabilities of each tool in order to choose the most efficient approach, but the general way should be :

• To use REQTIFY TM to generate the coverage matrix showing the compliance with the customer requirements, as it takes only a few minutes to customize the tool according to the requirements syntax. Of course DOORS TM will still be used for some proposals where it is the most adapted. • Once the business is secured, to use the DOORS TM and REQTIFY TM collaboration, or only one of these tools depending on the project context.

We also think that REQTIFY TM can be used even when subcontracting with a customer using DOORS TM , but we still have to confirm this view in real-size projects.

Beyond the CS experience

This approach based on the collaboration between a database based tool (DOORS TM but also RTM TM from Integrated Chipware, or CORE TM ,…) and a file-centric tool (REQTIFY TM ) can be extended in a very general way to a wide range of developments, including both Software and Hardware (FPGA, Electronic Boards) developments. So it can be a good answer to a wide range of problems not solved by the use of only one tool for all the process steps. Let's just take 2 examples among a lot of others :

• Hardware design : today a recent and very demanding standard has to be applied for Hardware in Aeronautics : the DO254 standard, equivalent of what is the DO178B for Software. Even for mature requirements engineering process, applying it across the Hardware design should be more easily accepted and easier to deploy with a file-centric tool than with a database based tool (does it make sense to import hundreds of VHDL files and test benches in a database ?) . • As a matter of fact, engineers live in a document-oriented world : Today's projects need to be very reactive and leave no place for the implementation of a bad requirement, or for a change realized without impact analysis. The document-based work generates a high risk of redundancy and/or non-synchronisation with a database. A 'file-centric' tool is a good solution for managing what is effectively in the documents.

The global process could so be presented as below :

Conclusion : Perspectives and reuse of CS experience

For requirements management, the process is the priority. Tools are only there to support this process as effectively as possible. Today, we consider that this 2 tools based approach is the most effective one for large groups, from both technical and cost points of view. It can be applied to software and hardware designs. It should also be the unique solution to support the deployment of recent demanding standards as DO254 for Hardware in Aeronautics, and is a good way to avoid redundancy in some document-oriented projects.

CS used DOORS TM and REQTIFY TM individually in various contexts, and is now deploying a 2 tools based approach described above. We consider there is a higher value in a collaboration rather than in the selection of only one tool after a competition.

As a consulting company, CS considers that this experience can help major groups looking for an effective solution to support their requirements engineering process, in Aerospace, Automotive, Industrial and other markets.

References :

[Air&Cosmos] '

About CS

CS is a major player in the market for integrating and running industrial and scientific applications and secure infrastructure services.

CS is firmly positioned at the top of its industry, ranking second in France for industrial and scientific applications and third in computing infrastructure services. CS assists its customers over the long term by providing solutions that are ideally suited to their needs and resources.

Its expertise and its corporate culture based on commitment and innovation have been rewarded with contracts to manage large, complex projects in a number of fields. For example, CS has been awarded substantial contracts by the Délégation Générale pour l'Armement (DGA), France's arms agency. DGA contracts have included the €158 million CLA 2000 project to renovate the air force's local air traffic control system and the €146 million SRSA project to develop an air-to-ground communication system, also for the French air force.

CS is also a technology partner for Airbus and its embedded software suppliers, Société Générale's preferred supplier for distributed systems administration, the service operator for Renater 3, the French research community's national telecommunications network, and the project manager for the future banking services network in France.

Today CS is regarded as an established service provider by its major customers, which have remained loyal for 20 years because of its employees' expertise, commitment and customer service focus.

  is a software engineer (Université Paul SABATIER, Toulouse) and has been working at CS since 1981. Now project manager and senior software engineering consultant, he has already presented papers on HOOD, Ada, UML and object business patterns. He also currently teaches software engineering in different training structures, like Ecole Centrale Paris, Paris Dauphine or Université Paul Sabatier (Toulouse).

-22 -23 January 2004

-22 -23 January 2004Stephane Lelievre is a software engineer (EERIE -Nîmes) and has been working at CS since 1998. Now project manager and software engineering consultant, he has deployed new software development process based upon generated code from models and traceability with REQTIFY TM .


Marion Sperle
email: marion.sperle@siemens.com

Keywords: Process, Methods, CMMI, best practices, business goals, process improvement, requirements engineering, project planning, architecture

During her studies she worked at Siemens Information and Communication developing public network systems. At Taurus GmbH and Vereinsbank she developed application systems with graphical user interfaces and database applications.

Since 1998 she works as senior consultant at the Siemens AG within the unit Corporate Technology, Software and Engineering Processes. Her main tasks are leading CMMI-based process assessments and leading CMMI-based process improvement projects

The article shows the benefit of systematic processes for the development of embedded systems. Based on the example of automotive supplier business, it shows some important factors that should be considered in processes to be efficient (chapter 2.1 and 2.2), the impact of the factors on the processes and how these factors can be considered in the processes (chapter 2.3).

Introduction

In the automotive business the variety of features is increasing constantly and they are increasingly implemented as embedded software.

The SW projects increase dramatically fast (up to 30% of the vehicle cost in 2002 will be electronics, Financial Times automotive report by Eric Harkness). The German research and prognosis institute "Marketing Systems" has evaluated in 2000 that 40% of all automotive suppliers are in risk as their rate of return is below 1 percent. So they are forced to increase their productivity. The article talked about possible savings of multiple millions of Euros by increasing the quality of planning (Handelsblatt, 5 th april 2000).

Increasing productivity and reducing problems with a simultaneous dramatic increase of the complexity of projects and involvement of multiple disciplines requires systematic and efficient processes.

Why systematic and efficient processes?

Experiences of companies world-wide show that productivity and quality can be increased significantly by improved descriptions and implementation of the proceeding in development (development processes).

The following table (figure 1) about changes through Software Process Improvement (SPI) shows an interesting benefit (an investigation done by the Software Engineering Institute (SEI) of the Carnegie Mellon University in 1994). 2 How can a process become systematic and efficient?

Category

Range

Common success factors

There are some common success factors for process improvement. Similar to other projects, process improvement needs realistic and measurable goals and a strict monitoring and controlling to become successful. Changes in processes means changes in behavior of people and this needs special attention. It is important to motivate the people to change their behaviors (e.g. to show the reasons for changes, periodic communication of benefit, reward, ...). A clear and periodic communication of the goals, the planning and the progress for instance supports the continuity of process improvement. Additionally the management needs to support the changes in the process, for instance in recognizing that changes in the beginning need time and investments.

As process improvement has impact on all the staff, it should follow a systematic way to assure a certain quality. Proceeding this way can be compared to a product development process: to analyze the requirements, to plan the development of the process, to develop a design/structure of the process, to assure its quality, to manage the process items and their versions, to test the process before releasing it and so on. These steps can be implemented as follows for process improvement:

• An example for analyzing the requirements of a process will be shown later in the article.

• It will not only be helpful but necessary if the process will be described simultaneously by different groups, to describe the structure of the process. The structure should describe what process areas will be affected, what topics are covered by what process areas and how the interfaces between the process areas are defined. This is similar to the architecture of a software program. The management of the items supporting the process (process descriptions, intranet pages, templates, slides, etc.) and their versions will be based on the process structure. • To assure the quality of the process different methods can be implemented. A well-known one is a systematic review of the process items by experts. The advantage is that it can be used already during the definition of the process. • By piloting the process in some representative projects before releasing it for the whole organization, the process can be tested if it is easy to use, consistent and fitting to the needs of your organization. • An assessment of the process helps to analyze gaps in your process definition or in your process implementation by mapping it to a process model that was developed by using the experience of many different organization (e.g. the process model CMMI of the SEI) and by considering the influences of your organization and your business.

The proceeding for Process improvement can be seen in figure 3:

Business analysis example

An analysis of your business and your business goals is a part of the requirements of your process: What are the specifics of your business? What do you want to improve? What topics influence your business and your business goals? What factors influence the topics to be improved? With this knowledge you will be able to design a well-fitting process for your organization that will support your business and your staff.

Referring to the article of "Marketing Systems" in the year 2000, it shows that automotive business needs to improve the productivity and the quality of planning. Both strongly depend on the specifics of the business. The goals of car manufacturers are also influencing their suppliers.

The assessment -improvement cycle

Re-Assessment

Improvement

Juni Jul i

Phase III: Piloting

Phase II: Process-Definition Phase IV: org. wide use

Controlling

ASSESSMENT 1st Assessment

This chapter shows exemplarily how business analysis works as a basis for process definition by using the example automotive supplier business.

Automotive supplier business has a lot of specifics. These specifics must be considered in process definition. To give you an idea how the specifics have impact on the processes it is enough to look at some of the most specific:

1) Personal cars are mass-products.

2) The products are evolving a lot since 100 years, and have a lot of features and requirements.

3) More and more features are developed as embedded systems using standard hardware and software as well as specific hardware and software.

4) Most of the features have to fulfill real-time conditions.

5) The products often have different variants, e.g. low-budget vs. luxury cars, country-specific variants.

6) Often features are based on former products.

7) A lot of the features of vehicles are safety-relevant.

8) There are really hard target dates (SOP).

9) The products are composed of multiple disciplines (hardware, software, mechanics, etc.) .

10) Sometimes suppliers deliver a whole system (e.g. an airbag system), sometimes they deliver only a part of a system (e.g. only an airbag processor).

How to react on these multiple constraints of the automotive supplier business in the processes ?

The following description shows some parts of processes that have to be defined or adapted in order to meet the business goals and business specifics analyzed above.

Ad 1) As personal cars are mass products the process should define how the purchase, the stock management, the tests before production etc. can be optimized. Be aware that these process areas have impact on the development and on the production, e.g. when a cheaper standard hardware may not support some features, the development has to react on it. 21 -22 -23 January 2004

-> mainly influence to the business goal productivity. -> mainly influence to the business goal quality of product.

Ad 2, 5 and 6) As cars are existing since more than 100 years they have evolved significantly. Nowadays thousands of features are implemented and often a feature is evolving from product to product. That means that a requirement is implemented in different parts of a product and may use parts of former products.

Additionally a feature may have different variants, for instance it needs some country-specific adaptations or adjustments to different budgets (low-budget, luxury).

This requires a good structure of the requirements. You need to be able to trace the requirements throughout the whole product lifecycle in order to be able to answer the following: what requirements are depending others, where are they implemented, what impact has a change on the requirements and on the product components, are all requirements implemented, etc.. Consequently you need a stable change management and a consistent version management to be able to put together all the needed product components and the right version of them.

-> mainly influence to the business goals quality of planning and quality of product.

Ad 7) Safety relevant features of a product need special and intensive treatment. The safety relevance can be categorized depending on the impact of a malfunction of a feature (SIL-safety integrity levels). According to these levels different methods should be used. The safetyrelevant parts of a feature have to be separated from non-safety relevant parts, and this throughout the whole product lifecycle: it has to be indicated if a requirement is safety-relevant, safety-relevant parts should be implemented in separated product parts, safety-relevant parts should be tested intensively according their SIL, and so on.

-> mainly influence to the business goal quality of product.

Ad 8) In order to meet the hard target dates you need a good planning considering all the risks of the project and defining mitigation strategies and a tough monitoring and controlling procedure. As projects in the automotive business generally are long-term projects (2 years) it is important to define several deliveries in order to be able to assess the progress. Additionally to the deliveries requested by the customer, you should define internal synchronization points, e.g. internal deliveries and releases. These synchronization points facilitate regular monitoring of the progress against the planning and the controlling of the technical consistency of the product components. 21 -22 -23 January 2004

-> mainly influence to the business goal quality of planning.

Ad 3 and 9) Most of the features are implemented in software embedded in specific as well as standard hardware. Additionally "Standard Software", e.g. a communication bus system, is integrated in the product.

The product architecture has to reflect on these aspects taking into account that the standard hardware and the integrated standard software may change from project to project or even within a project. Defining different product layers with only one hardware dependent one, might reduce effort when hardware changes. Testing must also be prepared to changes in hardware and software.

As many disciplines are involved, it is very important that the process defines the system engineering: how all the disciplines will develop consistently and in a synchronized manner. It has to assure that the different components will fit together (technical interfaces) and will be developed at the right time (synchronization points). But be aware that this kind of synchronization will affect the whole product lifecycle, e.g.:

• the decision what requirement will be implemented by what discipline

• how the product architecture looks like

• when tests will be done separately and when with the integrated product. A simulation environment would be helpful to recognize the defects as early as possible, in order to be able to test the software even before the specific hardware is realized. • last-but-not-least when spare parts production requires input from the different disciplines. -> mainly influence to the business goals quality of planning and quality of product and productivity.

Ad 10) When only a part of a whole system is developed by an organization the technical interfaces and time constraints are of very important. They have to be well-defined to ensure that the components coming from different suppliers are working correctly together. Contract Management, Requirements Engineering and Testing will be very important.

-> mainly influence to the business goals quality of planning and quality of product.

At least all these aspects (and many others) have to be considered in a process for an automotive supplier organization.

Figure 4 shows exemplary the process areas that have influence on 3 business goals:

  21 -22 -23 January 2004Abstract:

Figure 1 :Figure 2

 12 Figure 1: An investigation about changes through Software Process Improvement

Figure 3 :

 3 Figure 3: The proceeding of Process Improvement

  . 30. 05. 06. 06. 13. 06. 20. 06. 27. 06. 04. 07. 11. 07. 18. 07. 25. 07.

Ad 4 )

 4 The real-time conditions of automotive features should be considered for instance in the requirements, the architecture and the test of the components. In order to facilitate the consideration of real-time conditions during the development they should be described already in the requirements. It is important to analyze what components may consume what amount of time and what situation may have impact on the time conditions of the system. The real-time constraints should be tested as early as possible.

Nr. of organi- zational data points Detailed data per organization

	Years engaged in SPI	1-9	13
	Yearly Cost of SPI per	$490 -$2004	5	SPI-years : $
	Software Engineer			6:2004; 2:490; 6:858; 3,5:1619; 2:1375
	Productivity Gain per Year	9 -67 %	4	SPI-years: (LOC/unit of time in %):
				3:9; 1: 67; 4:58; 5:12
	Early Defect Detection Gain per Year	6-25 %	3	SPI-years: (Defects detected early in %) 9:6; 5:25; 3,5:22
	Yearly Reduction in Time-to-Market	15-23%	2	SPI-years: (development time reduction per year in %): 3:15; 6:23
	Yearly Reduction in Post-Release Defect Reports	10-94 %	5	SPI-years: (defect reports reduction per year in %) 9:39 / 1,5:94 / 1:70 / 3,5:10 / 3,5:11
	Business Value (Savings/Cost of SPI)	4:1 -8:1	5	SPI-years: (business value ratio) 3,5:4,0 / 6:5,0 / 6:4,2 / 5:6,4 / 3,5:8,8
	Investigation by SEI, Carnegie Mellon University (CMU), USA, at 13 organizations
	(e.g. Bull HN, GTE Government Systems, HP, Motorola, Siemens Stromberg Carlson, Texas Instruments, …)

Some main steps of Process Improvement Process

	Q ual i t y Assurance Q ual i t y Assurance
	C onf i gurat i on and versi on m anagem ent C onf i gurat i on and versi on m anagem ent
	Process St ruct uri ng Process St ruct uri ng
	Process Test Process Test

R equi rem ent s anal ysi s R equi rem ent s anal ysi s Pl anni ng and M oni t ori ng and C ont rol l i ng (i ncl udi ng C om m uni cat i on and M ot i vat i on) Pl anni ng and M oni t ori ng and C ont rol l i ng (i ncl udi ng C om m uni cat i on and M ot i vat i on) Process D ef i ni t i on Process D ef i ni t i on

-22 -23 January 2004

Process Improvement: process is a factor influencing multiple business goals All the given examples explain that processes, especially development processes, have to be adapted to your business and your business goals in order to define a useful, easy-to-use, supporting and feasible process.

Main steps of a successful process improvement are the analysis of your business, your business goals and your organization. These analyses will show you the requirements of your process. The structure of the process shows the process topics to be treated, where they will be treated and how they interfere. The interfaces of the process areas should be considered well.

An appropriate common process model, for instance the CMMI of the Software Engineering Institute of the Carnegie Mellon Institute can support you performing these tasks and additionally gives you a good and well-experienced means to assess your processes regularly.