2.2.1 Introduction to Automotive Release Processes
The automotive development process for electronic systems is oriented on the V-model (Scha¨uffele and Zurawka 2003, p. 19). The V-model is a graphical representation of a system development cycle. It was introduced in 1992 to improve software development processes (Rausch and Broy2008, p. 2) and summarizes the main steps in a development project (see Fig.2.1).
The left side of the “V” includes a top-down process that starts with the definition of system requirements and ends in the implementation of software elements. The right side of the “V” follows a bottom-up process and involves system integration and test activities. The release process is the final step of the V-model (see red box in Fig.2.1). Here, the developed system is tested against its system requirements. Therefore, the release process bridges the gap between system development and operational use (Scha¨uffele and Zurawka 2003; Reif 2007).
A short release process facilitates a fast market launch but needs efficient integration and test processes. Therefore, the release is one of the most important elements of the development process (Sundmark et al.2011).
2.2.2 Regulatory Framework for Automotive Release Processes
Because the release bridges the gap between system development and its opera- tional use by the customer, it has to assure that the system fulfills all requirements.
Therefore, the release decision is of high legal relevance. Product liability laws, for example the German Produkthaftungsgesetz (ProdHaftG), ensure that the manu- facturer as well as the suppliers are held responsible for their products. Therefore, they have to make certain that their products are developed according to the present state-of-the-art. The state-of-the-art represents current laws, regulations and stan- dards, as well as patents and publications (Reuter2011).
Fig. 2.1 V-Model (according to HTWK Leipzig2014)
Two kinds of requirements are taken into account in automotive release pro- cesses. On the one hand, there are requirements that focus on the properties and functionalities of vehicles. Examples for this category are vehicle certification laws, e.g. UN ECE R13 H (2015) or FMVSS 126 (2007) for automobile brake systems, or safety standards e.g. ISO 26262 (2011) for the functional safety of road vehicles.
On the other hand, there are requirements that deal with the development process.
Examples for this class are IATF 16949 (2016), which focuses on quality manage- ment in the automotive industry, or Automotive SPICE (2015), which includes software development processes.
2.2.3 Implementation of Automotive Release Processes
The release is the result of approval and acceptance tests for the developed and parameterized system. The tests are part of a formal process and include verification and validation activities (Sundmark et al. 2011; Reif 2007). Release tests are usually black-box tests, where the functionality of a system is examined without insight into its internal structure (Borgeest2008). They consist of a great variety of different tests, which focus on diverse targets. Typical test categories for automo- tive controllers are for example (Borgeest2008):
• Functional tests
• Robustness tests
• Recovery tests
• Benchmarks
• Configuration and compatibility tests
• Usability tests
• Security tests
• Endurance tests.
Release tests presume that the system is tested in its final environment under customer operating conditions to ensure that all requirements are fulfilled. Because of that, a huge amount of release tests is executed in real vehicles. Common test targets are driving dynamics, acoustics, reference and benchmark (e.g. motorsport magazine comparison tests), test of driver assistance systems, and drivability. In many cases, the assessment of driving characteristics is subjective (e.g. on a scale from 1 to 10). A complete objective evaluation of driving maneuvers is not state-of- the-art and therefore a major challenge for the release process (Sundmark et al.
2011; Düser2010).
Another environment for release tests are hardware-in-the-loop-(HIL) tests.
Here, the developed system, for example a brake system control, is tested in a simulated vehicle environment. High repeatability of driving maneuvers and the opportunity for test automation are advantages of the simulation approach com- pared to real vehicle tests. Moreover, the simple availability of different environ- mental conditions and diverse vehicle parameters is advantageous (Borgeest2008).
Kvasnicka et al. (2006) and Mao et al. (2012) show examples for the application of HIL-simulation tools in brake system release processes. Furthermore, a CAE-based homologation approach for ESC systems is described by Holzmann et al. (2012). The quality of the HIL-tests depends significantly on the data (e.g. mathematical vehicle model, vehicle parameters), which was used to build the models. A high degree of detail usually requires a huge modeling effort (Langermann2008). Furthermore, not all evaluation aspects (e.g. driving comfort, drivability, and usability) can be objectively measured. Therefore, the use of HIL-tests in release processes is limited.
2.2.4 Sources of Change
Changes occur regularly in the course of a development project. They arise due to functional extensions, functional changes, cost reduction activities, or adaptations to new hardware (Gustavsson 2010). Eckert et al. (2004) distinguish between initiated changes and emergent changes. Initiated changes arise from an outside source. Many of these changes are known at the beginning of the development process, e.g. customer demands, legal requirements for products or processes, innovations (new materials, components, software), problems with past designs.
Some arise during a development project due to new customer requirements or recent innovations. Emergent changes are caused by the state of the design. They result from problems with the actual product. Problems arise during all stages of the development process and at all integration levels, e.g. in design, testing, prototyping, manufacturing, or use.
The later a change occurs in a development project, the more expensive is its implementation. There are two reasons for this. On the one hand, the processes become more time-critical because there is less time left for the handling of the change. Therefore, more resources are needed to deal with the change in time. On the other hand, the product is more integrated, so that the impact of the change is larger and more rework and retests are necessary (Eckert et al. 2004). Changes during the release process, which forms the last step before the product is produced and delivered to the customer, are therefore a fundamental challenge.
2.2.5 Automotive Change Management
The handling of changes is organized by change management processes. A change is therein treated as a small project within the overall vehicle development project (Borgeest2008). Gustavsson (2010) describes the change management process as a five step action. First, the change is identified through a demand analysis. Thereon, the impacts of the change are determined. In the next step, solution alternatives are
set up. Afterwards, the decision about the change is reached. Finally, the imple- mentation and validation of the change take place.
Automotive change management is defined in Automotive SPICE (2015). The specified process aims at ensuring that changes are controlled, tracked, and mon- itored. Therefore, a change management plan is established, which contains the change management strategy of the company. Here, change management activities including identification, documentation, analysis, and implementation of changes are defined. The central element of the change management process is the so-called change request (CR), which is used to handle a single change. It defines the purpose of the change, identifies its effects for existing systems, and contains the responsi- bilities as well as the status and the criticality of the change.
Requirements for handling changes in the automotive industry also arise from ISO 26262 (2011), which contains automotive functional safety standards. ISO 26262 (Part 8, Clause7, 2011) describes the required change management process.
It includes following steps: change request, change analysis, change decision, and change implementation and documentation. The central element is the analysis of the effects of the change on the functional safety of the system. According to the results of this analysis, the products of the safety lifecycle are adjusted and the affected work products are revised. Moreover, a revalidation of the concerned parts of the product is required. Also, the release process has to be reevaluated.
2.2.6 Summary and Conclusion
There are four major challenges of automotive release processes. The first challenge emerges from the high system complexity of the vehicle overall system, which results from the huge number of individual systems (hardware and software) and the intense connectivity between those systems. An entire testing of all combina- tions of input parameters of functions is not feasible with economically justifiable effort (N€orenberg2012, p. 26). Therefore, test case selection is an essential activity.
The second challenge is the vast test effort for automotive releases due to the high amount of vehicle variants and the fact that the major portion of tests is conducted in real vehicle environments. The expenditures for verification and validation activities form a huge amount of the overall development costs (Albers 2010). This includes costs for vehicles and components, test tracks, simulation environments, manpower etc. Hence, the reduction of release effort is highly recommended.
The third challenge is the short time for the release process. The approval cannot be carried out until the final hardware and software are available (Sundmark et al.
2011). Because of the short overall development cycle in the automotive industry, the time for test actions in the release process is limited to a few months. For that reason, a high efficiency of the release activities is required.
The forth challenge of automobile release processes are changes. According to statements from interviewees at Scania CV, changes cannot be completely avoided
(Sundmark et al.2011). They are especially critical if they occur late in the release process, when there is not much time left for their implementation and the retest of the system. Thus, the handling of changes in automotive release processes is a critical success factor. The identification of the effects of changes and the determi- nation of resulting retest effort is therefore an important research field.