Developing self-adaptive automotive systems

Marco Wagner 0 Ansgar Meroth 0 Dieter Zbel 0 0 D. Zbel Faculty of Computer Science, University of Koblenz-Landau , Koblenz, Germany Future Driving Assistance Systems (DAS) will have to react to changes within the system at runtime. This might be the case in Car-to-X systems where the availability of communication partners changes dynamically. Another example are systems like DAS for truck and trailer combinations where a trailer might be disconnected and replaced by another one several times a day. State-of-the-art DAS are not capable of handling these runtime changes. In our approach we make usage of the principles of Service-orientation to generate self-adaptive DAS on architectural level. But this technical approach requires the definition of a development process that fits into the practices within the automotive industry. This paper introduces SOMA4DDAS, a model-based development process based on the UML profile SoaML. SOMA4DDAS describes a tri-phase procedure to transfer an idea for a DAS into a detailed specification of the application and the Services involved. These phases are integrated into the core process for system and software development (CPSSD), a standard process within the automotive industry. The paper illustrates the benefits of this approach by developing a truck and trailer DAS consisting of 13 different Services. Driving is a complex set of different processes that constitute control loops on different levels. The most popular classification of driving tasks is according to [9] where the au- - thor distinguishes three tasks: The primary task aims at the stabilization (e.g. longitudinal movement, lateral movement ), the route keeping and the navigation of a car, the secondary task aims at operating the car devices (e.g. wipers, headlights etc.) and the tertiary task the operation of information, comfort and entertainment systems, often called infotainment [26]. ADAS developed in all three classes, mainly intended to the dimensions of safety (e.g. longitudinal and lateral stabilization, lane keeping, emergency breaking), comfort (e.g. headlight and wiping assistants) and efficiency (e.g. automated coasting). Automated and assisted driving is achieved by the interaction of different functional and physical instances which are connected via a network on physical level and make use of complex interfaces on the functional and logical level. The reasons for complexity are manifold. First, there is an increasing number of participating functional blocks (not necessarily corresponding to the number of physical units), second, the requirements to the interfaces grow with the functionality. Third, these functional blocks, whether they are in different physical devices or not, often come from different suppliers and not necessarily allow insight into their inner structure (e.g. their code) except for the interface. The big challenge for car manufacturers (often called OEMs) and first tier system suppliers is the integration on the base of a weak knowledge about the components. In [40] the authors find as the main reason of integration problems Poorly communicated module objectives or requirements. While the cited study considers mainly aspects of human behavior in integration, the car industry answers to the increasing safety, reliability and traceability requirements with a sophisticated development process organization that will be briefly discussed below. Future ADAS, however, will require totally different paradigms especially regarding situation awareness and changing configurations. Ad-hoc Communication between the so-called Ego-car, other vehicles, traffic participants and the infrastructure, often referred to as Car-to-X communication (See also: [19]) has immediate effect to the functionality and the behavior of hitherto self-contained vehicles [18]. While vehicle systems of the past could be comprehensively described during the design phase, future systems will be open to aftermarket extensions and variations. Typical examples are the retrofitting of infotainment and assistance systems with access to the cars internal network, the integration of mobile devices (see e.g. [25]), and the varying configuration of installations, as in commercial vehicles, agricultural machinery or in truck and trailer combinations. 1.2 Development processes as a measure for more safety and reliability In the past ten years, the automotive industry uses basically two approaches to solve the integration problem: The technical and the organizational one. On the organizational side, car industry takes advantage of highly standardized support processes, especially in requirements management, quality assurance, configuration management and project management. Standard models like CMMI [10], Automotive SPICE [27] and ISO TS 16949 [20] are widely spread out between OEMs and their suppliers. Technically, the development follows a systems engineering approach which breaks down the system requirements to subsystem and component levels, of which the functionality and properties are directly derived from those of the preceding system level. On each of them, logical, behavioral and technical models are created that correspond to a set of test cases for the future integration task on that level (see: [35]). This process is widely known as the V-model. It allows considering as many aspects of the system as possible in the specification phase and aims at comprehensive testing and integration. As a disadvantage, all requirements and possible systems configurations in one particular systems level should preferably be known at the beginning of the development phase of this level, and requirements changes often lead to disproportionately high additional work and expenses. Note, that the functional requirements of a vehicle are by far exceeded by quality requirements, e.g. regarding efficiency, maintainability, portability, usability and safety. In order to assure, for instance, functional safety, definitions of the safety lifecycle, a hazard analysis and risk assessment, and a functional safety concept in the beginning of the project are mandatory, as well as the subsequent specification of the technical safety requirements on each system level (ISO 26262), each strongly depending on a full understanding of the technical boundary conditions and behavior of the system. With increasing cost, variability and time-to-market demands, a higher re-use rate [22], the access to standardized and highly mature functional modules and a hierarchical model driven design (as e.g. shown in [11]) are necessary to cope with the integration challenge. Many of the above noted challenges have been addressed with the AUTomotive Open System ARchitecture (AUTOSAR) approach [21]. AUTOSAR considers a system architecture with highly reusable basic software, a runtime environment and a thoroughly specified application programming interface (API), as well as a development methodology. It strongly supports re-us (...truncated)