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

1. 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

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

3. Outline • Background • Experiences • Desiderata • Approaches • Conclusions

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

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

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

7. Outline • Background • Experiences • Desiderata • Approaches • Conclusions

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

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

10. Experiences: Relation between control and SW engineers SoftwareEngineers RequirementsAnalysis Acceptance Test ControlEngineers ArchitectureDesign Integration Test Module/AlgorithmDesign Module Test Handing overprintouts of ASCETor SIMULINK designs Implemen-tation

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

12. Outline • Background • Experiences • Desiderata • Approaches • Conclusions

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

14. Outline • Background • Experiences • Desiderata • Approaches • Conclusions

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?

16. Clarification: Two requirements analysis paths technically oriented business oriented requirements analysis requirements elicitation functional reqs(first version) non-functional requirements(first version) analysis of functional reqs analysis ofqualities functional specification drivingqualities architecturedesign

17. Clarification: Design viewed as an optimization problem requirements analysis analysis of functional reqs analysis ofqualities functional spec= optimizationconstraints driving qualities= optimizationcriteria design= optimization Find best or good enough solution (measured by qualities) among all admissible solutions (given by functional spec.)

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

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

20. Vision of ZAMOMO: Integrated model-based development Early consideration of non-functional requirements in control system design Early introduction ofplant models Requirements Model ? Consistency of models on different refinement levels, automatic transformation possible? Specification Model ? Simulation Model Plant model HiL Model Plant model refined Implementation Plant

21. Outline • Background • Experiences • Desiderata • Approaches • Conclusions

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