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, 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 – 2000Control 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 Control Engineers Software Engineers Experiences: Relation between control and SW engineers Requirements Analysis Architecture Design Module/ Algorithm Design Implemen- tation Module Test Integration Test Acceptance Test Handing over printouts 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: implementation As 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 technically oriented business oriented requirements analysis Clarification: Two requirements analysis paths requirements elicitation functional reqs (first version) non-functional requirements (first version) analysis of functional reqs analysis of qualities functional specification driving qualities architecture design

Slide 17 requirements analysis Clarification: Design viewed as an optimization problem analysis of functional reqs analysis of qualities 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 requirements in control system design Early introduction of plant models Consistency of models on different refinement levels, automatic transformation possible?

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