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
Top Related