introducing software product lines in model-baseddesign processes: an industrial experience

WICSA 2016 – Venice, Italy – April 7th

Introducing Software Product Lines in Model-BasedDesign Processes: an Industrial Experience

Domenico AmalfitanoVincenzo De SimoneAnna Rita Fasolino Mario Lubrano

Stefano Scala


Context◦ Automotive software development process

adopted in FCA Software Factory Motivation

◦ Improve efficiency of this software development process

Proposed Solution◦ Introduction of a Software Product Lines

approach for (semi)automatically producing Product Architectures starting from specification documents


Variability of the Automotive Domain● 222 different vehicle models available in

US in 20151

◦ 43 of these were newly introduced models● Tailoring of vehicles models due to

◦ Customers requirements◦ Cultural preferences◦ Different Laws

● Impacts on features provided by cars, such as:◦ Safety functions ◦ Driving Assistance systems

1 http://ww.statista.com/statistics/200092/total-number-of-car-models-on -the-us-market-since.1990/


Complexity of Automotive Embedded SoftwareMore features provided by electronics an software

◦ Increasing in the number of Electronic Control Units (ECUs) networked through the body of the car


Complexity of Automotive Embedded Software - 2Complexity of automotive embedded software increases

Excerpt of http://www.informationisbeautiful.net/visualizations/million-lines-of-code/


Variability Management Issue●Variability must be managed to avoid

that the same functions are developed several times

◦Case-by-case basis or opportunistic reuse strategies are adopted• Error prone• Not efficient

◦More systematic reuse approaches need to be introduced


Software Product Lines (SPL) ●SPL are a well-know solution for

handling variability and complexity of software development ◦ “A software product line is a set of

software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” 1

1 P. Clements and L. Northrop, Software Product Lines: Practices and Patterns.


Considered Industrial Context●FCA Software Factory (SWF) devoted to

the development of application software ◦ for Instrument Panel Cluster (IPC) ECUs. ◦exploiting Model Based Design (MBD)

process


Adopted Software Development Process Issues1. No systematic reuse strategies

applied◦ Exploitation of clone-and-own and copy-

paste-modify approaches when there is the need to implement same or very similar features for each new vehicle model

2. Difficulties in propagating modification or bug-fixing involving common parts of different software

◦ Need of traceability links between these software


Introduction of SPL in the adopted software development process


Proposed solution●Introduce SPL in the SW Architecture

and Design Phase◦ For the (semi)automatic generation of

Product architectures (PA): tailored for specific vehicle models, starting from the specification documents, defining a Feature Profile (FP) to specify

the features to provide and the values for configuring them.

relying on a SPL infrastructure, named AutoMative.


The introduction of SPL in FCA ●To introduce the SPL we executed

two processes:◦Domain Engineering Process

for developing the SPL infrastructure

◦Application Engineering Process for generating the IPC software products by exploiting

the SPL infrastructure


Domain Engineering ProcessIdentify the IPC features and define

its Product Line Architecture (PLA) that represent the design that is common to all SPL products

Execution of 4 activities:1. Identify Features2. Design PLA3. Define Extraction Rules4. Develop the SPL infrastructure


1. Identify FeaturesFor defining the IPC Feature

Model

◦ Identification of the main features of the IPC and the relationships among them by manually analyzing specification documents of multiple vehicle models. Specification documents in Excel and

Word format


2. Design the PLAThe IPC PLA was designed as a

composition of configurable MATLAB/Simulink (MS) models (Additive approach)◦ For each identified feature, a MS model

was defined in terms of: Its composing parametric subsystems and

their Variation Points (VP)s The configurable interconnections among

these subsystems The rules to instantiate and configure both

subsystems and their interconnections


2. Design the PLA – the followed approachFor defining the configurable

subsystems we: ◦ Analyzed the specification

documents◦ Performed a reverse engineering

process to extract reusable models from existing

architectural models


3. Define the Extraction RulesNeeded to produce a FP starting from

Excel specification documents of a given vehicle model.

They define how to identify Feature VPs and extract their values and how to map them in the FP

They were defined executing reverse engineering process on different kinds of specification documents


3. Define the Extraction Rules – An example

Excerpt of Specification Documents

Excerpt of Feature Profile


4. Develop the SPL Infrastructure AutoMative●To support the automation of the

Application Engineering process●The Infrastructure should:

◦handle the defined PLA, the configurable subsystems, the extraction and the transformation rules

◦produce PA tailored for a specific vehicle model


Application Engineering Process●It relys on the execution of 2

activities◦Definition of the FP • automatic generation of FP if the specification

documents comply with the models obtained in the Extraction Rules Phase

• need manual effort on the contrary◦Generation of the PA

generate the MATLAB/Simulink model by instantiating and configuring the needed parametric subsystems and their interconnections


Application of the Proposed ApproachApplication of the approach for obtaining the IPC PA tailored for the Fiat Tipo in a decoupled project

●Initialization of AutoMative Infrastructure by defining the PLA and by implementing the parametric subsystems related to the identified main features

●Definition of the FP according to the specification documents related to the Fiat Tipo

●Generation of the PA by instantiating and configuring of the subsystems according to the produced FP


Application of the Proposed Approach - 2

Feature#

Implemented Parametric Subsystems

# Identified Variation

Points

# InstantiatedParametric Subsystems

# Filled Variation

Points

F1 18 93 40 164

F2 17 76 124 418

F3 13 104 208 1664

F4 3 196 3 196

We considered a subset of 4 main features of the IPC


Application of the Proposed Approach - Costs Domain Engineering Process

◦ Six man-month for developing AutoMative

◦ Eleven man-month for the initialization of the infrastructure

Application Engineering◦ Tens of seconds to generate the FP when

no further manual filling is needed, hours otherwise

◦ Minutes for generating the PAs


Application of the Proposed Approach - Discussions SPL introduced without impacts on

the entire development process The produced PAs can be processed

by the code generation tools Improvement in the development of

the architectural models: ◦ current development practices:

several weeks◦ exploiting AutoMative: hours

less MATLAB/Simulink design skills required


Conclusions We introduced a SPL approach in the SW

Architecture and Design phase of the software development process adopted in FCA SWF

We developed an SPL infrastructure aimed at semi-automatically producing IPC PAs tailored for vehicle models

We applied the approach and the infrastructure to develop IPC for the Fiat Tipo in a decoupled project showing its feasibility


Future Work Integrate the infrastructure with the

other tools adopted by the company devoted to the configuration and change management

Application of the SPL paradigm to the other software development phases

◦ Requirements◦ Testing


Thanks for your attention

Questions?

Further Information:http://reverse.dieti.unina.it

@REvERSE_UNINA

[email protected]

https://twitter.com/REvERSE_UNINA

mailto:[email protected]

mailto:[email protected]