Prototyping Automotive Cyber- Physical Systems

Prototyping Automotive Cyber- Physical Systems Sebastian Osswald Technische Universität München Boltzmannstr. 15 Garching b. München, Germany osswald@ftm.mw.tum.de Stephan Matz Technische Universität München Boltzmannstr. 15 Garching b. München, Germany matz@ftm.mw.tum.de Markus Lienkamp Technische Universität München Boltzmannstr. 15 Garching b. München, Germany lienkamp@ftm.mw.tum.de Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the Owner/Author. Copyright is held by the owner/author(s). AutomotiveUI '14, Sep 17-19 2014, Seattle, WA, USA ACM 978-1-4503-0725-3/14/09. http://dx.doi.org/10.1145/2667239.2667304 Abstract Cyber-Physical Systems (CPS) in the automotive engineering process address the challenge of focusing on the interaction with physical processes rather than to cope with limited computational resources. The aim is to understand the joint dynamic of software, networks and physical processes, including the human in a vehicle. In the interplay between software and hardware, the user is an integral component and needs to be kept in the loop to understand, validate and control automotive prototypes. With the focus on information systems, this becomes particularly challenging with an increase of information sources. We define four categories to assess the effort for CPS prototyping to point out challenges and potential related to human-in-the-loop requirements. Author Keywords Cyber-Physical Systems, Prototyping, Automotive, Automotive User Interfaces ACM Classification Keywords H.5.2 User Interfaces: Prototyping Introduction In the field of automotive embedded systems, the integration of physical processes and computing has been in the focus since Volkswagen introduced the first microprocessor to control the fuel injection (Bosch D-

Jetronic) in the Volkswagen 1600 Type 2 E back in 1968. These, and following embedded systems were used to combine physical processes with computing systems in the vehicle. As most of the embedded systems are performing a unique task for themselves, they are not optimized to share and cooperate with other control units. These software optimized control units have no outside connectivity that can alter their behavior. Embedded systems are closed systems that are challenged nowadays with the transformation that comes from networking different devices [1]. Networking poses considerable technical challenges as the automotive network relies on concurrency and real-time communication, as timing is a major characteristic of the system. Tesla for examples, integrates a software management system in their vehicles that is utilized for repair and performance enhancement updates over the air [2]. This allows for changing and updating the software of the electronic control units without a workshop stop. Nevertheless, this is not comparable to the capabilities of an interconnected CPS. The envisaged interconnected CPS for a vehicle that supports the driver while driving and manage a variety of devices and control units, requires a more open setup. In a network environment with several processing platforms, the techniques used for benchmarking encased and closed systems are thus not adequate anymore. The possible conditions for testing these systems are multiplied in a way that evaluating these systems under all conditions is not possible anymore. The systems behavior is getting more unpredictable than before. In the area of automotive engineering, major steps were already reached in creating automotive CPS. An increasing number of electronic control units in vehicles indicates a tightly integration of the physical parts and the embedded computers. For now, the focus is nevertheless still vehicle-centric and does not incorporate information about the environment and the human. These system are not well suited to address the needs of humans that are embedded in the system e.g. as human-in-the-loop. Further, the technology lacks in terms of innovation and compatibility as it moves too slowly to keep pace with other technologies [3]. This becomes distinct in comparison to the highly networked mobile operating system that are more often integrated into the vehicle information system [4]. As the CPS design challenge is rather the intersection between the physical and the cyber than the union [5], it is not sufficient to understand only one side of the integrated components. As the embedded systems features mostly discrete behaviors and the physical systems are determined by an analogue behavior, the human is defined as an analog entity - a physical plant - that is depending on the laws of physics. The CPS is accordingly a combination of discrete and analogue behaviors. We will focus on how the human is integrated into the CPS cycle. To address the issue of a rather vehicle-centric design, a combination with a user-centric engineering approach seems to be fruitful [6]. This would come in hand with techniques from iterative engineering and design cycles that utilizes prototyping as a method to realize taskspecific systems/features. In order to combine prototyping with CPS design, we will first go into detail about how automotive CPS can be defined.

Figure 2: Example structure of an automotive cyberphysical system with a human-in-the-loop. Automotive Cyber-Physical Systems Based on the example structure of a CPS from Lee [5], Figure 2 includes the three main parts of a CPS. The physical plant (1) refers to the physical part of the system, which in general include all non-computational processes, including mechanical parts as well as the human. The network fibre (2) consist in state of the art vehicles in most cases of a controller area network or Flex Ray. The network fibre enables the platforms to communicate. The platform I+II are computational platforms and form the cyber part of the CPS. These platforms include computing units, sensors and interfaces. The workflow in Figure 2 is based on two networked platforms. Each platform provides its own sensors, computing units and physical interfaces. Platform 2 controls the mechanical parts (e.g. the wipers) and the actuators for the physical interface to the human (e.g. a tell tale). The presentation of the telltale and the wiper movement affects the data provided by sensor III of platform II. This might be induced by the acceleration pedal as physical interfaces, initiated by the driver who accelerates as the wipers clear the windscreen. On basis of the data from sensor III, computation III implements a control law. This law determines what commands needs to be issue to the actuators. This feedback control loop is extend by additional

measurements from platform 1, specifically sensor I+II. These data is processed by computation I and then communicated via the network fabric to computation II, which implements another control law. Both is merged subsequently and submitted to the actuators serving the physical interfaces for both physical plants. In a vehicle, there are nowadays dozen of electronic control units that communicate via the network fabric. Some of these systems, like the wiper example or the radio, can be seen as small, simple CPS systems. In the future, connected systems with lots of sensors and computation units will become more important. The sensors, computation units and even the connected humans do not even have to be in one vehicle. One use case for a CPS would be the range prediction for electric vehicles. Unlike one sensor, one computation unit and one display in a conventional vehicle, there are several voltage, current and temperature sensors in the vehicle that one can make use of. An interface to the human serves further as data source to collect data about the driving behavior and the intended target that can be combined with sensor data in other vehicles and traffic data from infrastructure components. All this information is processed in computation units in the vehicle or on a server. The result hast to be submitted to the human driver. Unlike the conventional fuel gage this information is more complex as it can contain e.g. alternative routes, recharging points and cues to alter driving behavior. Prototyping CPS To date, only little information can be found on the prototyping process of automotive CPS. More often it is discussed how different prototypes can be categorized based on their fidelity e.g. low-fidelity and high-fidelity prototypes [7] or based on their focus e.g. exploratory, experimental and evolutionary [8]. This leads up to the classification from Mayhew who introduced further subcategories [9]: exploratory (exploratory) experimental (experimental, performance, hardware) organizational (ergonomic, functional) The focus of this categorization is mainly to define first the purpose of your prototyping process and decide then what kind of prototype is required to reach the targeted goal. Nevertheless, these categories does not primarily target the effort one has to make to prototype, besides some rapid prototyping approaches that mainly want to do something quick and reduce costs. The majority of low fidelity prototyping methods cannot be applied to prototype a basic CPS as e.g. a paper prototype cannot address the complexity of a CPS. It is thus necessary to introduce new categories of prototypes that rather acknowledge the manifoldness of requirements, development effort, system definition effort, prototyping cost and man-hours it will need to complete the prototype. In the following we propose four categories for assessing the prototype state to develop automotive CPS. Software Cost & Effort: As CPS prototyping involves mainly software engineering, we propose to address the cost and effort estimation of a CPS prototype with the constructive cost model. The model uses a regression formula with parameters that are derived from historical project data and current project

characteristics. The basic models builds upon the factors: Effort Applied (E) = ab(kloc) bb [person-months] Development Time (D) = cb(effort Applied) db [months] People required (P) = Effort Applied / Development Time [count] Safety: We further assume that safety has a major impact on the prototyping process. For this purpose we propose to apply the failure mode and effects analysis (FMEA) to address safety concerns during the prototyping phase. This method helps to identify potential failure modes and risks during the development process. Calculated by the formula severity * occurrence * detection = RPN risk priority numbers (RPN) are created, sorted and assigned to developers. User requirements: To keep the human in the loop [10] the requirement engineering effort needs to be elevated [6]. The requirements of users rise exponential with the number of services and functions available. Depending on the degree of interconnectedness of the system components, the number of possible interfaces, devices and information is rising. New methods that specifically targets the automotive context to derive the users requirements targeting CPS are needed. Engineering: The work to e.g. engineer mechanical parts, set up the hardware and do the wiring of the prototype need to be addressed as well. We propose an expert estimation of the engineering effort, which is expressed in a severity factor. Challenges The challenges for building CPS prototypes targets the areas of safety and complexity management. Compared to an embedded system, a CPS comprises of interconnected sensors, actors and computation units. This leads to a huge amount of possible system states that cannot individually be validated. The physical world is not predictable and the system will not be operated in a controlled environment. It must be robust to a variety of conditions especially in the automotive context. According to the number of sensors, the risk of a failure multiplies. As it is not possible to validate every imaginable system state, environmental condition or failure, a self-stabilizing system architecture has to be developed. Possible errors could be compensated by plausibility checks and state estimation. The component behavior at any level of abstraction should be made predictable and reliable if technologically feasible. If it is not possible, the next level of abstraction above these components must compensate with additional robustness (e.g. the interfaces). These measures mean a lot of additional effort that is not always necessary. During the prototyping phase, several safety levels have to be defined. While safety for small demonstrators is not critical, it becomes the main focus in a drivable prototype. Besides safety, prototyping of CPS is challenging for complexity reasons. Computation units, sensors and actors often only support one specific communication protocol (e.g. CAN, PWM, LIN). With the given amount of elements in the system, several communication networks with different topologies are needed. This increases the system complexity and the wiring effort. Wireless

communication is one solution that works for specific applications, but lacks the robustness in an automotive environment. Thus, current trends in research like power line communication [11] needs to be targeted in the future. Summary To successfully make the transition from traditional prototyping to next-generation CPs prototyping, new factors needs to be addressed in the CPS prototyping process. Focusing on software cost & effort, safety, user requirements and engineering demand will help to make the rising prototyping effort more transparent to managers. Further, the holistic CPS prototypes approach will help to keep the human in the loop and develop user-friendly devices as they are needed to compensate possible system state errors. Acknowledgements This work was conducted at the Institute of Automotive Technology Technische Universität München. References [1] E. A. Lee, Cyber Physical Systems: Design Challenges, in 2008 11th IEEE International Symposium on Object Oriented Real-Time Distributed Computing (ISORC), 2008, S. 363 369. [2] R. Ordman, Efficient over-the-air software and firmware updates for the Internet of Things, Embedded Computing Design. [Online]. http://embedded-computing.com/articles/efficientsoftware-firmware-updates-the-internet-things/. [Accessed: 24-Juli-2014]. [3] D. Work, A. Bayen, und Q. Jacobson, Automotive cyber physical systems in the context of human mobility, in National Workshop on high-confidence automotive cyber-physical systems, Troy, MI, 2008. [4] S. Osswald, P. Sheth, und M. Tscheligi, Hardwarein-the-loop-based Evaluation Platform for Automotive Instrument Cluster Development (EPIC), in Proceedings of the 5th ACM SIGCHI Symposium on Engineering Interactive Computing Systems, New York, NY, USA, 2013, 323 332. [5] E. A. Lee und S. A. Seshia, Introduction to embedded systems: A cyber-physical systems approach. Lee & Seshia, 2011. [6] M. Broy und A. Schmidt, Challenges in Engineering Cyber-Physical Systems, Computer, Bd. 47, Nr. 2, S. 70 72, 2014. [7] J. Rudd, K. Stern, und S. Isensee, Low vs. Highfidelity Prototyping Debate, interactions, Bd. 3, Nr. 1, 76 85, Jan. 1996. [8] C. Floyd, A systematic look at prototyping, in Approaches to prototyping, Springer, 1984, S. 1 18. [9] P. J. Mayhew und P. A. Dearnley, An alternative prototyping classification, Comput. J., Bd. 30, Nr. 6, 481 484, 1987. [10] G. Schirner, D. Erdogmus, K. Chowdhury, und T. Padir, The future of human-in-the-loop cyberphysical systems, 2013. [11] P. Tanguy, F. Nouvel, und P. Maziearo, Power Line Communication standards for in-vehicule networks, in Intelligent Transport Systems Telecommunications,(ITST), 2009, 533 537.