Bosch Experience Report - Semantic Scholar · The Bosch Experiment Experience Report documents the insights gained by Bosch through applying the ConIPF methodology in the Bosch Car

Bosch Experience Report

John MacGregor

Version: 1.0

Document Information

Project Number: IST-2001-34438

Project Acronym: ConIPF

Workpackage: WP3- Bosch Experiment

Deliverable Number: D3.3.3 / D3.4.2 / D3.5

Distribution: Public

Document Title Bosch Experience Report

Authors: John MacGregor Bosch

Abstract:This document combines the general experience report,, the methodology introduction experiencereport and the experiment results

KeywordsBosch Experiment Experience Report

ConIPF (Configuration of Industrial Product Families) is a join research project composed of the following members:

Robert Bosch GmbH (Bosch),Germany

Thales Nederland B.V. (Thales),NetherlandsRijksuniversiteit Groningen (RuG), NetherlandsUniversität Hamburg (LKI)Germany

Table of Contents

1 Executive Summary......................................................................................................................... 1

2 Preface..............................................................................................................................................22.1 Purpose..................................................................................................................................... 22.2 Scope........................................................................................................................................ 22.3 Definitions, Acronyms and Abbreviations...............................................................................22.4 References................................................................................................................................ 32.5 Overview.................................................................................................................................. 3

3 Introduction...................................................................................................................................... 53.1 Purpose..................................................................................................................................... 53.2 Organisational Context.............................................................................................................53.3 Technical Context.................................................................................................................... 5

4 The Process...................................................................................................................................... 84.1 Planning....................................................................................................................................84.2 Preparation..............................................................................................................................114.3 Introduction............................................................................................................................ 114.4 Experiment............................................................................................................................. 124.5 Packaging................................................................................................................................12

5 The Instantiation............................................................................................................................ 135.1 Development Process............................................................................................................. 13

5.1.1 CPS Development Process...........................................................................................135.1.2 ConIPF CPS Development Process............................................................................. 14

5.2 Target Environment................................................................................................................155.2.1 Development Control Unit...........................................................................................155.2.2 Sensor Simulation........................................................................................................ 155.2.3 Human-Machine Interface (HMI)................................................................................ 165.2.4 Development Environment.......................................................................................... 175.2.5 Realisation Process...................................................................................................... 17

5.3 Knowledge Base.....................................................................................................................185.4 Conceptual Knowledge (AMPL-M).......................................................................................19

5.4.1 Context......................................................................................................................... 205.4.2 Features........................................................................................................................ 215.4.3 Software....................................................................................................................... 215.4.4 Hardware...................................................................................................................... 225.4.5 Interactions...................................................................................................................23

6 Issues.............................................................................................................................................. 246.1 The Experiment Process.........................................................................................................24

6.1.1 Experiment Plan...........................................................................................................246.1.2 Knowledge Base Construction Plan.............................................................................24

6.2 Methodology...........................................................................................................................25

6.2.1 Capability Features...................................................................................................... 256.2.2 Structure-based configuration......................................................................................256.2.3 Packaging variability....................................................................................................266.2.4 Asset Stratification.......................................................................................................26

6.3 Tools.......................................................................................................................................276.3.1 Modelling..................................................................................................................... 27

6.3.1.1 Configuration.................................................................................................. 286.3.1.2 Mindmaps........................................................................................................30

6.3.2 Derivation.....................................................................................................................306.3.3 Realisation....................................................................................................................30

7 Experiences in Methodology Introduction.....................................................................................317.1 Informing for Commitment.................................................................................................... 317.2 Training for Feature Configuration........................................................................................327.3 Training for Software Configuration and Calibration........................................................... 337.4 Training for Domain and Knowledge Engineers................................................................... 33

8 Experiment..................................................................................................................................... 348.1 Experiment Scope...................................................................................................................348.2 Experiment Environment........................................................................................................35

8.2.1 Feature Model.............................................................................................................. 358.2.2 Derivation Environment...............................................................................................35

8.3 Experimental Procedure......................................................................................................... 368.3.1 Direct Derivation..........................................................................................................368.3.2 Calibration....................................................................................................................368.3.3 Evolution...................................................................................................................... 368.3.4 Processors and Processes............................................................................................. 36

8.4 Experiments............................................................................................................................388.4.1 Direct Derivation..........................................................................................................388.4.2 Calibration....................................................................................................................398.4.3 Evolution...................................................................................................................... 408.4.4 Processors and Processes............................................................................................. 41

9 Results............................................................................................................................................ 429.1 Direct Derivation....................................................................................................................429.2 Calibration.............................................................................................................................. 429.3 Evolution................................................................................................................................ 429.4 Processes and Processors....................................................................................................... 42

10 Summary and Conclusions.............................................................................................................43

IST 2002-34438 / D3.3.3 / D3.4.2 / D3.5 Public Bosch Experience Report

1 Executive Summary

The ConIPF project defined a methodology for product line product development. Bosch applied this methodology to validate that the approach was practicable in industrial application.

The methodology was applied in the development environment of an organisation that developed preproduction prototypes of automotive embedded systems. The development environment was modified to support strategic reuse with the assistance of a structure-based configuration tool.

The knowledge models necessary to support the parametrised specification of the product hardware and software components from a description of the required features were developed. The software to transform this parametrised specification into a runnable system was also developed.

The software was installed on a platform consisting of commercial components and was tested under realistic conditions. Moreover procedures were tested for fine-tuning the initial product configuration.

The ConIPF-conformant system proved to be practicable in this application.

The ConIPF approach is very comprehensive. It requires careful planning and control to be implemented successfully.

The configuration tool employed in the experiment was mature in its core competence as a configuration engine. There is potential for improvement in support for modelling large amounts of knowledge and for integration with other tools in a typical development environment.

Configuration in Industrial Product Families Page 1


2 Preface

The goal of the ConIPF project was to define and validate a product line product derivation (application engineering) methodology that is practicable in industrial application.

The academic partners, Hamburg and RuG, defined the methodology ([Meth]) and the industrial partners, Bosch and Thales; have implemented it in their environments. The results of the experiments were assessed by the academic partners to establish if the methodology fulfills its purpose (product derivation) and whether it is practicable. The results of the assessment will be incorporated in [Meth] either as improvements to the methodology or as an assessment of its practicability.

2.1 PurposeThe Bosch Experiment Experience Report documents the insights gained by Bosch through applying the ConIPF methodology in the Bosch Car Periphery Systems (CPS) group.

Considering that:

• this is the only public document that describes the Bosch experiment,

• the ConIPF methodology is documented fully in a book,

• the generally accessible version of the methodology will be a white paper on the project web-site (http://www.conipf.org),

this document is primarily directed at readers interested in a complete example of an instantiation of the methodology and who want to decide if the methodology is applicable in their context. It assumes a good understanding of the methodology.

The methodology is sufficiently complex that it is impossible to understand its application without having understood it. The document uses ConIPF terminology, which in some cases has very specific meanings for terms that are quite general in common use. Some of the discussions involve very fine points of the methodology.

That being said, the document is also directed at the uninitiated reader who wants to get an impression of the scope of such an undertaking.

2.2 ScopeThis document describes the initial situation and outlines the steps taken to transform the CPS development environment into a ConIPF-conform environment. That is, the changes to the development process, product software structure and the supporting infrastructure. Moreover, it outlines the organizational changes that were necessary to support the changed development process.

This experience report describes the tests used to establish whether the methodology is feasible in an industrial setting and documents the results.

2.3 Definitions, Acronyms and AbbreviationsRefer to [Meth] for the definitions of general product line and ConIPF terminology.



2.4 ReferencesAnnex: Consortium, Annex 1 - Description of Work, , , 2001

BoschKBConst: Bosch, Knowledge Base Construction Plan, ConIPF Project Deliverable, D3.2.3, 2003

Czarnecki: Czarnecki, K., Eisenecker, U., Generative Programming: Methods, Tools and Applications, Addison Wesley, ISBN: 0-201-30977-7, 2000

ExpPlan: Bosch, Bosch Experiment Plan, consortium-internal, , 2002

FODA: Kang, K.C., Cohen, SG. Hess, J.A:, Nowak, W.E, Peterson, A.S,, Feature-oriented domain analysis feasibility study, Carnegie Mellon University, Pittsburgh, , 1990

FORM: Kang, K.C., Kim, S., Lee, J., Kim, K.,FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Arch..Annals of Software Engineeing, pp. 143-168,1998

Meth: LKI, RuG, Methodology I-V, ConIPF Project Deliverable, D2.1 - D2.5, 2003

MethInt: Bosch, Methodology Introduction Plan, consortium-internal, , 2004

Praise: Bosch (Hein, MacGregor, Schlick, Vinga-Martins), Bosch Lessons Learned, European Software Institue (ESI), , 2000

2.5 OverviewThis document has the following chapter structure:

Executive Summary

The executive summary provides a brief overview of the purpose, organisation and results of the experiment.

Introduction

The introduction is an introduction to the structure and contents of the document. Moreover, it is the reference repository.

The Process

This chapter describes the steps taken to plan and construct the development environment used in the experiment.

The Instantiation

The instantiation describes the development environment – the instantiation of the ConIPF methodology.

Issues

This chapter documents the technical considerations related to the experiment.

Experiences in Methodology Introduction

This chapter summarised the organisational issues encountered in the course of the experiment.

Experiment

The tests used to validate the methodology are outlined in this chapter



Results

This chapter documents the results of the experiments

Summary and Conclusions

This chapter interprets the issues, considerations and experiences encountered in the course of the experiment.



3 Introduction

This chapter presents background information about the experiment target environment.

3.1 PurposeBosch applied the ConIPF methodology in several functional areas of the Car Periphery Supervision (CPS) domain using several projects that develop manufacturable prototypes. In CPS, complexity arises from a large number of variants of individual features.

Note that the ConIPF activities ran parallel to the prototype development activities. These CPS development activities ran in conjunction with business units and had strict delivery commitments to Bosch customers. The approach of the ConIPF project was therefore to use the infrastructure and expertise available from CPS, and neither to dictate nor rule out that prototypes for customer projects be built using the ConIPF methodology.

3.2 Organisational ContextThe experiment took place in FV/SLD, a department in Bosch Corporate Research. As illustrated in Illustration 1 one group in FV/SLD participated in the ConIPF project while another did research into sensor applications. Personnel from the Product Line group were responsible for the organisational and methodological aspects of the experiment. The Sensor Applications group adapted their software for experimental purposes.

The Sensor Applications group has the mandate to liaise with customers and business units in order to expedite the initiation and development of new CPS product markets. It develops prototypes of new products tailored to a specific customer’s situation at several levels of suitability for manufacture. The department is also integrates of multiple CPS products in a single CPS system.

The FV/SLD CPS initiative is over 10 years old. Approximately 10 full-time engineers and engineering students worked on the project during the experiment time frame. The first ultrasonic OEM products were introduced into the market in 1994. There are now over 140 ultrasonic product variants.

3.3 Technical ContextCPS applications stem from the possibilities accruing from mounting ultrasound or radar sensors on automobiles to infer information about objects located at the car’s periphery. Such applications include services such as Parking Assistance, PreCrash Detection, Parking Spot Detection, Blind-Spot-Supervision, and Adaptive-Cruise-Control. At the moment, over 30 possible applications have been defined.

Some of these applications may be familiar, others less so.


Illustration 1: Structure of FV/SLD

Product LineApproachResearch

Group

DepartmentFV/SLD

SensorApplications (CPS)

ResearchGroup

ConIPFConIPFConIPFConIPFConIPF

Project

ConIPFConIPFConIPFConIPFSensor Application

DevelopmentProjects


• Parking Assistance indicates the distance to the nearest object visually (in a display) and/or audibly (with warning tones) while the vehicle is parking.

• PreCrash Detection infers an imminent crash situation and initiative appropriate actions. These actions include PreSet (sensitising the airbags to optimise their release timing) and PreFire (firing seatbelt tensioners).

• Parking Spot Detection estimates the size (and depth) of gaps between cars and informs the driver of sufficiently large spaces. Additionally, the application can calculate the vehicle trajectory and instruct the driver when and how much to steer in order to park the vehicle.

• Blind Spot Supervision sounds an alarm when an object is in the blind spot of the vehicle and the relative trajectories indicate imminent contact.

• Adaptive Cruise Control maintains a steady speed while also maintaining a suitable distance to the vehicle ahead of the subject vehicle.

For each application, there can be several different levels of functionality or convenience possible, from “basic” through “complete”, from “simple” through “luxurious” or from “manual” through “fully automatic”. Even by combining these aspects at this rather simplistic level, hundreds of individual products and thousands of hybrid products are conceivable. Illustration 2 portrays some of the viable possibilities that have been defined.

Bosch supplies electrical and electronic components to the automotive industry. It has more than 20 customers and each may manufacture vehicles for markets on 5 continents and scores of individual countries. A CPS feature can have a variant for each manufacturer in each market.

The CPS market was relatively new and the CPS effort was a mixture of applications in various stages of maturity. That is, this mixture ranges from product ideas that had not been scoped for market potential, through products where a number of prototypes had been developed to show to customers, through products that have been on the market for a number of years, sold to a number of customers (automotive manufacturers) were are available in several functional levels.


Illustration 2: CPS Product Line

Parking Assistance

Pre-Crash Detection Side & RearSemiautomatic ParkingBlind Spot DetectionPre-Crash Detection Side

ACC Stop & GoSemiautomatic GoPre-Crash Detection Front

Parking Spot Detection


Sensor applications overlap in terms of their requirements on object location information. Considering that there is at present a physical limit of six sensors of the same type in a bumper, sharing sensor signals among applications is inevitable. A common software infrastructure for the participating applications is therefore a necessary precondition for allowing the applications to share the sensors. This infrastructure was being developed in the target environment and dictated the course of the experiment.

The initial CPS product line initiative was studied in the PRAISE project (see [Praise]), where the emphasis lay on the scoping and domain engineering analysis phase. The domain scope defined in PRAISE has served as the basis for further product line development.

An initial feature model was developed in PRAISE which at the start of the experiment comprises more than 150 features at the capability and product attribute level.

Feature modelling was an iterative process because a number of product areas changed from immature to stable. Features were only modelled for the short to mid-term scope of the product family. Nonetheless, the feature model had the order of magnitude of hundreds of features, where each feature also reflects a variation point in the product palette and architecture.

Product line engineering work subsequent to PRAISE concentrated on defining and validating the logical, hardware and process architectures through an ATAM (Architectural Trade-off Assessment Method) review. The architectures were initially defined in UML using Rational Rose and then re-specified in Aonix StP. During the experiment the architecture views were revised according to the review results. The low-level architecture (generic components) was refined and the existing product software was reconciled with the low-level design.

Although some products would have been excluded from scrutiny due to their immaturity, given the combinatorial nature of CPS products, it would have been impossible to model the complete domain in this project. A subset of the PRAISE feature model was therefore used in ConIPF.



4 The Process

Illustration 3 shows that the ConIPF project was divided in a methodological stream and a experimental stream. While the academic partners established the requirements on the methodology and defined it, the industrial partners concentrated on planning and preparing to implement the methodology. This document represents the result of the packaging step at the end of the experiment.

The rest of this section describes the steps Bosch planned to take in the various phases of the experimental stream. Chapter 5 will outline the significant results.

Note that the steps leading up to the experiment are practically the same as would be taken to introduce the methodology in an industrial environment. Moreover, implementing the methodology as an experiment within a research project is not fundamentally different from testing the suitability of the methodology in a particular company through a pilot. This description can therefore serve as a basis for defining introduction plans in industry.

4.1 PlanningIn the planning phase the general plan proposed in the [Annex] was focused to a specific product area that was both mature enough to be mechanised and young enough that the current software structure could easily be adapted to the needs of the experiment. Planning was divided into 3 phases, each with a separate plan.

The Experiment Plan ([ExpPlan]) was analogous to a project plan. It documented how Bosch planned to realise the methodology. That is, the process that would finally be used to develop software. It focused on the information processing steps necessary to transform the requirements for a particular product into a selection of hardware components and an appropriate set of executable software components.

The Knowledge Base Construction Plan ([BoschKBConst]) examined what information necessary to support this process and specified how this information would be gathered, assembled and maintained in order to support the process. It is therefore subordinate to the and focuses on a single aspect.


Illustration 4: Planning Documents

Illustration 3: The ConIPF Timeline

Plan Prepare Introduce Perform PackageExperiments

Survey Define Observe PackageMethodology

Project Year 1 2 3

Knowledge BaseConstruction

Plan

MethodologyIntroduction

Plan

Info

rmat

iona

l Asp

ects

Methodology Implementation

Organisational Aspects

Experiment Plan


The Methodology Introduction Plan ([MethInt]) focussed on the who aspects. It examined the tasks and the roles assumed by the personnel that performed them in the current development process. It planned the organisational measures necessary to prepare the development organisation for the changeover to the methodology. It is therefore also subordinate to the [ExpPlan] and also deals with a single aspect of the plan.

The Experiment Plan

The structure of the experiment plan was based on the RUP Software Development Plan. It plan had the following essential sections:

• Project Overview

• Project Organisation

• Management Process

• Technical Process Plans

• Supporting Process Plans

• Additional Plans

The plan described how and with what means the experimental environment would be constructed. Note that here the emphasis was on the experiment.

The experiment plan defined the organisational and management processes that would be employed to perform the experiment. It defined the tasks required to implement and test the methodology. It also assigned roles to the tasks and personnel to the roles.

The plan defined the resource requirements, and in the technical process plans, it sketched the technical changes necessary to transform the current CPS development process to a ConIPF-conform development process.

It identified technical and organisational risks and defined corresponding monitoring and mitigation strategies. The plan also contained references to other plans, especially requirements and configuration management. The latter emphasized strategies for version management and coordination of parallel development of the knowledge base.

The Additional plans section documented the choice, or scoping, of the experiment's target environment.

The Knowledge Base Construction Plan

The Knowledge Base Construction Plan was a detailed plan to analyse and specify what means would be used to realise the methodology. Here the focus was on defining what the methodology would be in the CPS environment. It corresponds to the instantiation section of the methodology and answered the questions:

1. Just what do we want to do to derive products?

2. Just what do we need to do it?

3. Where can we get it? How do we reconcile redundancy?

4. How do we put everything together

• Point 1) involved tailoring the methodology to the product line goals of the organisation and, if necessary, adapting the existing development process to support product line reuse in general and the ConIPF methodology specifically.



• Point 2) involved defining the classes of knowledge that would actually be needed in CKML. Firstly it involved examining the APML elements that would be needed to support the process defined in 1). That is, the types of features, the types of hardware and software components, the types of parameters, etc. that are used in the target development environment.

• Point 3) entailed choosing the configuration and knowledge management tools to support the modelling and processing of the knowledge identified in 2). It involved examining the other CASE tools in the development environment (architecture / design, requirements management, configuration management and development(IDE, compiler, linker)) and reconciling their role with the process defined in 1) and the knowledge defined in 2). Lastly, the interfaces between the configuration, knowledge management and CASE tools were defined.

• Point 4) involved specifying the steps necessary to realise the development environment corresponding the first 3 points. As with all plans, it involved defining the tasks, assigning them to personnel, specifying their timing and defining the necessary resources.

• The essential chapter structure of the Bosch Knowledge Base Construction Plan was:

• Approach - Point 1)

• Preliminaries – Tailoring the ConIPF Methodology

• Survey - specifying the changes to the existing development process

• Representative Knowledge Model – Point 2)

• Analysis – Point 3)

° Characterisation of the Knowledge Base

– Types of Procedures – Direct Derivation , Calibration, Impact Analysis

– Reuse Knowledge – APML – Context, Features, HW/SW Components, etc.

– Development Knowledge – needed for the realisation transformations.

° Interactions and Interfaces with the Case Tools

° Tool Chain – choice of specific tools

• Construction Plan – Point 4)

The Methodology Introduction Plan

The Methodology Introduction Plan focussed on the demands being placed on the operative personnel. The current development process was documented in terms of the information processing tasks performed by the project managers, the developers and the integrators respectively. The ConIPF process was documented in a similar fashion. Note that the knowledge modelling and maintenance tasks were required a new developer role. Lastly the training and preparation activities were defined by comparing the differences between the existing and desired processes.

The essential chapter structure of the plan was:



• Existing Process

• ConIPF Process

• Transition Plan

4.2 PreparationIn the preparation phase, the background work was done to characterise the infrastructure of the sub-domain as it existed and to identify and test the changes necessary to allow the methodology to be tested. It consisted of the following tasks:

Develop the Feature Model

Existing domain engineering feature models (PRAISE), customer requirements and prototype specifications were examined to characterise the sub-domain product palette at the feature level. Future trends in the product requirements were also be considered. A feature model was specified using an appropriate knowledge representation (see Knowledge Base Implementation Plan, below) that characterised the composition of the features, their variability and the interdependencies between them.

Develop the Artefact Model

The structure and parametrisation of the current software was examined against itself and against the feature structure and the changes necessary to accommodate the methodology were identified. Based on this, now idealised structure, a knowledge model was again defined that described the composition of the product software.

Develop the Intermediate Representations

A representative set of product specifications were identified. The relationship between the feature and the artefact configurations for these products was examined and the correlation between them was defined. Intermediate knowledge models were defined based on these correlations.

Knowledge Base Implementation Plan

Considering that the success of the experiment depended on a correct and complete knowledge base, current knowledge base engineering techniques were surveyed in collaboration with LKI. A major consideration was the maintainability of the knowledge representation and more specifically, facilities to test its consistency and locate inconsistencies.

A plan was produced which sought to minimise risk and effort in implementing the knowledge base containing the feature model, the artefact model and the intermediate representations.

4.3 IntroductionIn this phase the infrastructure for the experiment was developed. The tools to support the configuration were selected. The models defined in the preparation phase were adapted as necessary to the configuration tools and expressed in their fullest extent and detail. The rest of the tool chain was adapted and the system was tested using the software from existing prototypes. The phase had the following tasks:

Building the Knowledge Base

See above.



Preparing the Tool Chain

Interfaces to the simulation, compilation, installation (on the control unit), integration testing and configuration management systems were defined and the necessary adaptations were implemented.

Organisational Preparation

The procedures for developer interaction with the configuration system as well as the changes in the interaction with the simulation, installation, integration testing and configuration management systems were documented.

4.4 ExperimentThe purpose of the experiment was to apply the methodology on a sufficiently large scale in order to demonstrate the applicability of the methodology on an industrial level. During the experiments feedback was given to the academic partners through their assessments, which resulted in the fine-tuning of the engineering techniques and methodology.

The main result of the experiment was a demonstrable application of the methodology with Bosch test cases, and a demonstration of a prototypical engineering environment geared towards assisted product derivation and configuration.

4.5 PackagingPackaging consisted of preparing input for the various dissemination activities and centred around the preparation of this experience report. The reports document how the methodology was demonstrated and to what degree the expected results were obtained. Furthermore, problems encountered in the implementation of the methodology as well as the solutions found were listed and explained. Specific proposals to enhance the methodology will be made. The following tasks were defined:

Preparation of the Bosch Experience Report

This experience report was prepared.

Preparation of the Bosch Contribution to the Book

The deliverables were tailored for publication, as required by the academic partners.



5 The Instantiation

This chapter documents the environment in which the methodology was tested. CPS was used as the Guiding Example in the [Meth] document and the essential modelling and instantiation aspects are covered there. The purpose of the chapter is therefore to give an impression of the industrial realism of the environment used in the Bosch experiment.

This section provides the information necessary to understand the issues presented in Chapter 6. Refer to the [Meth] for the corresponding methodological considerations.

The earlier parts of the chapter address the application engineering process, while the latter parts present the models used in the derivation – normally the purview of domain engineering. Refer to the [Meth] for an explanation of how the models are processed by the configuration tool.

5.1 Development ProcessThis section first documents the conventional development process used by the CPS research group. It then outlines the development process used in the experiment.

5.1.1 CPS Development Process

The basic architecture of CPS products is illustrated in Illustration 5. The sensors contain microprocessors which preprocess the signals before sending them to the control unit The control unit contains software to interpret the information from the sensors into a representation of the objects in the automobile’s environment (environment description) and to execute the various applications based on that representation. The software is structured in 3 layers: the applications, the environment description layer and a framework consisting of, among other things, OSEK, a commercial operating system.

Development of CPS systems can be divided into two major streams: the development of sensor processing, including environment description, and the development of the applications, such as parking support, automatic cruise control, etc. that depend on the sensor processing. The applications are therefore the consumers of the products of the


Illustration 5: Basic CPS Architecture

Sensor1

Sensorn

Sensor2

Bus

Control Unit

. . . Framework

App.

1

App.

n. . .

EnvironmentDescription

Sensors


sensor applications and the development of new systems proceeds synchronously insofar as the new application requires new sensor application functionality.

Illustration 6 shows the conventional CPS system development process. The algorithm is developed separately from the system until both reach sufficient maturity. In the less mature stages, the software is developed in a PC-based environment and without real-time constraints

The algorithms are first coded in C using Microsoft Visual Studio and validated in a PC environment using Labview. Pre-recorded sensor data is used to test the algorithms.

The algorithms can first be tested with real-time constraints by simulation in a PC environment using a test facility provided by the OSEK operating system.

After successful simulation, the system is installed in prototype hardware consisting of a control unit that is outfitted for debugging. Low speed applications can be tested in a test harness consisting of a car bumper mounted on a sled on rails. High-speed applications must be tested in a test harness installed in an automobile.

5.1.2 ConIPF CPS Development Process

Refer to [Meth] for a description of the basic ConIPF process model. To an extent the process model is a replacement for the conventional requirements analysis phase where raw requirements are transformed into a consistent, technically feasible and implementable requirements specification. Insofar as components from the platform can be used directly, the process additionally circumvents the rest of the conventional analysis and design phases

The result of the ConIPF process is a list of artefacts and their parameter values which would flow directly into a component integration step. The CPS development process is iterative with successive iterations bringing the new system closer to the target hardware. The positioning of the ConIPF process with respect to the current CPS process is shown in Illustration 7.

Note that the CPS environment is somewhat different than typical software or systems development processes in that algorithmic development plays a central and essential role. In Bosch business units with more mature technical domains, the algorithms used in products have stabilised and the whole technological basis for the products is relatively well understood. In recent years the business units have been increasingly successful in structuring, standardising and parametrising the algorithms so that they can be used without modification.


Illustration 7: The ConIPF CPS Development Process

ConIPF Configuration

Release

ConIPF Realisation Algorithm Simulation

Algorithm Development

Algorithm Simulationw/ Real-time Constraints

Synthesis on Hardware

ConIPF Calibration

Illustration 6: The CPS Development Process

Architectural Design

Release

Detailed RealtimeDesign Algorithm Simulation

Algorithm Development

Algorithm Simulationw/ Real-time Constraints

Synthesis on Hardware

Test


The assessment of the extent to which the algorithmic development could be parametrised and therefore integrated in the configuration process was a part of developing the artefact model in the preparation phase. The integration of configuration in the algorithmic development process affected the relative positioning of the configuration process in the system development process.

5.2 Target EnvironmentAt the time of the experiment, FV/SLD had developed a series of Short-Range Radar (SRR) applications which were cohesive and exhibited enough variability to reflect a product line. Applications existed for Parking Assistance, PreSet and PreFire.

The goal of the experiment was to test the methodology in an environment that was as close to a normal development as possible. The idea of demonstrating the methodology by deriving the software and installing it in a vehicle was considered. It was rejected, however, in favour of using the CPS development platform. In the end it was as realistic as a vehicle platform, as it used the same hardware and ran with the same real-time constraints as a production system thanks to the aforementioned facility of the OSEK operating system. As a demonstrator, it had the advantage that it was robust and far more portable than a vehicle platform.

The software generated by the ConIPF development process would be installed on a development control unit platform. For testing and calibration, prerecorded sensor data would be put on the control unit's bus by a PC. A Human-Machine Interface (HMI) was developed to show the effects of configuration and calibration on the running system.

5.2.1 Development Control Unit

The experiment used a standard development control unit which is used in the workbench development in conventional CPS process.

The control unit consists of a production or pre-production automotive components and is mounted in a case to make it easily transportable. It has 2 CAN bus connectors, one that receives the sensor data as input and the other that sends control information on the HMI. It also has debugging and flashing interfaces for development purposes.

5.2.2 Sensor Simulation

The sensor simulations are also a standard application used in workbench development in the conventional CPS process. The simulations are Labview applications that run on PCs equipped with CAN bus cards.


Illustration 8: Target Control Unit


Files of sensor data recorded with a laptop in the field can be loaded into the application and used to feed the control unit over the CAN bus. The playback speed depends on the PC processor and the control unit clock frequency must be reduced to synchronise with the data feed.

Illustration 9 depicts the playback interface of the application. It consists of a window with the player interface and another window showing a video of the recorded situation.

The main window in the player interface shows distance information (y axis) over time (x axis). The lines in the graph show the progress of the echoes detected by the sensors (2 sensors in the illustration).

5.2.3 Human-Machine Interface (HMI)

An HMI was developed for the experiment to demonstrate the configurability of the software. The HMI was written in Labview and runs on a separate PC which is again equipped with a CAN bus card.

The applications in the HMI are activated and configured at programme start-up based the results of the ConIPF derivation process.

The slider at the bottom of the window indicates the distance to the nearest object – a value calculated by the control unit based on the sensor data it received.

The coloured bars in front of the automobile depict zones that are used in the parking assistance application. Parking assistance can be configured to have either 3 or 4 zones. In the simulation, the bar is greyed out when the object enters the zone. The object also triggers beep tones that increase in frequency as the object enters nearer zones.

The two spheres under the automobile turn bright green when the object triggers the PreCrash applications: PreSet and PreFire. That is, when the airbag is sensitised (PreSet) or the belt tensioners are released (PreFire).

The switches under the front parking assistance zones indicate the state of the HMI options.


Illustration 9: CPS Sensor Simulation

Illustration 10: ConIPF HMI


5.2.4 Development Environment

The development environment had the following components:

• iSystem WinIdea:

° Development IDE for the control unit

• Texas Instruments compiler

° C

• XML Spy – XML Editor

° Examination of the knowledge base

° Manipulation of the output from the configuration tool

• Saxon – XSLT Processor

° Parsed the output of the configuration tool to generate compiler commands, the software parameter file for the control units flash memory and the HMI configuration file

° For documenting the knowledge base and configurations in readable (pdf) format

• LabView

° HMI

° Sensor Data Simulation

5.2.5 Realisation Process

Illustration 11 documents the steps necessary to transform the (partial) configuration produced by the configuration tool (in this case EngCon) into a running system.

The configuration can still be open. Typically, the configurer can have either decided not to specify all the system or compiler parameter values or have left a choice open where all alternatives were feasible.

In both cases decisions must be made in order to complete the system. The default parameter values have been modelled in the knowledge base and a script substitutes these as necessary to completely specify the system.

Separate XSLT scripts produce the compiler commands, the software parameter file for the EEPROM and the HMI configuration file.


Illustration 11: ConIPF CPS Realisation Process

Start Control Unit

Compile Application Load EEPromParameters Start HMI

Parse for SoftwareConfiguration with XSLT Complier Script(s)

Parse Parameter Valueswith XSLT EEPromParameter Value List

Parse for HMIConfiguration with XSLT HMI Configuration

File

Give Open ParametersDefault Values with

XSLT FullConfiguration in XML

Derive Application withEngCon Partial

Configuration in XML


5.3 Knowledge BaseEssential questions for the knowledge base are:

• which information is stored where

• whether redundant information is allowed

• what interfaces are needed between the tools.

Illustration 12 is an attempt to relate the knowledge processing and storage relationships between the configuration tool and conventional CASE tools in a ConIPF-conformant process. Among other things, it is clear that the feature models in the configuration tool have their pendants in requirements management. There is a similar overlap between the configuration model and UML models with respect to hardware and software component descriptions.

The dark blue rectangles represent knowledge entities whereby the upper entities are more abstract and related to modelling and the lower entities are more concrete and are the objects of the derivation process. The grey arrows follow a specialisation / taxonomic hierarchy. The blue circuits of arrows represent the direct derivation (downwards, left) and evolution (counterclockwise) streams in the ConIPF process. The semi-transparent ovals in the background represent the spheres of influence of the various tools.

The tools use the models specified in the rectangles and receive them through the operations or conditions specified in the blue arrows.

Illustration 13 shows the tools that were employed in the experiment. Note that the tool aspects of realisation were discussed in the realisation section.

The CASE tools were largely inherited from the conventional CPS development environment. Rose was added to the list due to its integration with Doors and the fact that is used heavily by FV/SLD's product line group.

EngCon was chosen as the configuration tool primarily because of

• its direct structure-based modelling support,

• its procedural knowledge support,

• the close communication between the University of Hamburg and Encoway,


Illustration 12: ConIPF Tool Spheres


• Encoway's willingness to customise it for ConIPF.

• The configuration models were created by hand in EngCon's modelling environment. The possibility of modelling the components in StP and exporting them to EngCon was investigated, but it proved infeasible due to packaging considerations (refer to Chapter 6).

Mindmaps were used to sketch the conceptual knowledge (AMPL-M - see the next section) as they are already used quite extensively at Bosch for feature modelling. Bosch used the MindManager tool from MindJet.

The possibility of employing Doors in the experiment was also investigated. In the end, the case for using Doors in a production environment did not seem that strong. The ConIPF process defines its features in the configuration tool. Doors supports the traceability of customer documents to its internal requirements and feature models, but the problem of supporting the traceability from Doors to the configuration tool remained. Since the customer requirements documents may be realised in XML; it appeared to be easier to build traceability support direct from a repository for customer documents to the configuration tool.

The build facilities of Source Integrity were inextricably integrated with the Visual Studio IDE. The realisation scripts therefore used the Texas Instruments compiler while development work was done with Visual Studio and Source Integrity.

Completely configured systems were managed in Source Integrity were stored in Source Integrity in a conventional manner. The final configurations (that is, the XML files from EngCon) were included in the version sources.

5.4 Conceptual Knowledge (AMPL-M)This section provides an overview of the CPS knowledge base. It is intended to be a complete example, providing illustrative insights into the basic elements and interactions and the capabilities of structure-based configuration for product derivation.


Illustration 13: CPS Knowledge Spheres


The conceptual knowledge was sketched during the knowledge base design in order to classify the types of knowledge needed and therefore to derive the demands on the configuration tool. The versions shown here were prepared as a basis for discussion before the final versions were entered directly into EngCon.

Mindmaps have a basic tree structure that can be used to express feature trees. The notation used in the experiment denoted cardinality (multiple, alternative, optional) explicitly. It failed, however, to indicate whether branches denoted partonomies (the child nodes are parts of the parent node) or taxonomies (the child nodes are instances´of the parent node's type). The difference can be easily deduced from the context, however.

ConIPF defines assets as concepts with attributes. Considering that assets can be modelled as parameters or as optional parts, the notation was enhanced with a specific symbol to denote attributes.

5.4.1 Context

The context consists of aspects of the target vehicle, the physical environment and the region where the CPS system will be used.

The physical environment dictates which hardware can be used. All hardware in the system must at least be certified for the minimum and maximum temperatures and humidities specified in the physical environment.

The region dictates several types of minimal requirements. First of all, the region can dictate the maximum/minimum temperatures /humidities. Secondly, it can dictate certain regulatory assumptions – allowable frequency ranges, emissions regulations, etc. Thirdly, it can dictate technical assumptions – metric / SAE threading, for example.

The target vehicle again dictates technical requirements on the system – the communications bus, types of connectors, etc. In the CPS example the width of the bumper also derives suggestions for the placement of the sensors on the bumper and their geometry.


Illustration 14: CPS Context Model

CPS Context

Target Vehicle

Front Bumper

Width

Height

Rear Bumper

Width

Height

Interfaces

Airbag Interface

Belt Tensioner Interface

MMI Interface

Physical

Max Temperature

Min Temperature

Max Humidity

Min Humidity

Region

Europe

N. America

Rest of the World

Max Temperature

Min Temperature

Max Humidity

Min Humidity

Multiple (One or More)

Alternative (Just 1)

Optional

Property


5.4.2 Features

CPS has 3 applications: Parking Assistance, PreSet and PreFire. The latter are parts of PreCrash and choosing either implies choosing PreCrash as well.

Parking Assistance has 3 or 4 zones whose depth differentiates the relative danger of the object that is nearest to the vehicle. The danger can be signalled to the user through a display, with a tone or both. Each zone has configurable tones or display colours associated with it.

Parking Assistance can use 1 or 2 sensor configurations. A 1 sensor configuration is restricted to supervising the passenger side and is not available with the PreCrash applications.

The maximum depth of the parking assistance zone dictates the requirements on the sensor configuration. A maximum depth of over 1 metre means that a more powerful ultra-sound configuration or one of the SRR configurations must be taken.

PreSet and PreFire each have 2 zones. The outer (activation) specifies where the application starts to monitor objects in the periphery. The inner (trigger) zone specifies the point where application reacts – sensitised the airbag or fires the belt tensioner, respectively.

PreCrash applications require SRR sensors, but can share the sensor data with other applications (parking assistance in this case). PreCrash software can be outfitted with several tracking algorithms. The algorithm, or combination of algorithms, installed in the software influences the accuracy of the tracking. The PreCrash feature has an attribute “Probability of a wrong action” which dictates which algorithm is installed.

Again, the maximum of all PreCrash activation zones dictates the requirements on the sensor configuration.

5.4.3 Software

The bulk of the software was common to all applications. The common modules were bundled together and their variability parametrised. The common software is therefore modelled as mandatory.


Illustration 15: CPS Feature Model

CPS Features

Application

Parking Assistance

Supervision Depth = Max[Trigger Depths]

Symmetry

Passenger Side (1 Sensor)(excludes PreCrash)

Left & Right (2 Sensors) (does not exclude PreCrash)

H-M-I

Zones

Imminent

Trigger Depth

Tone

Colour

Very Near

Trigger Depth

Tone

Colour

Near

Trigger Depth

Tone

Colour

In Proximity

Trigger Depth

Tone

Colour

AlarmRadio

Buzzer

Speaker

Display TFTBig

Medium

Navi Monitor

PreCrash

PreSet

Trigger ZoneDepth

Activation ZoneDepth

PreFire

Trigger ZoneDepth

Activation ZoneDepth

P(Wrong Action)Unlikely

Very Unlikely

Extremely Unlikely

Supervision Depth = Max[Activation Depth]



Optional

Property


The number of sensors used affects the supervision and control behaviour of the software. The Main module therefore has variants for 1 and 2 sensor configurations.

Each application has a corresponding software package.

PreSet and PreFire require the PreCrash package, which, in turn, must have a tracking algorithm (COI). Which COI depends on the probability of wrong action specified in the feature model.

5.4.4 Hardware

There are a number of ultrasound and SRR sensor configurations that offer different supervision depths. The appropriate configuration depends on the type of application and the maximum of the supervision zone specified in the feature model.

There are a number of modalities for auditory and visual warnings. Note that the TFT displays were specified with a minimum temperature of -40°C. In physical environments with a lower minimum temperature, TFT displays are not offered as a feature.


Illustration 17: CPS Interaction Model

CPS Interactions

Feature <==> Software

PA requires PA

PreFire requires PreFire

PreSet requires PreSet

P(Wrong Action) == Unlikely requires COI 1D

P(Wrong Action) == Very Unlikely requires COI 2D

P(Wrong Action) == Extremely Unlikely requires COI 1D & 2D

Feature <==> Hardware

Max[Application Supervision Depth] <==> Sensor Configuration Supervision Depth

PreCrash requires SRR Sensors

(PA > 1m) ==> SRR Sensor

(PA <= 1m) ==> US Sensor

Passenger Side PA means 1 sensor

Hardware <==> Software

Configurations with 1 Sensor require a Main 1 Sensor

Configurations with 2 Sensors require a Main with 2 Sensors

Hardware <==> ParametersSensor Configuration <==> CCU_Max Temp

Features <==> Parameters

PA Supervision Depth <==> ParkingAid_TP_X

PS, PF_Activate Zones <==> PS, PF TTI, Distance Activate

Context <==> ParametersBumper Width <==> Sensor_Y

Context <==> Hardware

Physical Temperature Range <==> Operating Temperature Range

Physical Humidity Range <==> Operating Humidity Range

Airbag Interface <==> CCU

Belt Tensioner Interface <==> CCU

MMI <==> CCU

Illustration 16: CPS Artefact Model

CPS Artefacts

Software

Common

Main 1 Sensor

>1 Sensor

PreCrashCOI COI 1D

COI 2D

ApplicationParking

PreSet

PreFire

Hardware

Control Unit

Airbag Interface

Belt Tensioner Interface

MMI Interface

Sensor Configurations

1xUS(a)Supervision Depth=1m

1xUS(b)Supervision Depth=2,5m

1x SRR_aSupervision Depth=3m

2xSRR_aSupervision Depth=10m

2xSRR Supervision Depth=20m

AudioBuzzer

Loudspeaker

Radio Adapter

DisplayTFT 1

TFT 2

Navi Adapter



Optional

Property

requiresrequires


5.4.5 Interactions

The interactions between asset classes were placed in a separate model. Interactions within the class were placed in the class model. Other than the meaning of some software parameter names, the interactions have been explained with the respective asset models.

The software parameter interaction model is presented for illustrative purposes only. X and Y denote the longitudinal and latitudinal offsets from the centre axes of the vehicle. CV is closing velocity and TTI is time to impact.


Illustration 18: CPS Software Parameter Interaction Model

CPS Parameters

Common

Sensor (Configuration)Sensor.y [mm]

Sensor_aktiv

Dokutool Data

TTI für DOKU_TRIGGER [ms]

Min CV für DOKU_TRIGGER [m/s]

Max CV für DOKU_TRIGGER [m/s]

CCU_CONFIGCycle TIme [ms]

TEMP_MAX

Start

Parking

PARKINGAID enable

PARKINGAID_TP_Y

PARKINGAID_TP_X

COI

COI 1DCOI MINLIFE_1D [1..10]

COI 2DCOI MINLIFE_2D [1..10]

COI_MAX_2D_AGE

COI Y-CORRECTION [mm]

COI_MIN_CV

COI TIME-CORRECTION [ms]

COI MAX DY [mm]

PreSet

PRESET TTI SEND [ms]

PRESET TTI ACTIVATE [ms]

PRESET DISTANCE ACTIVATE [mm]

PRESET MIN CV [m/s]

PRESET MAX CV [m/s]

PRESET MAX DY [mm]

PreFire

PREFIRE TTI [ms]

PREFIRE MAX CV [m/s]

PREFIRE MIN CV [m/s]

PREFIRE MAX DY [mm]

=

=

|Sensor.y| < MAX DY

|Sensor.y| < MAX DY

ACTIVATE > SEND

Enable ?= CV <= Min CVg

Enable ?= CV <= Min CV


6 Issues

This section discusses significant considerations encountered during the experiment.

Note that, in the rule, problems are more interesting than expected results. This section therefore presents the more interesting aspects of the experiment. That should not in any way be construed to be a negative judgement of the methodology or any of the tools that were used.

6.1 The Experiment Process

6.1.1 Experiment Plan

As mentioned in the preceding chapters, the experiment was essentially a project to construct a ConIPF-conformant product line product development environment. The differences were that ConIPF was not defined at the beginning and that there was increased emphasis on creating an environment that tested the capabilities of the methodology.

Using the RUP template brought a needed discipline into the process that, perhaps, would not otherwise have been there. Issues that otherwise might not have been considered include:

• Documenting the existing process, the planned process and planning the transition

• Stakeholder analysis, especially the project's external interfaces

• Training requirements

• Project control considerations – time, budget

• Risk management and problem resolution procedures

• On a number of occasions, it seemed that various stakeholders in the experiment had an informal impression of what the experiment was supposed to do and what it was supposed to accomplish. Because the plan explicitly documented the analysis, the assumptions and the risks it was much easier to clarify the misunderstandings.

6.1.2 Knowledge Base Construction Plan

Again, the knowledge base construction plan brought a needed discipline that, perhaps, would not have otherwise been there.

The methodology recommends a survey of the expressiveness of representative knowledge and mapping it to CKML. This is probably not intuitive and definitely a good basis for comparing configuration tools. Certainly all considerations of the representations of variability (through parametrisation or through binding components) ameliorate design problems that would surface in the implementation or in the operation of the system.

Considering the interaction with CASE tools and rethinking the mechanisms used in the realisation phase are also issues that could easily be overlooked in the planning stage.



6.2 Methodology

6.2.1 Capability Features

Capability features were a basic premise of the ConIPF project. In CPS, the zones in PreCrash and Parking Support are capability features. The zones were defined only to have a maximum depth, but could have just as well been defined to have more non-functional aspects such as breadth or sensitivity. The key is that the configuration tool can eliminate all sensor configurations with inappropriate zones and that the zones represent a concept that is intuitive to the layman.

The alternative to using capability features would have been to have the configurer select the sensor configuration. Either the configurer would then be presented with the data for each sensor configuration and would make his choice accordingly. Or the configurer would not be presented with the data and would have to rely on experience or intuition to ensure that the sensor configuration met the requirements. Additionally, in both cases, the configurer would be responsible for ensuring that the sensor configuration was appropriate for the envisaged application. If the interactions between the capability requirements of the various applications are not or can not be modelled, it must be so. Experiences outside of ConIPF have shown that trying to model features solely as product components or product attributes leads firstly to vastly larger and more complex feature models and secondly to larger and more complex, almost nebulous, constraint models.

The experiment has established that using capability features has clear advantages. It has corresponding disadvantages, however. Firstly, the capabilities of the product must be identified and the effects of certain components, or of combinations of components must be known. When this information exists at all, it is usually in the heads of experts and requires further expertise to be formalised. Secondly, it requires substantial effort to develop and maintain the corresponding models. Each new component can change the capabilities or the interaction.

In the end, it is a judgement call in each organisation whether the reuse potential is high enough or if errors due to product decisions in the absence of appropriate expertise are costly enough to justify the investment in modelling capability features.

The Bosch experiment indicates that it can be.

6.2.2 Structure-based configuration

Using structure-based configuration, as opposed to other types of configuration, was also a basic premise of the project. Since the University of Hamburg had the expertise and had recommended structure-based configuration, there was no cause to investigate alternatives.

That being said, the impression is nonetheless that a tool that supports structure-based configuration from its native facilities presents a significant advantage over more-general tools where the inferences stemming from the structural relations (has parts) must be programmed.

The constraints sketched in the AMPL-M section of this document could be implemented practically 1:1 in EngCon. That is, rather than programming multiple constraints in the tool for the constraints formulated abstractly in the knowledge base design, one constraint was usually sufficient. The constraints were not directed, however, so that the constraints often resulted in two parts.



The taxonomic (inheritance) relations brought more significant advantages, however. It is easier to keep an overview of the constraints and the constraints are more easy to maintain.

A typical example would be the constraint that all hardware meet or exceed the temperature and humidity requirements. This was implemented with 4 attributes on the Hardware concept class and 4 constraints (All concepts of the type hardware must have a maximum operating temperature greater than the maximum temperature in the environment, all hardware concepts must have a minimum operating temperature less than the minimum temperature in the environment, and so on.) A new hardware component inherits both the attributes and the constraints. Maintenance consisted merely of setting the maximum and minimum temperature/humidity values for new components. In fact, in the absence of these values, they would always be offered for selection.

6.2.3 Packaging variability

Two significant issues in modelling were

• Whether the sensors could be allocated individually

• Whether the software compatibility would be modelled. That is, whether individual software classes would be modelled with their interfaces (or with connectors) or would the software be modelled so that only compatible components could be combined.

The capabilities of sensors could only be sensibly considered as packaged solutions. It is intuitive that a designer would make a choice between a 2, 3 or 4 sensor solution with homogeneous sensors, but less intuitive that the designer would mix and match, say two SRR sensors as opposed to 2 SRR sensors on the outside and an ultrasound in the middle. Both alternatives only make sense when capabilities of the individual combinations have been tested.

Similarly there is a tendency, at least in the embedded systems area, to use proven aggregates of software components and minimise the risk of unforeseen interactions.

Both examples lead to the hypothesis that in the context of strategic reuse, it is better to limit the amount of compositional variability. That when the capabilities, and the qualities such as reliability for that matter, must be assured, that the product should only be configured with certified combinations of components.

This leads to considerably less variability in the system with correspondingly less modelling and model maintenance effort. It also leads to considerably more testing effort, however.

6.2.4 Asset Stratification

CPS was modelled in several layers. The context, features, the artefacts and the software parameters were each in separate layers. It was hoped that using these layers would minimise the interactions between the layers.

The interaction model is relatively simple which seems to indicate that layering was a good strategy.



Note as well, that the procedural model follows the same philosophy: First configure the context, then the features, then the artefacts and then the software parameters. Experience from testing the knowledge base indicates hat deviating from this strategy increased the likelihood of conflicts, reduced the amount of inference and increased the number of decisions that had to be made explicitly.

6.3 ToolsEngCon is generally sold as a turn-key system. Encoway is a service provider that develops the configuration models for the customer. Moreover, it develops interfaces to the customer's MRP system, (SAP, for example) and front-ends that control the configuration process.

In the context of the experiment, neither a custom front-end nor turn-key configuration models were appropriate. The experimental system therefore used internal EngCon testing interfaces for modelling and configuration. The modelling interface was definitely designed as a single-user application. The configuration interface was neither designed for the comfort of uninitiated users nor for end-users.

6.3.1 Modelling

Calibration - Parameter Defaults as Attributes

In the initial derivation to a runnable system, the initial parameter values and component choices can be conservative or optimistic. Calibration is the process of optimising a viable system for a particular application and/or target platform. Essentially, to do this, run-time parameters can be changed or existing components can be replaced with more / less powerful or more / less expensive components. These are re-configuration operations that should also be controlled by the configuration tool.

As delivered, EngCon only supported linear backtracking. That is, the configuration steps could only be undone in the order in which they were taken. Ultimately, ConIPF commissioned the development for support in EngCon for arbitrary changes. Before that, Bosch tried the following approach with moderate success.

Each parameter value is an attribute of the concept corresponding to its component. In EngCon, the attributes were also equipped with fields which contain arbitrary, non-configurable data. The default values of the parameters were placed in the fields so that they could be used when the attribute was not given a value during the configuration process.

The engineer could then configure the product to his satisfaction and would then store the (partial) configuration. The XSLT scripts that processed the configuration to obtain a viable system were written to use the default values when the attributes' values were not set. Should the engineer establish after testing that the attributes should have non-default values, he could set them by loading the partial configuration into the configuration tool.

By placing the resulting set of partial configurations under configuration management and commenting the changes rigorously, the engineer could backtrack to a point and configure further.

Generally, this solution worked well. Note, however, that it is only applicable to reconfiguring parameters.



6.3.1.1 Configuration

Modelling in Parallel

As mentioned above, the EngCon modelling environment was designed for single-user operation. In fact, it was probably designed to be used offline. That is, not on the the knowledge base running in commercial operations. Testing revealed that operating in parallel on the same knowledge base on the same machine could lead to changes being over-written.

At any rate, the experiment knowledge bases were generally developed by a single engineer. For a short while two engineers used the same basic knowledge base to model separate enhancements. Since the limitations of EngCon were already known, no problems were encountered. In the end, the 2 knowledge bases were merged using an XML tool. There were problems synchronising the knowledge bases with the DTD, which made the merge more difficult as the concepts in the two knowledge bases had stored in different orders.

This later problem was encountered on a number of occasions. A “diff” between two knowledge bases was difficult without the DTD.

The knowledge bases were put under configuration management during their development. There was never the need to retrieve a backup. The versioning was primarily used to document the progress of the knowledge base and provide a traceability between the development tasks and the changes in the knowledge base.

Again, as the EngCon modelling interface is designed to be single-user, the knowledge base can be monolithic. In small development groups such as FV/SLD, it is quite possible that only one engineer would do the modelling. In large organisations, it is more likely that engineers would be responsible for the models related to their subsystems or areas of expertise. This would speak for distributed knowledge base models.

In the future there will probably be the need to support synchronous modification of the knowledge base and / or the ability to develop independent models and to integrate them.

Naming Convention for Constraints

During the experiment, the CPS knowledge base contained approximately 50 constraints. The constraints were presented in an alphabetically-sorted list, and the first line of the GUI contained the alphabet as hyperlink shortcuts to the corresponding entries in the list.

It soon became clear that a constraint name that merely reflected its function would quickly get lost in the list.

Bosch employed a naming convention which followed the convention of the AMPL-M models. The class of constraint was (roughly) denoted by the AMPL-M class: C for Context, F for Feature, A for Artefact, P for Parameter. Interactions within a class were prefixed with a single letter, F_ for feature interactions, for example. Interactions between classes were prefixed with two letters so that a C_F_ constraint was an interaction between the context and a feature.

This technique helped to control the multiplicity of constraints, but it began to show its limits.

The naming convention also used standardised names for the components, PA for Parking Assistance and PC for PreCrash, for example. Since some components had the same names as the features, there were standardised suffixes for the asset classes, whereby features did



not have a suffix. That is, PA was the Parking Assistance feature and PA_Module was the corresponding software component.

Before this latter convention was introduced, there were several constraints with redundant functionality. After the complete naming convention was operational, it was reasonable to audit the constraints for redundancy and redundant constraints were often noticed in the course of routine maintenance.

In the long term a graphic interface with a connection to the conceptual knowledge will be necessary.

Shares Relation

In the standard EngCon each part can only be the part of a single parent. In software there are many situations where this condition does not hold. Each application needs a platform (operating system, say) and the instantiation of an application should cause the instantiation of the platform. But the instantiation of a further application should not cause the instantiation of a further platform.

The relationship that applications have to their platform was termed “shares”. In the CPS example, the PreSet and PreFire features share the PreCrash feature and there is a corresponding relationship between the respective software modules.

After an extensive requirements definition and joint design process, ConIPF commissioned the enhancement of EngCon with a shares capability.

The solution implemented the relation as a constraint between classes. Using a constraint to implement the shares relation had the advantage of immense flexibility. Two components could share an arbitrary number of subcomponents and still have an arbitrary number of private subcomponents of the same type.

The solution was not optimal ergonomically, however.

A shares relation is a partonomic relation. The partonomic information was modelled in a window for modelling the conceptual knowledge – taxonomic and partonomic combined. While the modelling interface showed which parts a concept had, it did not indicate in any way the parts that it shared. The shares constraint was displayed in the constraint modelling window, along with the interaction constraints. The shares constraints could be held together with an appropriate prefix in the constraint name, however.

Backtracking

Refer to the calibration section above for an explanation of why ConIPF commissioned the enhancement of EngCon to undo arbitrary configuration decisions.

In comparison to the solution outlined there (defaults as fields), the EngCon enhancement:

• allowed the retention all decisions that were independent of the decision that was undone and

• allowed the undo of specialisation (which variant) and compositional (which subparts a component has) decisions.

The solution worked and was useful in the context of calibration.



6.3.1.2 Mindmaps

As discussed in the knowledge base section, mindmaps were used to sketch (as in to consider alternatives) the asset models and to document them. Because they have a tree structure, they can emulate feature models of the [FODA] / [FORM] / [Czarnecki] style. From the structure-based configuration perspective, they have the disadvantage that they do not clearly distinguish between taxonomy and partonomy.

Bosch used MindManager from MindJet, which is programmable and can export its mindmaps in XML format. This suggests that the models could be designed in Mindmanager and exported to EngCon. With enough effort that might be possible. One problem with the approach is that there is no round-trip capability. Changes in the EngCon knowledge base would be hard to bring into the mindmaps.

An alternative is to use the mindmaps as a start and after a certain point to switch entirely to EngCon. An XSLT processor can be used to transform the knowledge base into a readable pdf document. In that way, the documentation accounts for changes in the knowledge base. An XML-based graphics solution might be an additional possibility.

6.3.2 Derivation

The primary impression left by the Bosch experiences with respect to derivation is that conflicts hardly occurred in “production” situations. That is, when the tool was not being used to develop and test the model.

Conflicts could certainly be produced intentionally. The proper sequence of configuration decisions was often critical to avoiding conflicts. EngCon's support for modelling and controlling the configuration process was definitely an advantage.

Note, however, that the experiment used EngCon's internal configuration interface. In a real environment there could be a custom configuration interface that had the procedural knowledge hard-coded.

The inference machine showed its maturity in that it always made the proper inferences. The constraint processing was also very accurate.

6.3.3 Realisation

The most important impact of ConIPF on the realisation aspects of the development process was that the IDE could not be used and that Bosch had to “revert” to using make or custom compile scripts to build the software.



7 Experiences in Methodology Introduction

Perhaps the most fundamental insights from the experiment is that the ConIPF methodology is very extensive and therefore not particularly accessible to the uninitiated. Conversely there were very few fully initiated. Consider that:

• ConIPF combines software engineering (product lines) with artificial intelligence (structure-based configuration). ConIPF was a research project. It is quite rare to find researchers with research interests in both disciplines. Both product lines and structure-based configuration are not introductory subjects and require considerable background knowledge. Operational personnel in industry are not researchers, and the probability that they have the necessary qualifications is correspondingly less.

• ConIPF deals with strategic reuse. It requires an understanding of what can be reasonably reused in a development organisation and how. Moreover, it requires that these assets be structured and organised to be configured. Personnel that must understand ConIPF must have architectural abilities.

• ConIPF deals with tools. It rearranges the distribution of processing and repository responsibilities for conventional CASE tools and requires the integration of a new class of tool in the tool chain. The personnel that introduce ConIPF into the organisation must understand how software is produced and how the developers use the available tools to produce it.

• The methodology introduction plan focussed on training for operational personnel. It foresaw two levels of training – one for the personnel that did the feature configuration, another for technical personnel that configured the software or performed calibration.

• Training for the domain and knowledge engineers that would build the system was not considered as they were the personnel that performed the experiment, and were already trained. The experiences presented here are a synthesis of the experiences gathered from building the knowledge base.

• Another aspect of the methodology introduction that was not addressed was the events where the methodology was presented to uninitiated audiences to inform them or to gain commitment for the introduction.

• This chapter addresses the insights gained from the training that was performed, but also from this latter class of event.

• Generally, ConIPF requires an unusually large amount of discussion and explanation. There seems to be no shortcuts.

7.1 Informing for CommitmentDuring the course of the experiment, the methodology was presented by Bosch personnel

• Twice at international conferences for software engineers

• Four times at meetings of Bosch-wide networks of software experts responsible for introducing CMM key-processes into their business units



• Four times within FV/SLD. That is, for groups of software product line experts

• Twice to management

The presentations were in generally in the native language of the audience and were presented by several persons (so that the results were not correlated with an individual presenter).

In approximately a third of the cases, severe time restrictions were given – such as: up to a maximum of 20 minutes including discussion. The audiences for these presentations were homogeneous and the presentations were tailored (severely) to their strengths. Nonetheless, the presentations were in general not particularly well received. The presentations seem to have left a superficial or chaotic impression. In particular, the impression seemed to be that it was all hype. Another impression was that ConIPF is so intense, that even the experts have gaps in their expertise that severely hinder their ability to quickly assimilate the philosophy.

In the rest of the presentations lasted between 1 and 2 ½ hours. Time was taken for discussion during the presentations. Concepts were illustrated with examples. In a number of cases, the experimental system, consisting of a control unit and two notebooks for the sensor simulation and another for the HMI, was brought to the presentation. The models were examined, several complete derivations were demonstrated, the software was compiled and the system was demonstrated to have been correctly configured.

These presentations were generally considerably more successful. The methodology was accepted as a practicable and feasible. The audience seemed to be better able to translate the presentation into their individual situations.

One conclusion seems to be that short, explanatory presentations seem to be doomed to be partially successful at best. There may be good tactical reasons for giving them, however.

Interestingly, the converse seems to lead to exactly the opposite result. Comprehensive presentations with concrete examples seem to be exceptionally well accepted – by practitioners, academics and by managers. With respect to ConIPF, seeing is indeed believing.

The recommendation is that in preparing to inform, attention should be given to ensuring that all aspects of the methodology be presented and that the methodology be related to practice. A demonstrator or a prototype is invaluable.

7.2 Training for Feature ConfigurationThe CPS ConIPF system used the EngCon modelling interface for configuring features. The feature configuration tasks is intended to be performed by a project manager or a member of the sales team. The task consists of selecting the appropriate features from the feature model and storing the partial configuration in a file. The task is steered by procedural knowledge, so that the user must only perform the steps required of him.

A project manager from the CPS group was given a 1 ½ hour presentation consisting of an explanation of the ConIPF methodology and of the CPS asset models. The manager was then given a demonstration on the system and shown the configuration possibilities that would be encountered.

The manager was then given a set of simulated requirements to translate into a feature configuration. The task was performed without difficulty.



7.3 Training for Software Configuration and CalibrationThe developers responsible for software configuration and calibration also received the feature configuration training.

Additionally they received a presentation about the revised structure of the software and about the software parametrisation modalities in the configuration tool. The developers were already familiar with the parameters. The developers were then given a demonstration of running the XSLT scripts, of the changed compilation process and of the EngCon backtracking interface – for calibration.

The developers were able perform the software configuration and calibration tasks after a short practice phase.

7.4 Training for Domain and Knowledge EngineersAccording the methodology introduction plan, the domain and knowledge engineers should receive the aforementioned basic training and an intensive training covering:

• Modelling and Testing Constraints

• Programming Constraints in Java, using the EngCon GUI

• Modelling Procedural Knowledge

• EngCon Administration

• Knowledge base manipulation – import / export

• Manipulation of the knowledge base at the XML level.

The experiment personnel received 2 days general training in EngCon from Encoway The University of Hamburg visited Bosch a number of times to provide modelling support.

The experiment personnel received 1½ days training in programming custom constraints and a 1 day training in procedural knowledge.

The general experience reflects the comments at the beginning of the chapter. Everyone has gaps in their knowledge. The methodology book will provide a good reference for modelling assets and designing a derivation process.

The experimental team has some experience with feature modelling and product line architecture, but from outside the experiment. The experience does not show an unambiguous direction. Some engineers/architects model their domain very elegantly. Some use brute force. Those that tend to use brute force are often bound by the traditions of single-product development.

It is difficult to use EngCon without training, or at least accompaniment from an experienced user. Conceptual knowledge is relatively easy to model. Formulating and testing constraints is difficult without training, but relatively easy and straightforward thereafter. Programming custom constraints requires proficiency in Java and a good understanding of the EngCon GUI. The skills rust quickly without frequent practice.

The tool administration and XML skills were self-taught. The XML part was time-consuming and required a lot of experimentation as the available documentation revolved around web applications.



8 Experiment

The ConIPF methodology [Meth] defines a process for deriving a product line product from a selection of its features. It has 3 basic elements:

1. Direct derivation, which is used to obtain a viable product

2. Calibration, where the viable product is optimised for its intended use through testing its optimality and changing parameter values or exchanging components as appropriate.

3. Evolution, where no combination of the current components can meet the product requirements and new components, or combinations of components must be developed.

In direct derivation the structure-based configuration tool, containing a model of all possible features in the product line, is used to obtain a configuration, or a partial configuration of hardware and software components to be used in the product, along with any parameter values that may be associated with them. This configuration is realised by parsing it to derive any necessary configuration files and also the commands necessary to compile and link the software.

In calibration, an existing configuration is loaded into the configuration tool and and components or parameter values are changed while the values of the selected features are retained. The realisation step is repeated to obtain a runnable system.

In evolution either a feature has been demanded that is not modelled or a conflict has occured during configuration. This latter condition indicates that the features required of the product cannot be met by the existing components. The conflict is examined to determine its cause. When the necessary development actions have been determined, the appropriate components are developed and the derivation environment is updated. The product can then be derived through direct derivation.

8.1 Experiment ScopeThe goal of the ConIPF project is to define and validate a product line product derivation (application engineering) methodology that is practicable in industrial application. The goal of the experiments is to validate the methodology.

In order to do that, the expermenters must build a development environment that conforms to the ConIPF philosophy. Moreover, they must use this environment to develop products, firstly in conformance with the ConIPF methodology and secondly, that portray a representative cross-section of the variability to be found in the product family and also a cross-section of the development aspects covered by the methodology.

Applying these criteria to CPS means that:

• a number of single-application systems and a number of mixed-application systems should be developed,

• calibration should be performed and

• evolution should be performed.



Note that since the systems are all being built retrospectively, there is a keen difference between building the various single- and mixed-application systems and merely testing the knowledge base and the development environment. In recognition of the difficulty of differentiating between the two, the variants used in validating the methodology are referred to as „experiment test cases“.

The experiment will be considered a success when the experimental development environment can be used to develop a viable product, either directly or by supporting the development or adaptation of the necessary components.

8.2 Experiment EnvironmentThe experiment environment is documented in detail in [BoschKBConst]. It will be summarised here.

8.2.1 Feature Model

The CPS development environment was selected as the experiment's target. The environment is used to develop prototype embedded applications sharing a platform of ultrasonic or short-range radar sensors which detect objects close to a vehicle. Applications are developed that use this information to perform various actions. In the target environment these were:

• Parking Aid (PA) gives various levels of visible warnings on a display or audible warnings to indicate imminent collision while a vehicle is parking.

• PreSet (PS) sensitises an airbag trigger to allow quicker release after a collision

• PreFire (PF) fires a seatbelt tensioner

All applications share various „supervision ranges“ or „zones“ which are set to indicate the boundaries of various application capabilities which are based on the sensors used in the platform. In the target enviroment, the maximum of all supervision range boundaries dictates the choice of sensor configuration.

Parking aid has 3 or 4 supervision ranges which dictate the level of warning the application gives at a particular distance to the nearest object. Each zone can be configured with a display colour or warning tone, depending on whether parking aid is configured with visible and / or audible warnings. Moreover, a parking aid system can be configured to only supervise the passenger side of the vehicle, which allows the use of single-sensor solutions.

PreSet and PreFire each have two zones: the activation zone, which dictates the limit where the application starts monitoring objects, and the trigger zone, which dictates the distance to the nearest object at which the application's action will be taken. Moreover, they share a common tracking functionality, PreCrash, which, depending on the algorithm used, is unlikely, very unlikely or extremely unlikely to detect indicate an impending collision when there actually is no impending collision.

8.2.2 Derivation Environment

The following equipment was used to test the ConIPF methodology with CPS

• The configuration tool, EngCon, ran on one PC.



• The configurations were parsed with an XSLT processor to produce a compiler script, a configuration file for the EEPROM, and a configuration file for the Man-Machine Interface (HMI)

• A development CPS control unit was used with a pre-production processor running at half-speed

• Pre-recorded sensor data was played back fromthe PC with the configuration tool to the control unit over a CAN bus.

• The Control Unit sent distance information over the CAN bus which was received by a second PC. This PC ran the HMI simulation which simulated the actions taken by PA; PS & PF.

8.3 Experimental ProcedureThe experiment proceeded in 4 stages, which were dictated by a combination of technology and learning curve.

8.3.1 Direct Derivation

In the first stage, the knowledge base was filled with the conceptual knowledge, the constraints and the procedural knowledge, practically in that order with no overlap. The last step occurred considerably after the first two, as several attempts at modelling procedural knowledge independently failed and everyone had to be trained by EncoWay.

During and after each step, test cases were executed and the partial configurations were tested to ensure the correctness and consistency of the knowledge base and of the configuration itself.

8.3.2 Calibration

After the demonstration environment had been developed, the changes in the parameter settings could be tested to ensure that the resulting systems displayed the behaviour dictated by the settings.

8.3.3 Evolution

When EngCon encounters a conflict, the only action allowed was to take back the last step and take a different one. After the conflict occured, it was usually possible to examine the constraint net and determine the constraint the caused the conflict.

Bosch performed a series of tests with pro-active evolution. That is, with features defined to have a greater parameter range than the capabilities of the available components would allow and with generic components that fulfilled those extended ranges.

Then, when a parameter value was selected that exceeded the capabilities of the available components, the generic component would be selected. The resulting configuration with a set of generic components would indicate that the real components would have to be developed that met the capabilities required of the generic components.

8.3.4 Processors and Processes

The SRR (prototype) development platform, which was used as the basis for the experiment, is a single-processor system. That is, the control unit has a single processsor.



At the time that the experiments were defined, the AMPL-M did not explicitly accomodate multi-processor / multi-process systems. This situation was adequate for the SRR platform, but was neither adequate for more advanced CPS applications (which were defined after ConIPF's start) nor for more general IT applications.

The experiment environment was extended with the architecture of a later version of the CPS platform which allowed multi-process / multi-processor applications in order to explore the ramifications of these considerations.

Knowledge Base Extensions

As illustrated in Illustration 19, the taxonomy was extended with a new asset type (process) and a new hardware type (processor) was added.

A CPS product now contains two application processes; PreCrash and ParkingAid, a SensorFusion process, which synthesises a list of objects in the vehicle periphery and a SystemProcess. The SensorFusionProcess contains a tracking module that was extracted from the common module and the COI modules. The SystemProcess is composed of the main module and the common module.

A control unit can contain a microcontroller or microcontroller and a DSP processor whereby the SensorFusionProcess runs on the DSP and the other processes run on the microcontroller. In other words, when the application load becomes too great (specifically: when both PreCrash and ParkingAid are selected), the load on the microcontroller is reduced by adding a DSP in the control unit and running the SensorFusionProcess on it.

The PreCrash Process consists of the PreCrash module, the PreSet module, the PreFire module or both PreSet and PreFire.


Illustration 19: Extended CPS Taxonomy

Extended CPS Taxonomy

Asset

Context

Feature

Artefact

Hardware

Audio

Control Unit

Display

Sensor configuration

ProcessorMicrocontroller

DSP

Process

SystemProcess

SensorFusionProcess

PreCrashProcess

ParkingAidProcess

Software

Application Module

Tracking

COICOI 1D

COI 2D

Common

Main

PreCrash Module

Product


Illustration 20 presents the extended CPS partonomy model.

8.4 ExperimentsThis section documents the experimental test cases used in validating the ConIPF methodology using the CPS environment.

In practice, the test cases had the goal of testing one aspect, but consisted of building running software and verifying the desired product attributes or properties.

8.4.1 Direct Derivation

In direct derivation, all components and information necessary to build a viable product are already present. The methodology is valid when realistic products can be derived from the feature configuration. The feature configuration may still allow various alternatives with respect to components or parameter values which must be resolved before the product can be built, but when the configuration tool is used to resolve these alternatives the resulting configuration must be viable, consistent and correct.

Validating the methodology with respect to direct derivation consisted of testing various combinations of the basic applications and their variants, as exhibited through the various options. Appropriate viable components and paramter values, especially for the software components, were chosen using the configuration tool. Table 1 presents the test suite.


Illustration 20: Extended CPS Partonomy

Extended CPS Partonomy

Product

has context

has feature

has hardware

Sensor configurationhas Parts Processor executes Process has Parts Software

has Parts Interface

Control unithas Parts Processor executes Process has Parts Software

has Parts Interface

Audio has Parts Interface

Display has Parts Interface

has software


8.4.2 Calibration

Calibration presents the case where the configuration resulting from direct configuration is changed to optimise the product with respect to particular criteria. The methodology is valid when a product configuration that resulted from a feature configuration and alternative resolution using the configuration tool is changed using the configuration tool and the resulting configuration has the same feature configuration and can be used to build a viable product.

Basically, this is equivalent to testing whether backtracking works in the configuration tool. The validation is therefore largely dictated by configuration technology. There are 3 types of backtracking:

1. Changing a concept's attribute value

2. Changing the concept to another instance of the same class

3. Changing the compositional relationships.


Table 1: Direct Derivation Experiments

PreCrash ParkingAssistancePreSet PreFire Sym Aud Disp Imminent Very Near Near InProximity

Case P(wr

ong)

Activ

ation

(cm)

Trigg

er cm

)

Activ

ation

(cm)

Trigg

er (c

m)

Dept

h (cm

)

Tone

Colou

r

Dept

h (cm

)

Tone

Colou

r

Dept

h (cm

)

Tone

Colou

r

Dept

h (cm

)

Tone

Colou

r

Simple PreCrashShallow PreSet Long unl. 900 300Shallow PreSet Long unl. 900 50Deep PreSet Long unl. 1800 300Shallow PreFire unl. 900 5Deep PreFire unl. 1800 5Deep PresSet Deep PreFire unl. 1800 300 1800 5Deep PreSet Shallow Prefire unl. 1800 300 900 5PreCrash 2D Very unl. 1800 300 1800 5PreCrash 1D + 2D Ext. unl. 1800 300 1800 5

Simple Parking SupportPassenger 3 Zone US Pass Buzz 30 Cont 50 Long 80 ShortPassenger 3 Zone SRR Pass Buzz 80 Cont 120 Long 180 ShortPassenger 4 Zone SRR Pass Buzz 80 Cont 120 Long 180 Short 280 BeepBoth 3 Zone SRR Both Buzz 80 Cont 120 Long 180 ShortBoth 3 Zone Forced SRR Both Buzz 30 Cont 50 Long 80 ShortMixed Tones Both Buzz 80 Short 120 Long 180 ContLoudspeaker Both Loud 80 Cont 120 Long 180 ShortRadio Both Radio 80 Cont 120 Long 180 ShortDisplay 3 Zone Both S. TFT 80 Red 120 Orng 180 YellDisplay 4 Zone Both S. TFT 80 Red 120 Orng 180 Yell 280 GrnMixed Colours Both S. TFT 80 Orng 120 Yell 180 GrnLarge TFT Both L. TFT 80 Red 120 Orng 180 YellNavi Both Navi 80 Red 120 Orng 180 Yell3 Zone Dual Signal Both Buzz S.TFT 80 Cont Red 120 Long Orgn 180 Short Yell4 Zone Dual Signal Both Buzz S. TFT 80 Cont Red 120 Long Orng 180 Short Yell 280 Beep Grn

Mixed PreCrash and Parking SupportPreFire, Parking, US unl. 95 5 Pass Buzz 30 Cont 50 Long 80 ShortPreFire 3 Zone Parking SRR unl. 800 5 Pass Buzz 30 Cont 50 Long 80 ShortPreFire 4 Zone Parking unl. 800 5 Both Buzz 80 Cont 120 Long 180 Short 280 BeepPreSet 3 Zone Parking unl. 900 300 Both Buzz 80 Cont 120 Long 180 ShortPreset 4 Zone Parking unl. 1800 300 Both Buzz 80 Cont 120 Long 180 Short 280 BeepPreCrash 1D + 2D, 4 Zone Parking ext. unl. 1800 300 800 5 Both Buzz S. TFT 80 Cont Red 120 Long Orng 180 Short Yell 280 Beep Grn


Attribute value change

Validating attribute value change basically consists of changing the configurable parameters associated with the software components.

Validing the attribute value change consists of changing the TTI_send_ms (The TimeToImpact that triggers the PreSet Message on the system bus) of the PreSet Module from 20 ms to 100 ms, for example and it could be seen that the constraint mechanisms changed to TTI_Activate_ms value accordingly. Another example: Changing the PARKINGAID_TP_Y parameter (which smooths the signal and shortens or lengthens the reaction time) of the parking module was changed from 100 cm to 130 cm.

Changing Instances of a Class

Validating instance changes consists of replacing a valid variant of a component with another valid variant of the component while preserving the feature configuration.

There are not so many instances of such situations in the CPS model. The depth of the activation zones for PreSet or PreFire were set to under 10 meters so that both SRR sensor configurations were valid. Validating the instance change consisted of replacing the SRR sensor configuration with a 10 metre depth with the sensor configuration with the 20 metre depth.

Changing Compositional Relationships

Validating compositional changes basically consists of exchanging a valid part with another part or changing the number of parts (there are other compostional relationships than „has-parts“, but the idea remains the same.).

Validating compositional changes in CPS consisted of changing the parking assistance display from the small TFT to the Navi adapter. Another validation case was changing the audible device from a buzzer to a radio adapter.

Strictly speaking, the validation was invalid as the display and audible devices were modelled as features. Changing them would therefore mean changing the feature configuration. Although this breaks the rule of the methodology, it does not break the spirit, as it is possible to absract the attributes of the devices as features and model the devices themselves as components.

Also, strictly speaking the compositional relationships also dictate the number of sub-parts a part can have. Not trying this case does not invalidate the methodology, it just weakens the testing of the knowledge base.

8.4.3 Evolution

Evolution presents the case where the capabilities demanded by the customer exceed those offered by the available components. Evolution could not be fully tested at Bosch, as the CPS target environement was based on SRR technology, which had been discontinued. There were neither sufficient test data nor concrete development activities resulting from new requirements on the platform.

The methodology outlines two alternative approaches to evolution: proactive and reactive. The first tries to anticipate new requirements and the second accomodates concrete new requirements after they have been received. The configuration aspects of the two approaches were examined briefly.



Proactive Evolution

Two cases were used to validate proactive evolution:

1. In the knowledge base, the single-sensor configurations were limited to a supervision depth of 3 metres. A generic single-sensor configuration with an arbitrary supervision depth of 20 metres was inserted and all parking support ranges were adjusted accordingly. Setting the ranges to more than 3 metres would then include the generic sensor configuration in the configuration which then could be developed.

2. Similarly, a generic COI was defined, which had an unspecified error rate.

Reactive Evolution

The original intention was to allow the feature attribute values to be unconstrained. Impact analysis could be performed by setting them to unforeseen values and letting conflicts fire. The point of evolution woud be indicated by the source of the conflict.

Unfortunately, since the configuration tool only allowed monotonically decreasing constraints, it was not possible to define features that have attribute ranges that exceed the capabilities of defined components without breaking the connections (constraints) to those components.

Without those constraints it was not possible to do any sensible impact analysis on the new requirements.

8.4.4 Processors and Processes

The processors and processes model was validated by repeating the direct derivation experiment cases (Table 1). The partial configurations were checked by hand that they specified the appropriate modules and parameter values.



9 Results

9.1 Direct DerivationAll cases from Table 1 resulted in running, viable products.

9.2 CalibrationAll cases resulted in running, viable products

9.3 EvolutionThe cases were performed successfully. It must be noted, however, that

1. It must be possible to model the new requirements in advance. The approach is no help for unforeseen functionality.

2. The solutions must be modelled in advance. Moreover, when a requirements can be fulfilled with different solutions, then all alternatives must be modelled and criteria must be developed in advance to decide between them.

9.4 Processes and ProcessorsAll cases resulted in running, viable products



10 Summary and Conclusions

Bosch applied the ConIPF methodology to an industrially-realistic software development process. It was able to successfully derive, calibrate and evolve the product software and install it in product hardware platform.

The derivation process used a commercial configuration tool and integrated with a production tool environment. The configuration tool's core functionality was robust and mature. It had a number of strengths, but also a number of shortcomings in the experimental environment. The tool will have to be developed considerably further to allow its seamless integration into software development environments.

The experiment used a proprietary configuration front-end and internal modelling environment. Both were functional and the configuration front-end could conceivably be used by end-users. The modelling environment should be enhanced to support parallel and distributed modelling as well as the visualisation of vast numbers of concepts and constraints.

The methodology spans two quite separate disciplines and requires a deep understanding of all aspects of a product line development process from platform engineering to (individual) product development, from abstract architectural aspects to concrete realisation aspects, such as tooling. The need for education is immense as is the potential for misunderstanding and miscommunication. The introduction of the methodology must be rigorously planned and executed.
