Continuous Integration of service applications

Informationstechnik München

Excellence in Automotive Computing.

IFS Informationstechnik GmbH Trausnitzstraße 8 81671 München Sitz: München Registergericht: Amtsgericht München HRB 126547 Geschäftsführer: Dr.-Ing. Markus A. Stulle Dipl.-Ing. Thomas Frey

Continuous Integration

of service applications

Automotive Diagnostic Systems 2013 Dr.-Ing. Markus A. Stulle

IFS Informationstechnik München

Company and self-conception

 Founded in 1999, 50 employees

Portfolio: automotive engineering, cybernetics, development tools, process tools.

Since 2011 member of ASAM e.V.

 Supplier of the BMW Group since 2000

 “The best way to predict the future is to invent it.” (A. Kay)

Current priority: mobile applications based on Microsoft Windows Phone – “Mobile first!”.

ADS 2013

Continuous Integration

of service applications

 What is software quality?

 From discrete integration

to Continuous Integration (CI)

 Process tool Prometheus

 Test framework Anubis

of Serviceplattform Taurus®

 Vehicle emulator Virgo

What is software quality?

- indirect definition required

 Cross-disciplinary definition of errors by Martin Weingardt:

“In the face of an alternative, a subject understands the variant as error which - in terms the correlating context and a specific interest – is regarded as so disadvantageous that it appears to be undesirable”.

 Software quality

 Use cases are fulfilled without errors

 Application gives a positive user experience  Efficiency in operation and maintenance.

ADS 2013

What is software quality?

- corollary

 Implementation free of errors

not sufficient to achieve high software quality!

 Timely provision of proofs of concept as

primary objective (“speed is the essence!”)

 Metrics for source code

 Suitable for an one time only “accuracy check”,

e.g. for the evaluation of offshore providers

 Unsuited for continuous quality management,

Error-free authoring of source code

- collaboration

 “Pair programming ” - two persons work together on the same

function in one session at one computer

 Higher likelihood that technical and functional errors

are recognized thanks to mutual monitoring

 Can make component test dispensable!

 Disadvantages: personnel placement is at least doubled,

asymmetrical cooperation, little acceptance among employees!

 Groupware solution Collabode (MIT CSAIL) makes it possible to

ADS 2013

Error-free authoring of source code

- component tests

 Testing of the implementation of a software component F

with a defined function call f(x)

 Test scenarios T: Function arguments x have to cover

the co-domain as completely as possible

 Development of mock-ups laborious, comparison between

the expected and the actual results of the functions requires the knowledge and abilities of the developer of F

 According to the best practice the development of the

component and the test is carried out in disjunctive groups  Contradicts the demand for a short cycle time!

Causes of software errors

- lack of knowledge

 Errors occur, because

 … some use cases haven’t been identified yet  … the paradigm or the technology is new  … some facilities of the platform are unknown  … the documentation is insufficient.

 … because there is a lack of knowledge

ADS 2013

Software for service applications

- axioms

 Crisis of acceleration

All software projects suffer from  Missed deadlines

 Pressure to be innovative:

Mobile gadgets set the pace!

 Nobody makes mistakes due to want of care!

 All speak the same language

 Example “Taurus® spoken here”

Strategies for high software quality

- process models

 Software engineering, here: V-model

 Basic approach: Once everything has been written down,

ADS 2013

 Objective

to meet requirements precisely

 Procedure

listing of all requirements, modeling of use cases, systematic elaboration of concepts

 Characteristics

 Division into specification stage and implementation stage  Sequential development:

concept - specification - implementation - integration - testing

Process models

- V-model (I)

 Disadvantages

 Strictly sequential: Defects, flaws, technological obstacles

won’t be detected until implementation or testing

 In the time between proof of concept and system integration,

the platform has often been developed further

 Merging of development

outputs takes place at a singularity

(“big bang integration”)

Process models

- V-model (II)

ADS 2013

Process models

- Simultaneous Engineering (I)

 Objective

early detection of flaws in the specification

 Procedure parallel stages  Characteristics

 Early implementation of development outputs  Mutual exchange

between the stages

concept / specification

implementation / integration system testing

Process models

- Simultaneous Engineering (II)

 Discrete Integration

successive merging of development outputs

integration planning

integration

production

review

integration

candidate 1 candidate 2 integration candidate n integration candidate release

…

system test

ADS 2013

Discrete Integration

- revision control

Discrete Integration

- disadvantages

 Implementation adheres strictly to the integration planning,

little scope for individual initiative

 It‘s difficult to determine the causes of errors via system

testing, since integration merges many different branches  Quantity structure of a service application “software repair”

 394 software modules over 2 million lines of source code

 265 test cases of system tests,

6477 test cases of regression tests in 40 test plans

 Software components

ADS 2013

Continuous Integration

- concept

 Objective to identify the origins of errors!  Procedure

abandon the use of development branches, timely integration of changes on all trunks

 Characteristics

before each commit: production, installation and system testing

 At all times a state in which of

products are error-free and ready to be deployed

 J. Humble, D. Farley “Continuous Delivery: Reliable Software

Continuous Integration

- requirements and components

 Definition of an integration product

 Process tools for FMEA data base and risk assessment

 Automated production

 Production of software components is replicable thanks to

assembly according to bill of materials

 Automated distribution

and installation on target platform (“delivery”)

 Automated selection, execution and interpretation

ADS 2013

Continuous Integration

- evolutionary steps

 Introduce an issue for error correction

or functional enhancement

 Changes of source code strictly adhere to the issue  Production of the correlative packages

 Process tool calculates system tests based on

the FMEA data base of the changed source code modules  Mounting of test constructions within the test framework,

performance and evaluation of relevant system tests

 Commit of the changed modules

Process tool Prometheus

- FMEA data base

ADS 2013

Process tool Prometheus

Process tool Prometheus

- definition of use case

• Use case requires a basic function

• Functions are effected by source code modules

• Modules are items of the bills of material

ADS 2013

Process tool Prometheus

- Risk assessment of a project

• Radar charts facilitate the comparison of risks

• Execution duration of the system tests due to be executed is known

• Question“ Can the

functional enhancement be released in the

maintenance window?” can be answered easily!

Service application

- roles of the operator

 Role R₁ – functioning as an actuator

 Control variables of the application are communicated via the

user interface, e.g. in form of a text display “Turn the steering wheel to straight-ahead position!”

 Role R₂ – functioning as a sensor

 The discrete measurands determined by the operator are also

communicated via the user interface, e.g. by pressing a button.

 Role R₃ – functioning as a selector

ADS 2013

Control system of service application,

vehicle, VCI and operator

 Challenge: Roles R₁, R₂ and R₃ of the operator are carried out

Control system of service application,

test framework Anubis and replicas

 Roles R₁ and R₂ from the operator model,

ADS 2013

Test framework Anubis

- implement system test case (I)

• Implement system test: substitute Role R₃ in ISOM/L

• Prepare tracing of operating record

Test framework Anubis

- implement system test case (II)

• Implement system test: assume Roles R_1,2

• Operating records – link situations and user input in the FMEA data base

• Reproduction by Anubis in the automated

ADS 2013

Replicas for system tests

- vehicle emulator Virgo

 Discrete event dynamic system (DEDS) models

for control units taken from a “clean room approach”  Petri net as the form of modeling permits concurrency

 Emulation also replicates the electrical system of the vehicle

and the sensors

 Hybrid emulation: Integration of CAN bus hardware

allows gradual transfer to real vehicle

 Replica of vehicle communication interface, e.g. SAE J2534.

 Emulation description can be generated by Taurus®

Vehicle emulator Virgo

- example plug-in hybrid Durango

• 18 control units,

diagnostic protocol UDS

• Vehicle access via ePlanet® , LTE and K-Line (ISO 9141) • Service application based on ASAM/MCD • Challenge: software updates “anywhere”!

ADS 2013

Virgo-GUI

- start of emulation (I)

• Virgo-GUI uses Virgo as well as Anubis via web service interface

• Interactive preparation of test scenarios

Virgo-GUI

ADS 2013

Virgo-GUI

Vehicle emulator Virgo

- enhancement “Reality Engine”

• CVDS models for components, e.g. seat heating

• DEDS models for driver, e.g. temperature perception

• Parameters and events can be controlled by the test

ADS 2013

Vehicle emulator Virgo

- petri net of control unit INSTRUMENTS

• Concurrency:

firing of T₆ puts tokens on E₁ and F₃

• Behavior of transitions can be controlled via web service at runtime

• Even complex service situations can be constructed by

Vehicle emulator Virgo

- control unit memory model (I)

• Service situations: control unit memory model allows replication of defective memory cells

ADS 2013

Vehicle emulator Virgo

- control unit memory model (II)

• Software logistics:

Virgo can associate memory contents with applications

Vehicle emulator Virgo

- control unit memory model(III)

• System dynamics:

time behavior of model is configurable

ADS 2013

Process tool Prometheus

- select system tests (I)

use cases

test coverage

Process tool Prometheus

- select system tests (II)

• FMEA data base provides prognosis for overall duration of the system test cases

ADS 2013

Process tool Prometheus

- select system tests(III)

• Presentation of reduced test coverage in tree map

Process tool Prometheus

- execute system tests

• Parallel execution in test case groups with up to 5 vehicles

• Emulations are

individualized by Anubis, e.g. by setting a VIN

• Values of performance criteria are automatically computed and compared to former system tests

ADS 2013

Continuous Integration

- best practice

 At the very beginning: define an integration product,

automate production, distribution and installation

 Build a FMEA data base,

link use cases and system tests

 Provide replicas for operator and vehicle

 Implement system tests

 Develop functional enhancements within issues

 The commit of source code changes

We are looking forward to seeing you

at our exhibition stand!

 taurus@ifs-it.de, virgo@ifs-it.de, Tel.: 089 – 45 09 83 - 0  kontinuierliche-integration.de, continuous-integration.org © M ich ae l N ag y, Pre ss eam t M ün ch en