Engineering for Automotive Systems: A Roadmap Alexander Pretschner, Manfred Broy, Ingolf H. Krüger, Thomas Stauner

Alexander Pretschner is a senior researcher at ETH Zürich,

Switzerland, currently concentrating on model-based testing and

distributed usage control. He holds master!s degrees in computer

science from RWTH Aachen and the University of Kansas as well as

a Ph.D. degree in from Technische Universität

München. Alexander has organized several workshops in the field of

for automotive systems.

Manfred Broy is a professor at the Department of Informatics of Technische Universität München, Germany. His research interests are software and comprising both theoretical and practical aspects. He is leading a research group working in a number of industrial projects that apply mathematically based techniques to combine practical approaches to software engineering with mathematical rigor. The main topics are , ad hoc networks, software architectures, componentware, processes and graphical description techniques. In his group the CASE tool AutoFocus was developed. Today one of his main interests is the development of a modeling theory for software and systems engineering.

Ingolf H. Krüger holds a Ph.D. from Technische Universität München, Germany, and an M.A. from the University of Texas at Austin. He is an Assistant Professor i.R. in the Computer Science and Engineering Department of UCSD's Jacobs School of Engineering, leading the “Service-Oriented Software and Systems Engineering Laboratory”; he also directs the “Software & Systems Architecture & Integration” functional area within the California Institute for Telecommunications and Information Technology (Calit2). Dr. Krüger is a member of the UCSD Divisional Council of Calit2. Krüger!s major research interests are service-oriented software & systems engineering for distributed, reactive systems, software architectures, description techniques, verification&validation, and development processes. Together with Manfred Broy he has organized the Automotive Software Workshops 2004 and 2006 in San Diego, CA.

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007

Thomas Stauner is a software specialist with BMW AG, Germany. He studied computer science at Technische Universität München and the University of Edinburgh. He obtained his PhD in computer science from Technische Universität München. After leading a team at BMW Car IT on specification and verification of automotive systems, he is currently responsible for compatibility management of automotive electronic control units at BMW.

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 Software Engineering for Automotive Systems: A Roadmap

Alexander Pretschner1, Manfred Broy2, Ingolf H. Krüger3, Thomas Stauner4 1Information Security, ETH Zürich, Switzerland 2Software&Systems Engineering, TU München, Germany 3CSE Department, UCSD, La Jolla, CA, USA 4BMW Group, München, Germany [email protected], [email protected], [email protected], [email protected]

Abstract vance give rise to various organizational, engineering, The first pieces of software were introduced into cars and research challenges. In the first part of this paper, in 1976. By 2010, premium class vehicles are expected we describe the unique blend of characteristics that to contain one gigabyte of on-board software. We pre- define automotive software systems. Reflecting on the sent research challenges in the domain of automotive market, technology, economics, and organization of software engineering. labor, we describe software-related consequences of • the heterogeneous nature of automotive software 1. Introduction (embedded and infotainment systems) and the The amount of software in modern cars is increasing consequences for systems integration, tools, proc- at a breathtaking pace. The current BMW 7 series, for esses and engineering skills; instance, implements about 270 functions that a user • the huge number of communicating processors and interacts with, deployed over up to 67 embedded plat- the resulting need for tailored middleware; forms. Altogether, the software amounts to about 65 • the necessity to handle large numbers of variants megabytes of binary code. The next generation of up- and configurations; per class vehicles, hitting the market around the year • decisions grounded in a unit-based cost model; 2010, is expected to run one gigabyte of software (on • the interplay of long life and short development board, excluding data on DVD for navigation etc.). cycles; and This is comparable to what a typical desktop work- • specific requirements related to reliability, safety, station runs today. Reasons for this tremendous in- and security. crease include the demand for new functionality on the As key research challenges, we identify the integra- one hand, and the availability of powerful and cheap tion of heterogeneous subsystems from different hardware on the other hand. Furthermore, electronics sources as well as their evolution and maintenance, and in cars help reduce gas consumption as well as increase reuse. performance, comfort and safety as today’s figures of Division of labor in the automotive world has tradi- increasing traffic with decreasing serious accidents tionally been organized in a highly vertical manner, show. Finally, software enables OEMs (the “car mak- resulting in distributed and concurrent engineering ers”) and suppliers to tailor systems to particular cus- processes. The corresponding need for clear interface tomers’ needs. In other words, software can help dif- descriptions together with a tradition of model-based ferentiate between cars. At least in principle, software development of continuous systems explains, at least in also allows expensive hardware to be reused across part, the relative success of model-based approaches to different cars. developing automotive software systems. In the second Automotive software is economically relevant. The part of the paper, we hence explore potential benefits worldwide value creation in automotive elec- of a seamless model-based development process that tric/electronics (including software) amounts to an es- caters to the characteristics of automotive software in timated € 127 billion in 2002 and an expected € 316 terms of requirements engineering and management, billion in 2015 according to a Mercer study [DK04]. architecture development, and testing activities. Software makes up an estimated 40 percent of this Overview. Section 2 describes the characteristics of the value creation by 2010 [HKK04]. domain of automotive software and their conse- The considerable and increasing complexity of auto- quences. Section 3 uses this analysis to identify re- motive software systems and their huge economic rele- search challenges. More specifically, we present one

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 particular facet of model-based development as a pos- technologies (UMTS, Bluetooth, WiFi) via and with sible solution in Section 4. Our presentation of the fun- car information systems. Increasingly, the on-board damental models itself leads to many more relevant electronics systems establish communication links be- areas of future research. Section 5 summarizes our yond car boundaries, enabling various applications findings and concludes. A more detailed discussion of relating to, among others, sharing of infotainment con- the domain characteristics can be found in [BKP+07]. tent, remote vehicle analysis, software updates, global positioning and emergency services, inter-vehicle 2. Domain Profile communication for crash prevention and automatic We use this section to present five salient features of convoy forming. the automotive software domain as it presents itself 2.1.2 Consequences today. These features are the heterogeneous nature of From the integrated software and systems engineer- the software involved, the organization of labor, the ing perspective, the five clusters suggest a need for distributed nature of automotive software, the huge development skills from various disciplines. number of variants and configurations, and the pre- • The different SW/HW systems consist of a high dominance of unit-based cost models. In Section 3, we number of separated functions and processes that will use this analysis to highlight particularly relevant exchange information over several communication areas of research. links. These systems exhibit all the details and complexities of distributed computer networks— 2.1 Heterogeneity of Software computer science and skills 2.1.1 Description are required to successfully build automotive sys- Automotive software is very diverse, ranging from tems. entertainment and office-related software to safety- • These systems are connected to sensors and actua- critical real-time control software. It can be clustered tors that read physical values and operate physical according to the application area and the associated processes, respectively, in real time. The SW/HW non-functional requirements: systems have to respond to these inputs in a classi- • Multimedia, telematics, and human-machine inter- cal control-theoretic manner—knowledge of con- face (HMI) software: typically soft real-time soft- trol theory is required. ware, which also has to interface with off-board • For some functions, such as power train control IT, dominated by discrete-event/data processing; software, an understanding of mechanical engi- • Body/comfort software: typically soft real-time, neering is mandatory. discrete-event processing dominates over control Historically, the methods as well as the models of programs; control theory have been quite different from the mod- els of information processing. In control theory, tools • Software for safety electronics: hard real-time, discrete event-based, strict safety requirements; such as Matlab/Simulink [Mat06,WM95] are used to model differential equations. In contrast, engineers in • Power train and chassis control software: hard business information processing are increasingly eager real-time, control algorithms dominate over dis- to use models of data and behavior as expressed in the crete-event processing, strict availability require- Unified (UML), and other kinds ments; and of discrete data flow or state machine models. In auto- Infrastructure software: soft and hard real-time, • motive development, these separate engineering cul- event-based software for management of the IT tures have to be united to reflect all relevant aspects of systems in the vehicle, such as software for diag- the different engineering domains. nostics and software updates. The heterogeneity of the domain and the lack of a In terms of non-functional requirements, reliability and widely accepted, let alone standardized, set of models safety are concerns for all functions relevant to driving, and development approaches also explains the large from engine control and passenger safety functions to number of different tools in use in automotive software forthcoming X-by-wire [XBW98] functions where development today. Because the tools are developed by mechanical transmission is replaced by electrical sig- different vendors, there is no comprehensive system nals, such as steer-by-wire (steering signals are elec- model, and as a consequence, the tools are usually not tronically transmitted to the wheels) or brake-by-wire integrated. There exist attempts to creating pragmatic (braking signals are electronically transmitted to the tool chains by connecting the tools in a form where the brakes). In addition, with the development of infotain- data models of one tool are exported and imported by ment functionality, the car is becoming an information the next tool [PT06, KSL+03, AKMP05], but in most hub where functions of cell phones, Laptops and PDAs are interconnected using wired and wireless network

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 cases, full production support has not yet been possible for the OEM to localize errors and to modify achieved. parts of the subsystems.

2.2 Distribution of Labor 2.3 Distribution of Software 2.2.1 Description 2.3.1 Description As mentioned above, the car industry has tradition- As mentioned in the introduction, today’s premium- ally been organized in a highly vertical manner. Me- class vehicles are equipped with as many as 67 proces- chanical engineers worked hard for over a century to sors that implement roughly 270 user functions that a render the various sub-systems in cars independent. user interacts with (one of the reasons for the huge This facilitated independent development and produc- number of processors being the organization of labor tion of the parts and gave rise to a highly successful as described in §2.2). These functions are composed of division of labor: today, an estimated 25% of the prod- as many as 2500 “atomic” software functions. These uct value is created by the OEMs who tend to concen- functions address many different issues including clas- trate on the engine, integration, design, and marketing sical driving tasks but also other features in comfort of the brand. and infotainment and many more. These functions do In the past, the “ideal” of automotive development not stand alone, but exhibit a high dependency on each was that the parts of cars are produced by a chain of other. A telling example for the increased interaction suppliers and more or less only assembled by the among previously unrelated sub-systems is the central OEM. Thus, a large portion of the engineering and locking system (CLS) as found in most modern vehi- production activities were, and still are, outsourced. cles [KNP04]. It integrates the pure functionality of This also facilitates optimization of cost and risk dis- locking and unlocking car doors with comfort func- tribution. With software becoming a major force of tions (such as adjusting seats, mirrors and radio tuners innovation, the OEM’s responsibilities have evolved according to the specific key used during unlocking), from the assembly of parts to system integration. Tra- with safety/security functions (such as locking the car ditionally unrelated and independent functions (such as beyond a minimum speed, arming a security device braking, steering, or controlling the engine) that were when the car is locked, and unlocking the car in case of freely controlled by the driver suddenly related to one a crash), and with HMI functions, such as signaling the another, and started to interact, as the example of the locking and unlocking using the car’s interior and exte- central locking system in §2.3 will demonstrate. rior lighting system. Many of these functions are real- While the integration of subsystems is always a chal- ized in sub-systems that are distributed according to lenging task for a complex system, the situation in the major mechanical breakdown of the vehicle into automotive software engineering is even worse, be- engine, drive-train, body and comfort systems. In some cause suppliers usually have a lot of freedom in how vehicles this seemingly simple functionality is physi- they realize individual solutions. (In business IT the cally distributed over up to 18 electronic control units client will often strongly constrain the technologies (ECUs). Reinforced by a trend to combine on-board that may be used by a supplier.) with off-board IT, the car has turned from an assem- 2.2.2 Consequences bled device into an integrated system. Suppliers can use synergies in development and pro- 2.3.2 Consequences duction, because they usually produce similar systems With the huge amount of software-based functions, for different OEMs. This, in turn, also keeps the unit phenomena like unintentional feature interaction cost low for the OEMs. For functions that do not dif- [Zav93] have become issues. Feature interaction is the ferentiate between the different OEMs this synergy is technical term created in the telecommunication do- greatly exploited at the suppliers’ side. main for intentional or unintentional dependencies be- A negative side effect of the distribution of labor is tween individual features. Feature interactions are visi- that complex distributed processes need to be coordi- ble at the user level as specific dependencies between nated. In particular, development is geographically distinct functions. distributed and communication gets more complicated. A second consequence of the highly distributed na- Clear interfaces as well as liabilities need to be de- ture of automotive software systems is the intricacy of fined. The large number of parties involved in itself is an appropriate technical infrastructure, including oper- a reason for unstable requirements, with frequent ating systems and middleware. There are five bus sys- changes and revisions of the requirements during the tems (even more for some luxury vehicles) that serve development process as a consequence. Furthermore, as communication platform for ECUs. There are real the OEM often only has black-box specifications of the time operating systems; and a lot of system-specific subsystems to be integrated, and it is difficult or im- technical infrastructure on which the applications are

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 based. One challenge this infrastructure has to face is Software may be changed at much shorter intervals, the significant amount of multiplexing at the bus level typically several times a year. In particular, the com- to efficiently support communication among the doz- paratively short CPU life cycles enforce changes in a ens of ECUs for thousands of software-enabled tasks in vehicle’s software/hardware system during the produc- parallel. Among others, one consequence of the high tion period and maybe also during the development degree of multiplexing is that the transmission time of phase. This means that, over time, there are various messages exhibit jitter so that systems appear to be versions for each piece of software in a car. When de- nondeterministic. In many cases, timing deadlines can- fective ECUs are replaced or when a software update is not be guaranteed. Similar problems arise in the indi- performed as part of vehicle maintenance, configura- vidual ECUs where tasks and schedulers manage (vir- tions containing a mixture of “old” and “new” software tual) parallelism. We can thus find all the issues of can be created. distributed systems, in a situation where physical and 2.4.2 Consequences technical processes have to be controlled and coordi- Market demands, short innovation and long life cy- nated by the software, some of them being highly criti- cles lead to a huge number of variants and configura- cal and hard real time. tions. Updating or replacing software in cars is a chal- Due to the unpredictable load, time guarantees often lenge. New versions of software are brought in when cannot be provided. In many ways the communication exchanging entire ECUs, or during maintenance by buses serve as a global “memory” or database, captur- “flashing” techniques for replacing the software of an ing information about the current state of the vehicle ECU. In this context, it is estimated that today more and its electronics components. Therefore, a lot of in- than fifty percent of the ECUs that are replaced in cars teresting potentials for improvement, such as a car- are technically error-free—they are replaced when the wide and management system, or the intro- customer brings the car to a garage to fix a problem, or duction of drive-by-wire systems have not been real- for maintenance. They are replaced simply because the ized so far. Time-synchronous bus systems like TT- garage could not find better ways to fix the problem. CAN [ISO01] or FlexRay [MHB+01] are current at- However, often the problem is not rooted in defective tempts at solving these problems. hardware but in ill-designed or incompatible software. When exchanging entire ECUs or updating the re- 2.4 Variants and Configurations spective software, one has to be sure that new software 2.4.1 Description versions correctly interoperate with the remainder of The need for differentiation in the mass market mo- the vehicle software (compatibility [BBD+06]). Be- tivates the desire for customized items. A premium car cause of the substantial scattering of functionality in typically has about 80 electronic fittings that can be cars today, this is difficult, and a lot of the problems ordered depending on the country, etc. Simple yes/no we see today in the field are indeed compatibility prob- decisions for each function yield a possible maximum lems. Obviously, an elaborate design and test method- of 280 variants to be ordered and produced for a car. In ology is required for this. a similar vein, the authors of [BBC+01] calculate for a Furthermore, because of the long lifecycles of cars, simplified power train control application 3,488 possi- long-term maintenance processes must be organized. ble component realizations by instantiating different Today, an OEM's vehicle fleet is predominantly main- algorithms and their variants. tained by vehicle dealers following prescribed semi- A different kind of variability is a consequence of automated procedures. With its increasing amount of the development process. A car model is usually pro- software, the vehicle more and more inherits the char- duced for seven to eight years. The customer expecta- acteristics of a complex IT system. There is a differ- tion of a long lifetime is reflected in the OEM's duty to ence with the desktop software market, however: We offer service and spare parts for at least 15 years after deem it likely that future maintenance of on-board the purchase of a vehicle (compare this to an estimated software will continue not to be delegated to the users. lifecycle of, say, 4 years for an average workstation Among other things, this is a consequence of the program, with several hot fixes during this period). The OEM’s desire to create an overall brand “experience” life cycle of hardware components such as CPUs or to which the customer can relate as a “package”. DSPs is much smaller, say less than 5 years. Some of them will no longer be produced and have to be re- 2.5 Unit-Based Cost Model placed by newer types. Already after the first three 2.5.1 Description years of production, 25 percent of the ECUs in the car The automotive industry operates in a highly com- typically have to be replaced by newer ECUs due to petitive mass market with strong cost pressure. Here discontinuation of an ECU’s specific technology. the rules of business of scale prove to be crucial: how

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 many units of a product are sold? Depending on the We recognize that unit-based costs are important for market segments targeted by an OEM, competition software-based functions, as the above numbers show. occurs over product price, product quality, product However, they are but one factor. image and differentiating product features. Competi- tion by differentiation requires innovation and a strong 3. Research Challenges in Software Engi- brand profile. Competition over price requires perma- neering nent optimization. The domain characteristics of §2 directly translate Traditionally, the cost per unit produced has played a into many fascinating areas of research in software decisive role. A consequence of the large quantities engineering (we omit application-specific challenges produced, production and material cost by far out- such as crash prevention, advanced energy manage- weighed engineering cost for classical, not software- ment, driver assistance systems, further X-by-wire centric vehicle parts. The classical argument is as fol- technologies, HMI-related challenges, personalization, lows. A vehicle component may be produced over etc. here). At the bottom line, they all relate to quality seven years or more with, for instance, 500,000 units and cost, reflected by the need for integration, evolu- per year. A hardware cost reduction of € 1 for 20 such tion, and reuse: components (including 1 processor each) in each car 1. Languages, models, and techniques for require- would then lead to an overall cost reduction of € 70 ments engineering that support the structured million over the production period. For vehicle soft- specification of multi-functional systems and their ware, this argument continues to be used as a motiva- mutual dependencies; tion to keep the cost per unit low. 2. Languages, models, and techniques for require- 2.5.2 Consequences ments engineering that cater to heterogeneous sys- As a consequence, engineers concentrate on reducing tems and the engineers that build them, to the in- the amount of required memory and computation terplay between OEMs and suppliers, and to the power. Code is then written and directly optimized for huge number of variants and configurations; specific individual processors. Such optimization re- 3. Platform and HW/SW designs and design method- quires that the software be very closely tuned towards ologies at different levels of abstraction that ad- the processors’ characteristics. Trying to squeeze the dress the heterogeneity of the systems involved as code into as little memory as possible requires a further well as the compatibility problem; set of code optimizations. As a consequence, it be- 4. Middleware at different levels of abstraction that comes difficult to port the code to another processor. enables the communication between heterogene- Thus, keeping pace with processor life cycles (§2.4.1) ous subsystems; is hindered. The integration of new functionality is 5. Comprehensive cost models that take into account made more difficult or even impossible if memory size development, maintenance and opportunity cost of the ECUs was optimized too much during the de- (for failure of enabling reuse, for instance); velopment process. The negative results are as follows. 6. System models that enable the semantics- It is very difficult to add any functionality to the sys- preserving integration of different tools; tem later on, and it is very difficult to change parts of 7. Design and coding practices that lead to portable the code or to fix defects. The code is more complex and reusable code; than necessary, for instance, in terms of strong cou- 8. Security of the communication within a car as well pling between modules. Changing the code becomes as between cars and several forms of off-board IT; very difficult, and reusing this code in future car mod- 9. Reliability estimates, timing predictability, meas- els or on other processors is almost impossible. Finally, urements, and assurance; some defects in the code may be a result of the optimi- 10. Techniques and error models for quality assur- zation itself and finding defects may become even ance—particularly relevant in a domain with huge more difficult, since now application logic issues are numbers of deployed entities and very limited con- obscured by optimization. trol over them—that, in particular, address the in- In sum, exclusively thinking in terms of unit-based tegration problem as well as the huge numbers of costs with the associated need for optimizations makes variants and configurations; the software complex and difficult to handle. Prema- 11. Integration of on-board and off-board IT; ture optimization has a negative effect on many classi- 12. Approaches to error diagnosis and recovery; and cal quality attributes for software. Time-to-market, 13. Approaches to reuse for the benefit of reducing maintenance costs and the risk of not finishing a devel- complexity and cost. opment project in time are substantially increased. We will use Section 4 to address items 1, 2, 3, and 6 collectively in some detail under the headlight of

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 “model-based development”. In the remainder of this ness of the underlying model. Therefore, a powerful section, we briefly summarize research challenges for meta- or domain-model is needed that allows us to some of the other areas. express all required aspects of the system, including, but not limited to communication variants, timing as- 3.1 Middleware: Communication Services pects, safety and redundancy. A classical approach to handling complexity is The goal of a uniform, lean middleware layer that separation of concerns. The application logic, for in- manages communication and exception aspects in a stance, should obviously be independent from the un- system-wide uniform way is only achievable by in- derlying communication infrastructure; all applications creasing the expressive power of automotive modeling should, system-wide, react uniformly to exceptional approaches towards model-based system specifications events (such as physical read/write errors on the bus) supporting code generation of middleware components etc. With each of the five busses (§2.3.2) having its in an optimized and validated way. The AUTOSAR own characteristics and protocols, the definition of a [Aut06] partnership, consisting of various OEMs and respective adequate middleware, of course, comes as a suppliers, is a promising step towards an open architec- significant challenge. ture that features such a model-based middleware Separation of concerns can be reached on several layer. It provides a basis and an enabler for further levels, including architecture, design and implementa- aspects such as timing and redundancy aspects that can tion (language dependent). Popular techniques, well be included in the metamodel to further increase ex- known from business IT, are middleware layers and the pressiveness. corresponding component orientation. An automotive middleware, however, must fit other requirements than 3.2 Safety and Security middleware known from business IT (such as CORBA The life-criticality of many avionics systems has led and web services). Flexibility at runtime is still domi- to reliabilities of 109 hours mean time between failures. nated by the need for flexibility at design time in the This high reliability is, on one hand, due to the use of automotive domain, because the runtime layout of very sophisticated error tolerance methods and redun- automotive software is still mostly static. The follow- dancy techniques, and on the other hand due to sophis- ing issues need to be considered for automotive mid- ticated ways of error modeling (like Failure Mode and dleware: Effect Analysis (FMEA), which is also heavily applied • Resource optimization: due to the unit-based cost in the automotive industries, but rather not at the level structure (§2.5), modularity must not be overly of software). Furthermore, driven by government man- expensive with respect to resource consumption. dates, avionics companies invest heavily into quality • Adaptability to different domains: real-time and management, including rigorous code inspection tech- non-real-time, safety-critical and non-safety- niques throughout the development process. For many critical software is integrated within one system equally life-critical systems in the automotive domain, (§2.1). the respective numbers are not even known (but the • Optimizability to hardware but also transferability requirements are admittedly different). Research into from one hardware platform to another: due to the measuring and improving reliability is, hence, required. lifecycle gap (§2.4) and the hardware-software Personalization and the related privacy and security correlation the software must be transferable from issues are becoming increasingly important, notwith- old platforms to new ones, but still optimizable standing usability issues. The management of intellec- towards the hardware. tual property, including digital rights management, is • Extensibility: again due to the lifecycle gap (§2.4), particularly challenging in a distributed development it must be possible to upgrade a system during its process as described in §2.2. From a liability perspec- lifetime and extend it with new features. tive, unauthorized “tuning” of code must be prohibited In contrast to other middleware approaches there is or at least be detectable in hindsight. Liability also is no single instance in the system that handles the com- an important issue in ad-hoc distributed safety-critical munication dynamically (like an ORB in CORBA), but applications such as crash prevention that relies on the middleware layer is generated statically for this communication between cars. Today’s secure commu- special configuration of the system. This can lead to nication protocols need to be extended for real-time lean, highly optimized middleware portions inside applications. every ECU that minimizes the overhead that comes There are clear benefits to hardening the automotive along when using middleware. infrastructure against the intrusion of unauthorized The consequence is that middleware can be only as services and components. The more the vehicle be- flexible and optimized as allowed by the expressive- comes connected to the cyber-infrastructure the more

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 susceptible it becomes to attacks carried out via this base techniques to guarantee fail-safe and graceful cyber-infrastructure. Management of security is, there- degradation and, in the end, also error avoidance by the fore, a necessity both on-and off-board. As an example help of redundancy. for on-board authentication requirements, consider the importance of identifying which of the myriad of func- 3.4 Reuse tions and ECUs is responsible for a failure: if the func- Typically, functionality changes only to a small tions, as they become active and communicate, authen- amount from one vehicle generation to the next. Most ticate themselves, the system could identify the pres- of the old functionality remains and can be found in the ence of unauthorized components, or could determine new car generation, as it was in the old one. From one which of the authorized components malfunctioned. car generation to the next, functionality (of the systems These topics are under research also in their more tra- that exist in both generations) differs mostly not more ditional home grounds of internet-enabled business than 10%, while much more than 10% of the software information systems; their inherently cross-cutting is re-written. The short hardware lifecycles (§2.4) may nature makes them particularly challenging in automo- require frequent re-implementations. Nevertheless, tive architectures with a high degree of scattered func- today the process of software reuse is not systemati- tionality. cally planned between OEMs and suppliers, as re- quired, say, for software product lines ([CN01]; see the 3.3 Error Diagnosis and Recovery comment below). From the OEM point of view, reuse Failure management, from a systems engineering rather occurs on the level of whole ECUs than on the perspective, is a further area that requires increased level of software, and the reuse objectives of OEMs attention. Because of its role as the system integrator, and suppliers may be in conflict with each other. Reuse the OEM is uniquely positioned to deal with failures at is arguably one of the most challenging problems, the composite system level—as compared to the typi- clearly transcending the automotive domain, and we cally localized failure management at the component are not aware of convincing solutions for the general level prevalent today. This requires, however, compre- problem. However, some reuse problems are of an ac- hensive logical and technical domain models of fail- cidental rather than an essential nature. For instance, ures, failure effects, failure detectors, mitigators and too strong an optimization of the software towards the mitigation strategies that influence the choice of both hardware (§2.5) can make reuse in the form of porting logical architectures and their mapping to technical it to new hardware impossible or very expensive. With architectures (§4.2). the increasing importance of software, we deem it a Today the amount of error diagnosis and error re- mere question of time until it becomes more economi- covery in cars is rather lightweight. In the CPUs some cal to use more generous hardware structures and to error logging takes place, but there is no consideration stay away from low-level code optimization. nor logging of errors at the level of the network and the Reuse comes in different forms. Reuse at the level of functional distribution; there is no comprehensive error single code modules has proven to be utterly difficult. diagnosis and no systematic error recovery beyond At the level of programming or modeling languages, individual CPUs (note that as of today, this appears recurring patterns of behavior in a domain can be en- appropriate because systems are essentially designed in capsulated into concise language constructs. In terms a way that will lead to a safe state, even if bus commu- of research, this necessitates the analysis of domains nication crashes). One result of inadequate error man- where such patterns can be identified, and then the agement is the maintenance problem mentioned in definition of these patterns. The tradeoff between the §2.4.1, resulting in the replacement of many non- benefits of general-purpose languages on the one hand defective ECUs. Failure logging to the end of better and the benefits of domain-specific languages on the error diagnosis for maintenance then emerges as a other hand has to be evaluated. Domain-specific design relevant research problem. patterns must be defined in places where it makes no There are some fail-safe and graceful degradation sense to encode recurring patterns into dedicated lan- techniques found in cars today, but a systematic and guage constructs. Well-designed libraries and frame- comprehensive error treatment is missing. With the works form a promising avenue of research. upcoming multi-core controllers for embedded applica- Reuse is also facilitated by standardized middleware tions, an interesting area for research is how this can be [Aut06] that allows for coordinated and standardized exploited also for redundancy/recovery strategies. In interfaces. At the level of requirements engineering, the long run, comprehensive error models in cars seem there definitely is a need for further research into prod- desirable, and so does software for the detection and uct lines (with the common argument that product lines possibly mitigation of errors. On such models we can cater to anticipated changes only). The organizational

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 structure of the development process, with its interplay the abovementioned problems into the general ideas of between OEMs and suppliers and the resulting con- model-based development, by taking into account the flicting desires for reuse, must also be taken into ac- automotive idiosyncrasies. In this paper, model-based count (as reflected by suppliers being seemingly more development means working with artifacts representing open to product line approaches than OEMs). Research domain and design knowledge at different levels of into reuse must of course include studies of the cost abstraction, throughout the development process, and effectiveness, and hence be related to research into cost possibly also at runtime. Many crucial software-related models. It is unclear to date to what extent and where facets of a system are then represented by the follow- at least ad hoc reuse occurs today, and how OEMs and ing artifacts. suppliers profit from different forms of reuse. • Requirements models that address multi- functionality and feature interactions embrace all 3.5 Cost Models requirements-related issues, dealing with the direct In the development of software intensive systems, behavior of embedded software-based functions many aspects of costs are involved, including devel- from the users’ point of view. These include the opment cost, maintenance cost, different forms of op- driver, passengers, maintenance staff and other portunity cost, and reputation-related costs for the persons dealing with the car. Use cases and related OEM’s brand. So far the comprehensive cost situation behavior specifications are one part of the re- is not understood in sufficient detail. What is quite quirements models. clear is that the costs for the electronic devices both for • The logical architecture is a breakdown of the the development and for the production are rising (§1). functionality into interacting logical components. But it is not so clear how development cost is distrib- It represents the functional decomposition of a uted between software and hardware costs. Because system into functional components, as well as the current cost models usually relate to the cost per unit, behaviors of these components at the logical level. software is considered an integral part of the develop- The functional components provide the functional- ment process and not explicitly calculated in the con- ities described in the requirements model. tracts between the supplier and the OEM despite its • The technical architecture defines the deployment continuous rise (there is an estimation that, per year, architecture, i.e. all the hardware units, the basic about five percent of the costs “migrate” from hard- software (operating system and middleware) on ware to software). them and their connections: controllers, communi- The importance of intellectual property (IP) issues cation devices, actuators and sensor, as well as a seems to exceed that of hardware developments. The mapping (the “deployment function”) from the IP for a large piece of software is remarkable. The next logical architecture (its structures and behaviors), generation of premium cars will exhibit hundreds of to this deployment architecture. This includes the millions of lines of code. If the overall costs for such definition of source code modules, the platform, an amount of code are calculated according to the clas- and the representation of the application software sical development costs, the value of the software costs in terms of tasks, based on the chosen platform, as of a premium car amounts to somewhere between three well as the mapping of these tasks to ECUs and hundred and eight hundred million €. Owning the soft- their schedules. ware and being able to reuse it is an important factor in Each of these models must of course be connected to the cost models. non-functional requirements, including safety reliabil- In sum, the exponential increase of software does not ity, maintainability, portability, performance, etc. The justify the use of restricted unit-based cost-models architectures and the implementation of the system alone. The research challenge consists of understand- then have to ensure these requirements. ing processes and products and defining more appro- In the remainder of this section, we discuss require- priate, comprehensive cost models. The automotive ments models (§4.1), the logical and technical architec- industry needs decision and cost models that take into tures (§4.2), and the role of detailed behavior models account rising development costs, maintenance cost, (§4.3). We will argue that a clear separation of con- software-related project risk and time-to-market. It is cerns together with a comprehensive understanding of likely that such models require a more transparent co- the domain-specific issues (§2) and their cross-cutting operation between suppliers and OEMs aspects is likely to be the main benefits of this ap- proach. We consider code generation, in particular in 4. Model-Based Development the domain of discrete systems, to be but one of the In this section, we describe some further research benefits of a model-based approach. Furthermore, we challenges. We will cast facets of a possible solution to deem the availability of comprehensive product models

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 the exception, rather than the norm. This is a conse- mented in a way such that the supplier can imple- quence of the complexity of the systems and the nature ment them. of the distributed development process (§2.2). • Over the development process requirements occur With different levels of abstraction, seamlessness and in strongly varying levels of detail. In the begin- traceability are, of course, major concerns and belong ning requirements are often very abstract, e.g. to the fundamental research challenges: how can, con- based on benchmarking with competitors. How- ceptually, models at different levels of abstraction be ever, in the same process phase requirements to related to one another [BBJ+05], and how can the re- reuse some ECUs from other products may al- spective tools be integrated? The different levels of ready be fixed. The need to integrate these ECUs abstraction discussed in this section support require- not only strongly restricts the set of possible solu- ments tracing for functional requirements (of course, tions, it also adds a large set of very detailed re- requirements tracing should also include the link be- quirements resulting from the ECUs to be inte- tween requirements, their origin—e.g., requirements grated. from marketing—and design decisions). The flow- • Requirements specifications must deal with a large down is as follows. The relationship between the func- number of vehicle variants (§2.4; for instance, “2 tion hierarchy—a part of the requirements model—and doors”, “4 doors”), and in particular variants re- the logical architecture indicates which components of sulting from different combinations of auxiliary the logical architecture are contributing to (i.e., col- equipment. laboratively realizing) the respective function. The • Besides the functional requirements there is a logical components are later represented by specific large number of non-functional requirements con- software. The deployment onto the technical architec- cerning cost, time-to-market for innovations, ture determines which software runs on which hard- safety, security, reliability, maintainability etc. ware and which logical communication channels are • Often, there are further constraining platform- implemented by which bus systems. In sum, by also specific requirements (“this ECU has to be re- taking into account the quality models, elements of the used”), pulling deployment specifics already into function hierarchy can be traced to the hardware level, the levels of requirements engineering and logical which greatly facilitates requirements verification, architecture design. maintenance, and evolution after the start of produc- In general, requirements are originally expressed in tion. natural language. It has turned out that rigorously im- posing structure on the text is most useful. A first step 4.1 Model-Based Requirements Engineering from text to models are taxonomies that can be com- There is a general agreement that requirements en- puted from text by natural language processing tech- gineering for embedded systems is a key discipline in niques [Kof05]. They are used as a basis for the the automotive domain—a discipline that is not suffi- abovementioned requirements models (that of course ciently mastered today [WW03]. Reasons include the reflect a lot of structuring activities and which are following. hence richer than mere feature trees [BLP04]). • Many new innovative functions in cars today are The system’s (intended) functionality is modeled by based on embedded software systems. There is no a function hierarchy that collects all software-based experience so far with these functions and the best functions. These will be implemented by functional way to engineer the human-machine interactions entities defined at the level of the logical architecture. with them. The process of deciding on the optimal Requirements are associated with the elements of this realization of functions, the interaction between hierarchy. Its nodes relate to one another in an “is- functions themselves, and the interaction between subfunction” relation. The dependencies between the users and functions is a difficult and error-prone functions must also be described. Each function is learning process. Models and prototypes can pro- modeled in isolation. A function may, for instance, vide initial solutions to these problems. define an interactive service that is described by a state • The systems are multi-functional, and a huge machine. System behavior in the presence of failures number (§2.3.1) of functions is offered to the user. needs to be specified as well. Based on the function These functions exhibit complex interactions, are hierarchy, detailed behavior patterns can be provided mutually dependent and give rise to intended and for the individual functions. This model of the func- unwanted feature interactions. tionality comes along with models of the required qual- • The suppliers realize a lot of the functionality ity aspects of the system. (§2.2). Therefore the overall ideas of functions These models are a necessary starting point for have to be fixed by the OEMs and then docu- mapping requirements to elements of the logical and

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 technical architectures (ideally, the latter mapping is logical architecture or function network, and its de- indirect via elements of the logical architecture); the ployment on a concrete, technical architecture. This quality models are used to assess and optimize archi- entanglement gives rise to a scattering of functionality tecture decisions. Therefore, for a systematic model- (§2.3.1). One of the central challenges for next- based requirements definition, all requirements have, generation automotive system development is, there- sooner or later, to be formulated in terms of the struc- fore, to disentangle logical and technical architectures. tured view on the architectures. This will help unleash so far untapped potentials at Research Challenges. This approach to require- • reducing the number of ECUs required to deliver ments engineering entails many research challenges. the desired functionality based on the ability to es- The definition of the tracing structures and their effec- tablish globally optimal mappings from functions tive tool support is, so far, an unsolved problem. to ECUs; As indicated above, requirements exist at various lev- • enabling dynamic reallocation of computing and els of detail. They range from marketing-driven re- communication resources to effect globally opti- quests (“the car has to have the following comfort- mal energy and QoS management, or to manage functions”) to very detailed platform specifications, failures by means of an appropriate reconfigura- which may limit the design space for both logical and tion of the system; technical architectures. One research challenge is, • reducing the dependency on physical proximity for therefore, to elucidate a comprehensive requirements the provisioning of automotive functionality by in- model that brings out these levels of abstraction and troducing location transparency, say, for functions optimizes the resulting solution space for logical and such as navigation; technical architecture. • enabling conceptual reuse by allowing independ- A systematic way to structure the requirements after ent evolution of logical and technical architecture; capturing them, to make them precise, and to validate and them is still a challenge. First of all, a reference model • enabling faster modeling, design and test cycles, is needed that defines all the artifacts that are to be because the OEM can ultimately perform continu- considered as results of requirements engineering and ous integration of functionalities as they become requirements dependencies (see [GBB+06]). available from suppliers – rather than having to So far the models offered for requirements engineer- wait until all functions of all ECUs are imple- ing are limited. We need structured hierarchies of all mented towards the end of the overall system de- the software-based functions in a car that reflect all velopment cycle during system integration. their mutual dependencies (specified feature interac- Modern approaches to software and systems archi- tion). Good ways to model the functional hierarchies tecture and integration recognize the importance of and their dependencies that support automatic analysis separating logical and technical architectures. Model- are a challenge for research. In addition, the functional Driven Architecture, for instance, distinguishes be- behavior of the individual functions has to be modeled. tween Platform Independent Models (PIMs) and Plat- The systematic step from the requirements to the de- form Specific Models (PSMs) to separate logical func- sign phase, taking into account both functional and tionality from its mapping to a deployment model. Ar- quality requirements, is largely unsolved. Eliciting chitecture standards, such as the Department of De- domain-specific design and analysis patterns can be a fense Architecture Framework, distinguish operational promising research direction to tackle this problem. from systems views to effect a similar disentanglement between logical and technical system aspects. 4.2 Logical and Technical Architectures In essence, the models relevant for logical ar- As outlined above, the complexity of automotive sys- chitecture focus on capabilities and their mapping to tems rivals that of other ultra large scale systems, in- logical entities (sometimes called operational nodes). cluding avionics, command and control, and internet- These capabilities realize the functions in the require- wide business intelligence systems. In fact, automotive ments model. The models relevant for technical archi- systems combine many of the requirements challenges tecture focus on deployment, i.e. the physical layout of we see elsewhere only in isolation. Historically, there the system including physical nodes and networking has been a tight coupling between automotive software structures—and the mapping from the logical architec- functions and the physical processes they manage, and ture to this layout. Consequently, many models, includ- thus with dedicated, networked ECUs. This tight cou- ing structural and behavioral models, crosscut logical pling has contributed significantly to the fragmentation and technical architectures. Often, the technical archi- of the automotive platform into its current state. This, tecture introduces additional constraints at, for in- in turn, has led to a strong entanglement between the stance, performance, safety, security and reliability that

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 influence the mapping from logical to technical archi- rather than in terms of deployment components. A tecture. The use of reflective models, i.e. models that promising aid to that end is the notion of service. Of- are accessible to and can be modified by the runtime ten, service-oriented architectures consist of at least infrastructure, can establish a link between the logical two distinct layers: one domain layer, which houses all and technical architecture; this can provide a means to domain objects and their associated logic; and one ser- adapt the mapping between logical and technical archi- vice layer, which acts as a façade to the underlying tecture according to resource constraints, or to over- domain objects—in effect offering an interface that come failures. shields the domain objects from client software. Typi- 4.2.1 Logical Architecture cally, services in this sense coordinate workflows The focus of the logical architecture in general is among the domain objects; they may also call, and thus the set of capabilities provided and requested by the depend on, other services; and a respective service overall system and its subsystems. This describes the model that takes into account the specifics of automo- (logical) implementation of the overall functionality by tive requirements needs to be defined. Enriching do- a network of logical entities (operational nodes includ- main-specific architecture definition languages with ing software components) and the necessary links be- the corresponding abstractions and notations to capture tween these logical entities. In addition, the logical the cross-cutting, coordinating nature of services is architecture encompasses mapped use cases, the rele- also a rich topic of future research [KNP04, AKMP05]. vant data models, as well as QoS, bandwidth, (real- Another research challenge is the management of time) performance, security and other cross-cutting the various levels of granularity and detail available in concerns to the degree they are relevant on the logical a systems of systems engineering project. Because of level. Data models, logical entities and behavior mod- the complexity and size of automotive systems, having els are typically linked by means of data-flow models. complete knowledge about all subsystems and the Depending on the level of detail at which these models overall systems is an illusion. Hence, we need re- are available, the logical architecture can support early quirements and logical architecture models that can simulation, optimization, prototyping, verification & deal with the partiality of information. Again, the no- validation, including testing. tion of service discussed above can be a valuable step In the automotive domain, the so-called function into this direction. Services, defined via interaction network (which is not the same as the function hierar- patterns among roles, provide partial views onto the chy of the requirements model) is often used as a overall system, albeit in an end-to-end fashion. Com- key—sometimes the only—expression of the logical position and combination of services then leads to a architecture. The function network is, in essence, a composite view of the relevant parts of the overall sys- representation of the functionality to be provided by tem integration. Exploiting this partiality for tasks such the vehicle together with links indicating (communica- as simulation, verification and validation holds signifi- tion) dependencies among these functions. The mod- cant promise in complexity management. Of course, to eled functions are then mapped to the HW/SW imple- be viable, the service notion has to reflect the com- mentations as part of the technical architecture, consid- bined control- and event-driven behavior spectrum. ering the also captured real-time and bandwidth re- Ultimately, combining the aforementioned models quirements. into a notion of service- and component-interfaces that Because the OEM to a large extent plays the role of includes behavior descriptions and can be shared be- system integrator, the logical architecture from the tween OEMs and suppliers, is a long-term research OEM’s point of view will mainly stay at the level of an goal at the logical architecture level. Solving this chal- integration architecture. The detailed development of lenge would enable OEMs and suppliers to engage in functions is often left to suppliers; consequently, the meaningfully tool-supported exchange of interface OEM will have only a black-box view on these func- models that can support the value-added development tions, limiting opportunities for global optimization, support we have alluded to, above. and deep verification and validation. This places par- 4.2.2 Technical Architecture ticular importance on the specification of interfaces at The technical architecture identifies the ECUs, the the logical level; in particular, the interfaces need to be basic software (operating system and middleware) on rich in the sense that they need to convey not only them, their interconnection via busses, as well as the structural information (such as function names and data partitioning of functions or SW components from the types) but also behavioral information (§4.3). logical architecture onto ECUs. This, of course, re- Research Challenges. A first step towards accom- quires the identification and definition of software plishing the desired disentanglement of logical from components representing logical entities defined at the technical architecture aspects is to consistently think of level of the logical architecture. The respective parti- the system and its subsystems in terms of capabilities tioning decisions need to be future-proof, because of

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 the business characteristic of long life-cycles (§2.4): research question here also is how modeling can help changes in the partitioning are very likely to lead to in performing software diagnosis for shipped software, incompatibilities to legacy systems. An ECU with a i.e. without the possibility to inject stimuli from out- new partitioning will usually not work in an already side the system to localize faults. This also requires produced vehicle. As backward compatibility is models for the system environment (the plant in con- breached, a new branch in the configuration space is trol theory terminology). opened, or an obsolescence management strategy is In vehicle networks that contain both time- needed for the old ECU variant. asynchronous busses like CAN [Bos91] and time- The technical architecture also specifies how logi- synchronous busses like Flexray, a further question is cal communication is mapped onto technical commu- which functions are deployed onto CAN-ECUs and nication. For instance, the technical architecture speci- which on Flexray-ECUs. While functions with hard- fies how a logical signal is mapped onto protocol data real time requirements obviously are good candidates units of the bus system that is used for communication for Flexray-ECUs, the question remains where the bor- of the deployment components. Due to the specifics of der with the asynchronous world is to be drawn. Usu- real-time bus systems, this mapping often is a complex ally there remains a lot of communication between the issue. For instance, for a signal with hard real-time two worlds, but their interface is non-trivial. In particu- requirements that will be sent via the time-synchronous lar for the case of signals with soft real-time require- Flexray [MHB+01] bus, the decision remains whether ments that are forwarded via a gateway from CAN to the signal should be transmitted in the static segment Flexray, these signals are not only delayed by the la- of bus communication or within the guaranteed dy- tency when accessing the CAN bus, but also by the namic segment. latency time that is a consequence of waiting for the In the context of upcoming time-synchronous bus next appropriate Flexray time slot. This means that systems such as Flexray, a further task in the definition latency from CAN to Flexray either is rather high or of the technical architecture is to define a bus schedule. that bandwidth is wasted on the synchronous bus. Se- This schedule specifies what information is sent in mantics-preserving deployments of synchronous mod- which time slot, and it needs to be coordinated with the els on heterogeneous architectures [BCC+04, Rom06], task schedules of the ECUs. A close coordination al- including time-synchronous and asynchronous archi- lows to minimize communication latency. On the other tectures [HS06], deserve further investigation. hand, it decreases the maintainability of the overall Integration of models of the technical architecture system. If coordination is very close, minor changes in in overall models for systems engineering is a further the bus schedule might require changes to all task important topic. With respect to the technical architec- schedules of the ECUs that are connected to the bus. ture there is a close correlation to models for the flow Currently, first tools for the generation of bus sched- of electrical energy and geometric models for the ules start to be available [D06, P06]. placement of wiring and ECUs. Furthermore, a link to Research Challenges. From the point of view of cost models (§§ 2.5 and 3.5) is mandatory for partition- model based development, the integration of models ing decisions. For instance, with respect to cost, the for the technical architecture and models for bus traffic partitioning is strongly affected by the business choice analysis is highly desirable. A key property of these of which functions are part of every vehicle and which models is that they abstract communication behavior of ones are optional. With such an integration, a detailed hardware, middleware and application software in a evaluation of architectural decisions becomes possible. stochastic way, focusing on size, frequency of occur- For the integration with models from systems engi- rence and timing of the data to be sent. neering, establishing of a tool chain is highly demand- Furthermore, as already mentioned in §3.2, safety ing since for all disciplines good, isolated tools exists, analysis can greatly benefit from model-based devel- but we cannot assume that their semantics is identical opment, if further research identifies how those models in detail in the model elements they have in common. can be integrated with models for FMECA (Failure For a seamless model-based development, there is a Mode, Effects and Criticality Analysis), FTA (Fault need for models of the technical architecture that com- Tree Analysis), and also for reliability analysis in gen- prise all the features offered by a platform to the SW eral. Of course, the integration with the technical archi- components deployed on it. Therefore, research into a tecture alone does not suffice here. This is because modeling paradigm is needed that supports a kind of additional information on which functions are affected (automotive-specific?) layer-based modeling, which in which way is needed, i.e. the link to the logical ar- makes all relevant platform aspects visible but ab- chitecture. Similarly, models of the logical and techni- stracts from details. As suggested in §3.1 such a mod- cal architectures can be used as a basis for diagnosis eling of platform/middleware features must provide models that help in the localization of faults. A central that some features are system wide, for instance, due to

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 a common middleware, while others are domain or • Discrete systems, as predominantly found in the platform/ECU specific. infotainment domain (§2.1.1), are probably most familiar to software engineers. They are typically 4.3 Detailed Behavior Models specified in one of a plethora of state machine vari- Finally, we will have a look at behavior models that ants. As of today, in contrast to continuous systems, specify functionality at a rather detailed level. This is their usage is not commonplace in the automotive needed for architecture specifications at both the logi- industry. When speculating about the reasons, one cal and—in refined form—the technical levels. These might want to quote models come in different flavors. Existential models 1. the lack of convincing tools with excellent pro- focus on the main system runs in an exemplary man- duction code generators that would allow for ner. In the form of sequence diagrams, they are often roundtrip engineering; used as specifications. Universal models, on the other 2. a rather close proximity between genuine C++ hand, are detailed enough to permit the generation of code and state machines with C++ as action production code [FGG05, BOJ04], of simulation code language on transitions—hierarchical state ma- that is used for prototyping and hardware-in-the-loop chines then act as structuring means only; simulations [Spi01], and of test cases [PPW+05]. 3. the closely related problem of choosing appro- Except for the generation of production code, all priate abstraction levels (for continuous models, these activities require the development of environ- abstraction takes place by means of language ment models (with high costs and high potential for constructs, not deliberate loss of information reuse). We ignore them here for brevity’s sake, and [PP05,PP04]); focus on universal models of systems. 4. cost issues in cases where models are not used In accordance with the heterogeneous nature of auto- for the generation of production code but as motive software (§2.1.1), the models are continuous, specifications only: two artifacts, model and mixed discrete-continuous, and purely continuous (see code, have to be maintained and synchronized; [HS06] for a complementary perspective). 5. the necessity to add yet another language and • Modeling continuous systems—more concretely, yet another toolset to the existing tool chain for control algorithms—is common practice and has a continuous systems; long tradition in the automotive domain. In the 6. so far unfulfilled promises as far as the verifica- automotive domain, the most prominent toolset for tion of such models is concerned; and such models is Matlab Simulink [Mat06,WM95]. 7. education issues. The language of block diagrams allows the engi- It is noteworthy that the goals of code generation neer to graphically specify differential equations, and verification are somehow contradictory. The for- with blocks representing operations such as multi- mer requires a rather low level of abstraction as em- plication, integration, or differentiation, and arrows bodied by corresponding language constructs whereas between blocks representing data flow. Block dia- the latter usually requires abstraction in the sense of an grams can be seen as a graphical special-purpose actual loss of information [PP04]. Furthermore, verifi- programming language for control algorithms. At cation tasks by definition require knowledge of the the control-theoretic, purely continuous, level there properties to be verified, and these properties are often is a huge body of methods for the analysis of prop- not known (these problems are of course not unique to erties like robustness, stability, attraction, etc. the automotive domain). [Sta04]. Because of the low level of detail, impres- The above objections are hard to overcome. Indeed, sively efficient simulation and production code can as far as the automotive domain is concerned, it seems be generated. This, of course, involves discretiza- very possible that the benefits of model-based devel- tion and the respective fundamental problems with opment for discrete systems do not lie in the generation the transition from floating point to fixed point of code but rather in the definition of clear interfaces numbers. and the relationships between components (§§ 4.2.1 • Mixed discrete-continuous systems exhibit different and 4.2.2). What does appear appealing in this context modes in which they operate continuously, and is the use of behavior models as black-box specifica- modes are switched in a non-continuous—i.e., dis- tions, serving as communication interface between crete—manner [GKS00]. Approaches to specifying OEMs and suppliers (§2.2.1; [PP05, AKMP05]). In hybrid systems include hybrid automata, hybrid addition, these behavior models can be used to the end Petri nets, and equation-based approaches. In prac- of generating tests [PPW+05], thus facilitating the task tice, extensions of the Matlab Simulink languages of verifying a system with respect to its specification. (Stateflow) are most commonly used. Research Challenges. Challenges in the context of continuous models include even more efficient code

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 generators as well as a sufficiently precise “standard” domain-specific modeling methodologies, code genera- semantics. Such a standard would of course come with tors, roundtrip engineering, tool integration, and verifi- the political problems that every standardization of cation technology. semantics has to face, see the UML. On the other hand, Finally, empirical investigations into cost effective- it would allow assessments of the correctness of code ness are needed to assess the benefits of behavior mod- generators—as of today, production and simulation els when used for specification (where component- code from one product do not necessarily exhibit iden- based engineering might turn out to be the better solu- tical behaviors (we mention TDL [PT06] as a notable tion) and test case generation (where setting up better exception), and neither does generated code from two structured test processes might in itself solve a lot of different products [SC04]. Because the idiosyncrasies problems). We realize that many of these research of different code generators are known, the current challenges are shared with other technical domains. approach to handling this problem consists of avoiding “critical” constructs, which results in modeling guide- 5. Conclusions and Outlook lines. Because of the enormous state spaces of continu- Software engineering for automotive systems embraces ous systems, their analysis also remains a challenging almost all areas of computer science and computer task. Function blocks are equipped with a multitude of engineering, and includes all software engineering ac- possible parameters in order to cater for different ap- tivities. In this paper, we have characterized the do- plication domains such as automotive and avionics. As main of automotive software and highlighted some a consequence, it is very hard to keep track of all the particularly important research problems, of course relevant and irrelevant parameters; the models become without any claims to completeness. Because of the unnecessarily complex. A possible solution, and thus a broad scope of our subject it is not surprising that research challenge, is an automotive “profile” for Mat- many problems exist in other domains as well. As a lab/Simulink. consequence, we have taken some care to identify Because the classical proof methods from control problems that are specific to the automotive realm— theory are not applicable, the analysis of mixed dis- which explains why we did not discuss important prob- crete-continuous systems presents itself as a vast re- lems as diverse as continuously changing requirements, search problem, with only first steps in the understand- timing predictability, usability, portability, design and ing of proof methods [Sta04] and in terms of reachabil- coding standards, etc. Essentially, the problems we ity analyses being taken today. The conceptual clarity have identified relate to evolution and integration. To- of time-synchronous languages such as Esterel [BG92] day, integration is mainly enabled in an ex-post man- and Lustre [HCR+91] is appealing and might turn out ner, by testing and changing where necessary. For evo- to impact the integration of discrete and discretized lution, this becomes increasingly complicated, a con- continuous systems. Furthermore, the combination of sequence of the huge number of variants and versions continuous and discrete subsystems into a joint, com- that require support. We have indicated how model- prehensive domain model supporting early simulation based approaches to systems development can help and validation is missing so far. In particular, this will meet the challenges, and provided some particularly require a combination of timed behavior models of relevant research directions in the intersection of varying degrees of rigidity and event-driven behavior model-based development and automotive software models. This combination will be a first step towards systems. integrating time into a general programming model for Acknowledgment. The first author would like to thank embedded systems. Manuel Hilty for comments on a draft version of this Fundamental research challenges in the context of article. The third author was partially supported by the using models both as specifications and source of test UC Discovery Grant and the Industry University Co- cases include the definition of domain- and purpose- operative Research Program, as well as by funds from specific abstraction levels, tools for push-button gen- the California Institute for Telecommunications and eration of tests, and the definition of domain-specific Information Technology (Calit2). and domain-independent test case specifications. It is unclear if the effort, including synchronization, of 6. References maintaining both a model and a piece of code is justi- [AKMP05] J. Ahluwalia, I. Krüger, M. Meisinger, W. Phil- fied by the resulting quality of systems and test cases. lips: “Model-Based Run-Time Monitoring of End-to- Embracing all three classes of models, further open End Deadlines”. Proc. EMSOFT, 2005 research problems include the question of how to de- [Aut06] AUTOSAR consortium: www.autosar.org, 2006 rive detailed behavior models from more coarse- [BBC+01] K. Butts, D. Bostic, A. Chutinan, J. Cook, B. Mi- grained ones (§4.2), how to map this functionality to lam, and Y. Wang, “Usage Scenarios for an Automated software components and possibly different ECUs,

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007 Model Compiler”. Proc. EMSOFT, LNCS 2211, pp. 66- [HS06] T. Henzinger, J. Sifakis: “The Embedded Systems 79, 2001 Design Challenge”, 2006 [BBJ+05] A. Bauer, M. Broy, J. Romberg, B. Schätz, P. [ISO01] ISO. Road Vehicles – Controller Area Network Braun, U. Freund, N. Mata, R. Sandner, and D. Ziegen- (CAN) – Part 4: Time Triggered Comunication. Stan- bein: “AutoMoDe—Notations, Methods, and Tools for dard ISO/CD 11898-4, International Organization for Model-Based Development of Automotive Software”. Standardization, 2001 Proc. SAE 2005 World Congress, Detroit, MI, April [Kof05] L. Kof: “Text Analysis for Requirements Engineer- 2005. Society of Automotive Engineers ing”. PhD thesis, TU München, 2005 [BBD+06] M. Bechter, M. Blum, H. Dettmering and B. [KNP04] I. Krüger, E. Nelson. K.V. Prasad: “Service-based Stützel: “Compatibility models”. Proc. 3rd Intl. Work- Software Development for Automotive Applications”. shop on SW Engineering for Automotive Systems, pp. Proc. CONVERGENCE 2004, 2004 5-12, 2006 [KSL+03] G. Karsai, J. Sztipanovits, A. Ledeczi, T. Bapty: [BCC+04] A. Benveniste, B. Caillaud, L. Carloni, P. Caspi, “Model-Integrated Development of Embedded Soft- A. Sangiovanni-Vincentelli: “Heterogeneous Reactive ware”. Proceedings of the IEEE, January, 2003 : Capturing Causality and the Cor- [Mat06] The MathWorks, Inc., www.mathworks.com, 2006 rectness of Loosely Time-Triggered Architectures [MHB+01] R. Mores, G. Hay, R. Belschner et al.: “FlexRay (LTTA)''. Proc. EMSOFT, September 2004 – The Communication System for Advanced Automo- [BG92] G. Berry, G. Gonthier: “The ESTEREL synchronous tive Control Systems”. Doc. No. SAE 2001-01-0676, programming language: design, semantics, implementa- SAE, 2001 tion”. Sci. Comput. Program. 19, 2 (Nov. 1992), 87-152, [P06] preeTEC: “TDL Tool Suite”. http://www.preetec.com/, 1992 2006 [BKP+07] M. Broy, I. Krüger, A. Pretschner, C. Salzmann: [PP04] W. Prenninger, A. Pretschner: “Abstractions for “Engineering Automotive Software”. To appear in Pro- Model-Based Testing”. ENTCS 116:59-71, 2004 ceedings of the IEEE, 2007 [PP05] A. Pretschner, J. Philipps: “Methodological Issues in [BLP04] S. Bühne, K. Lauenroth, K. Pohl, M. Weber: “Mod- Model-Based Testing”. Model Based Testing of Reac- eling Features for Multi-Criteria Product-Lines in the tive Systems, LNCS 3472, pp. 281-291, 2005 Automotive Industry”. Proc. 1st Intl. Workshop on SW [PPW+05] A. Pretschner, W. Prenninger, S. Wagner, C. Engineering for Automotive Systems, pp. 9-16, 2004 Kühnel, M. Baumgartner, B. Sostawa, R. Zölch, T. [BOJ04] M. Beine, R. Otterbach, M. Jungmann: “Develop- Stauner: “One Evaluation of Model-Based Testing and ment of Safety-Critical Software Using Automatic Code ist Automation”. Proc. 27th Intl. Conf. on Software En- Generation”. Proc. SAE World Congress, 2004 gineering, St. Louis, 2005, pp.392-401 [Bos01] Robert Bosch GmbH: “CAN Specification Version [PT06] W. Pree, J. Templ: “Modeling with the Timing Defi- 2.0”, 1991 nition Language TDL”. Proc. Automotive Software [CN01] P. Clements, L. Northrop: “Software Product Workshop, San Diego, 2006 Lines—Practices and Patterns”, Addison Wesley, 2001 [Rom06] J. Romberg: “Synthesis of distributed systems from [DK04] J. Dannenberg, C. Kleinhans: “The Coming Age of synchronous dataflow programs”. Dissertation, Tech- Collaboration in the Automotive Industry”, Mercer nische Universität München, 2006. Management Journal 18:88-94, 2004 [SC04] I. Stürmer, M. Conrad: “Code Generator Testing in [D06] Decomsys: “Designer Pro”, http://www.decomsys. Practice”. Proc. GI Jahrestagung (2), pp. 33-37, 2004 com/htm/frs/3_flexraydesign_pro.htm, 2006 [Spi01] B. Spitzer: “Modellbasierter Hardware-in-the Loop [FGG05] A. Ferrari, G. Gaviani, G. Gentile, M. Stefano, L. Test von eingebetteten elektronischen Systemen”. PhD Romagnoli, M. Beine: “Automatic Code Generation and Dissertation, Univ. Karlsruhe, 2001 Platform Based Design Methodology: An Engine Man- [Sta04] T. Stauner: “Properties of Hybrid Systems—A agement System Design Case Study”. Proc. SAE World Computer Science Perspective”. in Congress, paper 2005-01-1360, 2005 System Design 24(3):223-259, 2004. [GBB+06] E. Geisberger, M. Broy, B. Berenbach, J. Kaz- [WM95] R. Weeks, J.J. Moskwa, “Automotive Engine Mod- meier, D. Paulish, A. Rudorfer: “Requirements Engi- eling for Real-Time Control Using MAT- neeringReference Model (REM)”. Internal Report, Soft- LAB/SIMULINK”. SAE Paper 950417, 1995 ware & Systems Engineering, TU München and Sie- [WW03] M. Weber and J. Weisbrod: “Requirements engi- mens Corporate Research Princeton neering in automotive development: Experiences and [GKS00] R. Grosu, I. Krüger, T. Stauner: “Hybrid Sequence challenges”. IEEE Software 20 (2003) 16-24 Charts”. Proc. 3rd IEEE International Symposium on [XBW98] X-by-Wire Consortium, “X-by-wire – Safety re- Object-Oriented Real-Time Distributed Computing lated fault tolerant systems in vehicles – final report”. (ISORC 2000), IEEE, 2000 Project BE95/1329, Contract BRPR-CT95-0032, 1998 [HCR+91] N. Halbwachs, P. Caspi, P. Raymond, and D. [Zav93] P. Zave. “Feature Interactions and Formal Specifi- Pilaud: “The synchronous data-flow programming lan- cations in Telecommunications”. IEEE Computer guage LUSTRE”. Proceedings of the IEEE, 26(8):20-28, 1993 79(9):1305–1320, September 1991 [HKK04] B. Hardung, T. Kölzow, A. Krüger: “Reuse of Software in Distributed Embedded Automotive Sys- tems”. Proc. EMSOFT, 203-210, 2004

Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007