On the relation between software development and control function development in automotive

embedded systems

Stefan Kowalewski

Embedded Software Laboratory(Chair Informatik 11)

RWTH Aachen University

ARTIST Workshop “Beyond AUTOSAR”, Innsbruck, 23-25 March 2006

Slide 2

Introduction

• Observation: Software and control function development currently not smoothly integrated.

– Technical issues• Missing bridge between software and control design models and tools

– “Soft” issues• Different culture, traditions

• Misapprehensions about roles in the development process

• Some even think software and control function design are the same.

• Model-based Design approaches will require a better integration of both disciplines

• Aim of the talk :– Share experiences

– Discuss approaches to improve integration

Slide 3

Outline

• Background

• Experiences

• Desiderata

• Approaches

• Conclusions

Slide 4

Background (1)

• Short bio– 2000 Control engineering, Universities Karlsruhe/Dortmund

2000 – 2003 R&D Robert Bosch GmbH, software technology

2003 – Computer science, RWTH Aachen University

• My background when entering industry:– Control theory, control engineering

– Discrete event systems, hybrid systems theory

– Formal verification (model checking)

• Main work topics:– Software engineering

– Software architecture design and analysis

– Software re-use, variability management

– Safety and reliability of software-intensive systems

Slide 5

Background (2)

• Much higher interest in “soft” topics (company-wide, also by management)

• Most pressing (cost) problems have been caused by software development issues (requirements, variability, re-use, etc.), not by control function development

• Automotive supplier industry is well experienced in developing new functionality up to prototype and first customer level.

• Problems start when additional customers with different requirements must be served and software qualities become important.

• “Hard” methods were not in the focus– Control design is considered as being mastered

– Formal verification was not of interest

Slide 6

Background (3): Architecture Analysis Workshops

• One of the main tools at that time to cope with software issues

• Idea:– Software quality is mostly determined by architecture

– Analyse early whether the SW architecture supports business-relevant quality requirements

• Basis: “Architecture Trade-Off Analysis Method” (ATAM), Software Engineering Institute, Pittsburgh

• Workshop format

• Participants: Marketing, Architects, Developers, Testers, Evaluators, if possible Management

• Steps: Identifying and refining business goals, brainstorming scenarios, play scenarios in architecture, identify critical points

Slide 7

Outline

• Background

• Experiences

• Desiderata

• Approaches

• Conclusions

Slide 8

Experiences from architecture analyses in business units

• Requirements management– Changes of architecture-relevant requirements late in projects

• Communication between marketing and development– Business goals unknown to architects

• Organizational structures do not fit any more– Domain-crossing functionalities

• Re-use, handling variability of products– 1500 variants of gasoline engine control systems sold per year

– Re-use concepts did not fit market requirements

Slide 9

Experiences from architecture analyses in business units (2)

• No cost models for software– No lifecycle cost considerations

– Product prices determined by hardware

– Hardware was fixed before software development began

• Permanent misunderstandings between control and software engineers

Slide 10

ControlEngineers

SoftwareEngineers

Experiences: Relation between control and SW engineers

RequirementsAnalysis

ArchitectureDesign

Module/Algorithm

Design

Implemen-tation

Module Test

Integration Test

Acceptance Test

Handing overprintouts of ASCET

or SIMULINK designs

Slide 11

How control and SW engineers see each other

• Control engineers:– System structure (trivial) and algorithms (difficult)

follow from control requirements should be designed by control engineers

– Remaining task for software engineers: implementationAs a consequence: responsibility for software quality

• Software engineers:– Control engineers already botch it up in the architecture

– System structure has to follow from „non-functional requirements“ should be designed by software engineers

– Architecture design is challenging, algorithm design is trivial

– Computer-aided control design tools (incl. autocoding) are used to avoid software engineering considerations

Slide 12

Outline

• Background

• Experiences

• Desiderata

• Approaches

• Conclusions

Slide 13

Desiderata

• Better understanding between software and control engineers

• At least: Sensitivity for different challenges

• Methodologically:– Early consideration of software requirements in control design

– Early integration of control requirements into software requirements

Slide 14

Outline

• Background

• Experiences

• Desiderata

• Approaches

• Conclusions

Slide 15

First step: Clarification of goals and responsibilities

• For control engineers:– There is more to the quality of control software than correct

functionality and good control loop performance.

• For software engineers:– Control function design at its core is not a software design problem.

– Closed loop dynamics are a challenge of ist own.

• Helpful for creating better understanding by control engineers:

Strict separation between non-functional and functional requirements or properties

Teaching?

Slide 16

technicallyoriented

businessoriented

requirementsanalysis

Clarification: Two requirements analysis paths

requirementselicitation

functional reqs(first version)

non-functional requirements(first version)

analysis of functional reqs

analysis ofqualities

functional specification

drivingqualities

architecturedesign

Slide 17

requirementsanalysis

Clarification: Design viewed as an optimization problem

analysis of functional reqs

analysis ofqualities

functional spec= optimization

constraints

driving qualities= optimization

criteria

design= optimization

Find best or good enough solution (measured by qualities) among all admissible solutions (given by functional spec.)

Slide 18

Example for preparing software engineers:Course „Dynamic Systems for CS students“

• Signals– mappings from time to value, no matter whether domain and co-domain are discrete,

continuous or hybrid

• Systems– mappings from input signal space to output signal space

– State as a general concept for representing dynamics automata, cont. state space, hybrid systems

– Linear systems

• Analysis– General properties: Causality, controllability, observability, reachability, stability

– Continuous systems: Frequency domain analysis, time domain analysis

– Discrete systems: Temporal logic, model checking

– Hybrid systems: reachability

– Simulation (integration of ODEs, DES simulation)

• Design– Continuous systems: Linear controller design

– Discrete systems: Supervisory control synthesis, game theoretic methods

Slide 19

Research: ZAMOMO-Project

• Integration of model-based software and model-based control system design

• Partners:

– Embedded Software Laboratory, RWTH Aachen

– Control Engineering Institute, RWTH Aachen

– VEMAC GmbH

– AVL GmbH

– Fraunhofer-Institute for Information Technology

• Started this year

Slide 20

Vision of ZAMOMO: Integrated model-based development

Requirements Model

Specification Model

Simulation Model

HiL Model

Implementation

?

?

Plant model

Plant model refined

Plant

Early consideration of non-functional requirementsin control system design

Early introduction ofplant models

Consistency of models on different refinement levels,

automatic transformationpossible?

Slide 21

Outline

• Background

• Experiences

• Desiderata

• Approaches

• Conclusions

Slide 22

Conclusions

• Challenge: Bridging the gap between software and control development

• Technical issues:– Connecting software models and tools with control design models

and tools

• Soft issues: – Clearer reference model for roles of software and control designers in

the development process

– Preparation for the cooperation of both disciplines by appropriate teaching