Developing self-adaptive automotive systems

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 author 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 car’s 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.

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-use, configuration and variant management and a homogenous system analysis and description. However, AUTOSAR does not support ad hoc communication with components that were not specified during the system design phase.

As mentioned earlier, many future Driver Assistance Systems like the ones basing on Car-to-X communication set up the requirement to allow changes of the software and system architecture at runtime. We call these highly distributed, dynamically changing systems Distributed Driver Assistance Systems (DDAS). In contrast, even cutting-edge development approaches like AUTOSAR do not support the design of such systems. On the other hand runtime adaptive systems have been used in other domains for many years now. One popular method to create dynamically changing, distributed applications is the usage of Service-oriented Architecture (SOA). The basic idea of SOA is, that all functionalities are encapsulated into so called Services. These Services are reachable through a well-defined interface from anywhere in the network. Each Service holds a contract that describes the ways of accessing this functionality. In order to build an application the Services are composed by an orchestration algorithm. These characteristics perfectly match the requirements set up by future DDAS. The heterogeneity of the functionalities is hidden behind the interface. Furthermore, the interfaces ensure compatibility when delegating the development to suppliers. Runtime adaption is carried out by re-orchestrating the Services in the event of a system change. Furthermore SOA-based systems are able to handle another issue coming up with the appearance of DDAS. Since these systems are no longer planned in a central manner, it is quite likely that duplicates of functionalities may be present. The system must be able to handle the presence of these duplicates. In Service-oriented applications the orchestration algorithm is in charge for that. Therefore, these applications distinguish between Services Classes and Service Instances. While a Service Class describes the functionality offered, a Service Instance is an actual software module. In this sense, an application is defined at design time as a combination of Service Classes while it is formed at runtime by the selection of one Service Instance for each Service Class. In order to create the best application possible at that very moment each Service Instance is equipped with a Quality of Service parameter. This property is accessible through the interface of the Service and is used to determine the best composition of Service Instances possible. In order to use SOA to build DDAS we developed the “Service Oriented Driver Assistance” (SODA) framework. This framework merges all the advantages mentioned in a very efficient middleware. It is tailored to automotive systems in the sense of taking resource constraints into account and in basing on state-of-the-art automotive network systems. Besides it is organized in a completely distributed fashion to keep it manageable and to avoid single points of failure.

But fulfilling the requirements set up by future DDAS technically is not enough. A new approach must also be capable of being integrated in the development processes of the automotive industry. Therefore we extended the SODA framework with a phase-oriented model-driven design process. This paper will prove, that this design process can be integrated in today’s automotive development schemes. We decided to pick up the so called “core process for system and software development” (CPSSD) published by Schäuffele and Zurawka in [35]. It is a well established model for system development in the automotive industry basing on the popular V-model approach.

The remainder of the paper is organized as follows: Sect. 2 gives an overview on Service-oriented approaches in the automotive domain as well as on development processes for SOA applications. Section 3 introduces our approach to develop self-adaptive Service-based DDAS and how this development process is integrated into CPSSD. In Sect. 4 a case study is presented to validate the development process. Finally, Sect. 5 concludes the paper.

In recent years, there have been several approaches to apply SOA-principles to automotive software systems. Some of these approaches aim on keeping software modules re-usable. Shokry et al. in [36] are presenting an approach to use Service-based computing to manage software product lines in cars. The main idea is to create functionalities in the form of Services that are orchestrated at design time to build an application. However, this approach does not consider any changes at runtime. The approach presented by Krueger et al. in [23] follows the same ideas when describing the development of a Service-based central locking system. Besides the restriction on design-time orchestration the described middleware is using a real time Common Object Request Broker Architecture (RT CORBA) that runs on high level operating systems only. This fact in combination with the strict resource constraints in the automotive industry makes a breakthrough of this approach quite unlikely. Baresi et al. in [4] describe a system using an already existing SOA framework that suffers the same disadvantages. Through basing on Java the system requirements are too high for being deployed on most of the automotive electronic control units (ECU). The necessity of using relatively powerful hardware limits the field of application of these two approaches to for example the infotainment system of a vehicle. The papers [12] by Eichhorn et al. and [8], written by Bohn et al., are describing systems basing on the Device Profile for Web Services (DPWS). DPWS is very interesting for our problem scenario as it is tailored to be used on embedded systems. However, this standard uses IP-based communication which is quite different from the network systems used in today’s cars. Additionally, the messages exchanged between the Services are based on XML files which produces a huge amount of traffic considering the transfer rates of automotive networks. Besides, [12] does only allow static, never changing configurations. The two approaches described by Xu and Yan in [39] and Ragavan et al. in [33] are focusing on a different scenario. Instead of implementing the internal functionalities as Services, they describe a gateway approach. These gateways offer internal data of the car to the outside world and vice versa. [39] is using this data to call Web Services located in the cloud, [33] on the other hand sets up an ECU using the Java-based Open Services Gateway initiative (OSGi) to allow a vehicle to invoke Services offered by the outside world and vice versa. The approach of Gacnik et al. described in [14] follows a similar idea. The authors describe a traveling salesman problem where a connected DAS extends its functionality by using Web Services to for example take train time tables into account when navigating. Although the usage of gateways to encapsulate car functionalities into Services and allows to call Services from outside of the car is a very interesting concept it cannot be transferred into our problem domain. This is because the software components on the vehicle are not implemented as Services and thereby are not runtime adaptive. A last approach which is very interesting in this context is the iLAND project described for example in [15]. Although it is not targeting on automotive systems, it is a very interesting approach to bring Service-oriented computing principles into the embedded domain. Similar to our scenario, the idea is to automatically re-configure a number of embedded Services to create an application. Unfortunately, the process of re-configuration is shaped in a way that does set up the need for a central device that overlooks the whole system. This fact creates a single point of failure scenario which is not acceptable. The number of approaches to bring Service-orientation into the automotive domain proves the potential of this paradigm. However, none of the approaches discussed here completely suites the demands of this problem scenario. In order to close these gaps the SODA middleware has been developed.

Through to the popularity of Service-orientation a huge number of process models to develop such systems has been published in recent years. In 2009 Thomas, Leyking and Scheid identified 21 different approaches in [38]. Most of the currently available models are tailored for a special purpose, require a particular tool chain or concentrate on one field of application only. However, none of them suits to the domain of automotive SOA solutions. Instead of developing yet another model, we decided to find a process model that can be customized to this special scenario and integrated into the CPSSD development process. In order to do so, criteria have been developed and the available approaches have been evaluated based on these. The following criteria have been defined:

Our first criterion is that the modeling approach has to allow a complete system specification which includes the specification of the Services as well as the Service Architectures. This also implies that a detailed technical point of view should be assured rather than focusing on the business domain which is very common using SOA. Finally, concrete methods or techniques on how to carry out the steps within the process model should be proposed. Due to the lack of specialized approaches for the automotive domain the second criterion states that the field of application should not be restricted. Specialized models, used for Web Services for example, are not very promising since their focus is too narrow. Converting these to suit embedded automotive systems would change too many of their essential ideas if possible at all. Another criterion is that the starting position at the very beginning of the process should be variable. This is important because the process model should allow new developments as well as migrating existing systems into SOA. The fourth criterion is that tool support should be given. Using a tool that for example allows modeling the system graphically reduces development time. In addition, implemented validation functionalities decrease the probability of semantic errors. Furthermore, the modeling language deployed should be widely-used and hereby accepted. This demand is set up because of the nature of development teams in the automotive industry. These teams are normally constituted by members with different backgrounds such as software engineers, electrical engineers or mechanical engineers. A widely-used modeling language simplifies the communication within the group and reduces the risk of misunderstandings. Finally, the last criterion is that the development process has to be capable of being integrated into CPSSD. Using these criteria, eleven process models are analyzed. The first one is a model proposed by Stein and Ivanov in [37]. The model is based on ten phases starting with a business process model ending with the deployment of the developed system. It focuses on business processes and the modeling languages suggested belong to the domain of Web Services. A similar model, the Enterprise SOA Roadmap method is presented in [17]. This model also emphasizes on business modeling since only one of the five steps to be executed is technical. Both of the process models violate criteria two that they shouldn’t restrict the area of application. Other approaches lack of concrete modeling techniques. Pingel [32] for example, introduces a technology independent five phase model extending well-known approaches. Another approach in this category is a proposal of Mathas [24] which extends the software lifecycle model by adding some SOA-specific tasks and roles while staying coarse-grained. The Service-oriented Modeling Framework developed by Bell is quite generic, too [6]. The idea of the author is to design a concrete process model for every case of application derived from his abstract methodology. Bell also proposes a special design notation which violates the criterion of using a widely-used modeling language. All these models are rather to be seen as suggestions on how a process model may be set up than being a concrete model itself. Unlike the previously named ones the models “Service-oriented design and development” [31] by Papazoglou and van den Heuvel and “Creating Service-oriented Architectures (CSOA)” [5] developed by Barry are technical in nature. Both of them are phase-oriented and contain practical techniques to be performed in those phases. Through basing on modeling languages like the business-oriented “Business Process Modeling Language (BPML)” or the “Business Process Execution Language for Web Services (WS-BPEL)” they cannot be used for other fields of application without major changes. This fact violates criterion two. Another approach is presented by Nadhan in [28]. The author describes a seven step procedure to migrate an existing solution into a SOA-based system focusing on technical issues. Targeting only on the migration scenario this model cannot be used for new developments. In doing so criterion three is violated. Some highly interesting approaches are using the Service-oriented modeling language (SoaML), a notation created to model and design SOA-based systems. This is a promising approach because the language itself satisfies the criteria set up in being not restricted to one field of application and being widely used since it is a profile of the popular Unified Modeling Language (UML). One of these process models is presented in [16]. The authors describe the development of a Service-based monitoring system by identifying and specifying the needed services. Although this is very promising, it does not allow specifying the architecture of the overall system which violates the criterion of enabling the user to carry out a complete system specification. Another methodology using SoaML introduced in [13] closely follows the processes defined in the Model-driven architecture (MDA) approach published by the Object Management Group. Tool support is granted by the modeling tool “Modelio”. This process model defines several specification steps within the computational independent model and the platform independent model of MDA. The approach is very close to “Service-oriented Modeling and Architecture (SOMA)” presented in [2]. This phase-oriented lifecycle model is based on the “Rational Software Architect” and is also free of any restrictions with respect of the area of application. Both of the lastly named methodologies are fitting the criteria set up earlier in this paper. The reasons why SOMA is favored is being more focused on technical issues and offering a more straightforward workflow. Furthermore, the phases of SOMA can be integrated into CPSSD more easily.

The CPSSD development lifecycle is the result of many years of experience of it’s authors Jörg Schäuffele and Thomas Zurawka. It reflects the processes actually used in the automotive industry in recent years. It is basing on the well-known V-model while being tailored to the specific needs of the automotive domain. Just like the V-model it is split up into two main parts. The first one that builds the left arm of the “V” consists of the specification and implementation phase. The second one that builds the right arm holds the integration and testing phases. The V-model is also divided into two levels. The upper part of the model is called the application level and consists of activities that refer to the overall application. The lower part of the model is called the component level. Here, all activities are related to some components of the application to be developed. Compared to similar development models like for example the waterfall model, introduced by Royce [34] or the spiral model, published by Boehm in [7] its main difference is the extension of the integration and testing phase. This addition leads to a better link between the specification and the test proceedings. The design workflow passes through the activities starting on the top left of the “V”. By going down the left arm first the application and then the components of this application are specified in increasing detail. At the very bottom of the left side the software components are implemented. The development lifecycle then moves on to the right side of the “V”. The level of detail decreases with every activity that leads the development team up again. After testing the particular components, these are more and more integrated into subsystems. These subsystems are tested again and then integrated into the application. The V-model ends with a test of the overall system. Figure 1 presents the V-model in the automotive-specific variant CPSSD. In this paper we focus on the specification of self-adaptive automotive systems. In this sense we restrict the rest of the paper to the left arm of the “V”. According to [35] the first activity of CPSSD is to specify the so called Logical System Architecture (LSA). The LSA is an abstract architecture that does not provide any technical details. It is an intermediate step building a bridge between the requirements of the application and the Technical System Architecture (TSA). In this working product logical components are determined. Furthermore the functionality as well as the interfaces of these logical components are defined. In a next step, the TSA is specified. In contrast to the LSA this description of the application already contains some decisions on how functionalities of the application will be realized. In order to convert the logical system architecture into the technical one, a team of specialists is making technical decisions and proposes suitable solutions. After the TSA is defined, the component level is reached. This means that the specification of the overall application is done and from now on the identified components are specified with increasing detail. It also includes, that the development process splits up into a separate development process for each component to be designed. The authors propose a two-stage process. In the first part of this process, the software architecture of each component is defined. This step defines several software components including their interfaces to each other that build the overall software architecture. These individual software components are then specified in more detail. The last activity of the left arm of the “V” is to implement the specified components.

One important characteristic of the CPSSD development lifecycle is the transition from system level to component level. At this point not only the overall architecture is defined and the development process is now split up into several smaller processes for the component design. In the automotive industry these processes are often delegated to specialized teams of developers or they are outsourced to suppliers. In some cases these components are even purchased as commercial of the shelf solutions.

As mentioned in Sect. 2.2 we have chosen SOMA as a base of our development process for Service-oriented applications. The SOMA methodology is a phase-oriented process model first published by Arsanjani in [1] in 2004. It is based completely on the modeling language SoaML. This ensures a consistent procedure where the outcome of each phase is documented in some kind of model which can directly be used in the next development step. Figure 2 gives an overview of the seven phases of SOMA. The first two of these are run simultaneously. While “Business Modeling and Transformation” generates a first, semi-formal description of the requirements, “Solution Management” sets up the project management processes. These two steps are followed by “Identification” to derive possible Service candidates. The “Specification” phase enhances the candidate descriptions and transfers them into Service specifications. In the “Realization” step the focus swaps from functional to non-functional requirements that are now added to the Service description. As the specification work is done now, the “Implementation” phase guides the developer while writing code. In the last phase the software application is put into operation. Although SOMA is meant to be used in any kind of domain there are some issues that have to be worked out in our scenario of usage. These issues are: In order to address the first two issues we did some refinements to the steps of the SOMA methodology. Furthermore instead of carrying out the whole lifecycle defined in SOMA we restrict our approach to the three phases marked in Fig. 2. These three steps are integrated into the left arm of CPSSD’s “V”. The reason for the restriction is our focus on the specification of the functional parts of adaptive embedded systems. This functional specification is finished within in this three phases. The remainder of this chapter will describe the refined process model to implement self-adaptive Service-based automotive applications.

The refined SOMA process model to develop Service-based application using the SODA middleware is called SOMA4DDAS. An overview of this process model is presented in Fig. 3. The first one of the three steps of SOMA4DDAS replaces SOMA’s “Business Modeling and Transformation”. We decided to not only change the context of this step but also it’s name to make clear that the refined step is capable of handling a much broader range of systems. In the remaining two steps title and purpose have been left unchanged compared to SOMA. However, the procedures within these three steps have been significantly tailored to the development of self-adaptive DDAS.