Figure 2. Schematic representation of an adaptive cruise control (ACC) system that controls vehicle 2 to follow the leading vehicle 1 with equal velocity at a desired safe distance xd. Further defined are the position x, velocity v, and acceleration a of both vehicles, the relative velocity vr = v1−v2, the clearance xr = x1−x2 (neglecting the length of the vehicles), and the separation error ex = xd−xr, all in longitudinal direction.
methods are required for the design of ADAS controllers and the validation of their safety and performance.
The objective of this paper is to present a new method for the development of ADASs that complements the existing development process. This method consists of vehicle hardwarein-the-loop (VEHIL) simulations that allow to efficiently and accurately test full-scale ADAS-equipped vehicles in an indoor laboratory environment.
The remainder of this paper is organised as follows. The problem statement is further defined in section 2 by reviewing the development process of ADASs and state-of-the-art test methods. In section 3 we then present the working principle and added value of the VEHIL concept, and discuss the position of the VEHIL laboratory in the ADAS development process. This is demonstrated in section 4, where VEHIL test results for ACC and FCW are presented. Finally, section 5 presents the conclusions, and discusses ongoing research activities. Lists of frequently used symbols and abbreviations are also included at the end of this paper.
2 Tools in the design and validation process
In the automotive industry the different phases in the development process of safety-critical control systems are often connected using the ‘V’ diagram, depicted in figure 3 [20]. The ‘V’ diagram uses a ‘top-down’ approach to design and a ‘bottom-up’ approach to validation, although in practice the process does not strictly follow all phases in this sequence and goes through several iteration loops. The ‘V’ diagram is frequently applied to the development process of mechatronic vehicle systems [21]. However, the various development phases for ADASs face some specific challenges.
2.1 Challenges in the ADAS development process
The ADAS development starts with a definition of the functional requirements in terms of the desired functions, driver comfort, and operational constraints. In addition, ADASs are safety-critical systems that require a high level of dependability, a term covering reliability, (fail-)safety, and fault-tolerance. Hazard and risk analyses are therefore performed to identify the safety requirements, usually in terms of the rate of false alarms (when an ADAS takes unnecessary action) and missed detections (when it fails to correctly detect a dangerous situation). State-of-the-art systems achieve a false alarm rate in the order of 10−5 per
Figure 3. The ‘V’ diagram represents the sequential design and validation phases in the development of automotive safetycritical systems, including the use of various test tools in these phases.
km, but this is still considered too high [12]. From the functional and safety requirements a system specification is produced to define the precise operation of the system. However, in practice requirements are often difficult to define and subject to ambiguity, which may lead to an incomplete or incorrect specification.
Subsequently, the system specification is used as the basis for the top-level design of the system architecture, followed by detailed module design (environment sensor, controller, actuator, driver interface). After implementation of the individual hardware and software modules, system integration takes place by assembling the complete system from its component modules. In every integration phase verification takes place to determine whether the output of a phase meets its specification, as illustrated by the horizontal arrows in figure 3. On component level this means testing the range, accuracy, and tracking capabilities of the environment sensor [22]. On a higher level, verification must assure that integration with other subsystems does not have any negative side-effect.
Since verification only confirms compliance with the specification, errors in the specification may result in a faulty product. It is therefore important to perform validation of the integrated system against its requirements, especially for type approval and certification purposes. Usually, the development process involves several iterations, where the results of verification and validation are used to modify the system specification and design, after which another test cycle takes place. Obviously, there is a need to reduce the