On the relation between software development and control function development in automotive embedded...
-
Upload
horace-copeland -
Category
Documents
-
view
214 -
download
0
Transcript of On the relation between software development and control function development in automotive embedded...
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