A Holistic Approach to the Integration of Safety ... - Semantic Scholar

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS

1

A Holistic Approach to the Integration of Safety Applications: The INSAFES Subproject Within the European Framework Programme 6 Integrating Project PReVENT Angelos Amditis, Member, IEEE, Enrico Bertolazzi, Matthaios Bimpas, Member, IEEE, Francesco Biral, Paolo Bosetti, Mauro Da Lio, Lars Danielsson, Alessandro Gallione, Henrik Lind, Andrea Saroldi, and Agneta Sjögren

Abstract—This paper deals with the integration of multiple advanced driver-assistance systems (ADAS) and in-vehicle information systems (IVIS) in a holistic driver-support system. The paper presents the results of a project named Integrated Safety Systems (INSAFES), which was part of PReVENT: an integrating project carried out under the European Framework Programme 6. Integration in INSAFES is tackled at three different levels in the framework of a “cognitive car” perspective: 1) at the perception level, to represent the world around the vehicle, including object-tracking between sensor fields and the detection of driver intentions; 2) at the decision level, to reproduce humanlike holistic motion plans, which serve as “reference maneuvers” to evaluate the motion alternatives that a driver faces; and 3) at the level of interaction with the driver and vehicle control (action level), to arbitrate between the requests of functions competing for driver attention. A function that provides simultaneous longitudinal and lateral support has been developed. It gives support for safe speed, safe distance, lane change, and all-around collision avoidance all at the same time. At its core, there is a tool (evasive/reference maneuver) that constantly evaluates two possible alternatives (in lane and evasive/lane change) and compares them with the driver input to detect which one applies, which dictates warnings and driver interactions, and whether there is a better alternative. In addition, a “warning manager” has been developed, acting like a referee who lets the ADAS applications work standalone Manuscript received December 20, 2008; revised May 31, 2009 and October 14, 2009. This work was supported by the European Commission under Framework Programme 6 (FP6 507075). A. Amditis and M. Bimpas are with the Department of Electrical and Computer Engineering and the Institute of Communications and Computer Systems, National Technical University of Athens, 15773 Athens, Greece (e-mail: [email protected]; [email protected]). E. Bertolazzi, F. Biral, P. Bosetti, and M. Da Lio are with the Department of Mechanical and Structural Engineering, University of Trento, 38050 Trento, Italy (e-mail: [email protected]; [email protected]; [email protected]; [email protected]). L. Danielsson and H. Lind are with the Active Safety Electronics Department, Volvo Car Corporation, 405 31 Göteborg, Sweden (e-mail: [email protected]; [email protected]). A. Gallione was with the Centro Ricerche Fiat, 10043 Orbassano, Italy. He is now with the Fiat Group Automobiles, 10135 Torino, Italy (e-mail: [email protected]). A. Saroldi is with the Centro Ricerche Fiat, 10043 Orbassano, Italy (e-mail: [email protected]). A. Sjögren is with the Intelligent Vehicle Technologies Department, Volvo Technology Corporation, 405 08 Göteborg, Sweden (e-mail: agneta. [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TITS.2009.2036736

and then combines the requests of each application, prioritizes them, and manages the interaction with the user. The warning manager can be particularly useful in the case of integration of pre-existing standalone functions, which can be quickly reused. If a holistic ADAS is developed, the warning manager can still be used to combine it with IVIS functions. In fact, depending on the kind of ADAS and IVIS considered, the most suitable approach can be either to combine functions in a unified multifunctional driver-support application or to arbitrate between them through the warning manager. Index Terms—Advanced driver-assistance systems (ADAS), cognitive car, H-metaphor, human–machine interface (HMI), integrated road safety.

I. I NTRODUCTION

R

ESEARCH on intelligent vehicles has been carried out by a number of programs worldwide [1], [2] since the late 1980s. Some programs began with a focus on automation, for example, the PATH partnership in the United States which originally researched automation in restricted highway scenarios to respond to the increasing demand for transportation [3]–[5]. Full autonomous operation, however, remained, for the most part, a topic for unmanned vehicles [6]–[10] (with exception), whereas research goals shifted to “intelligent vehicles” and driver-assistance systems for a number of reasons that included liability issues, acceptance and feasibility in the midterm, and the desire to prevent driver mistakes. Full autonomous drive was left for the longer perspective. As an example, in Europe, the Prometheus project introduced areas of research such as enhanced driver information, active driver support, cooperative systems, and fleet management [11]. Similarly, in Japan, the Advanced Safety Vehicle (ASV) programs introduced a number of support functions, e.g., [12] and [13]. With intelligent vehicles, the driver is almost always in the loop, but the system manages to prevent driver errors, which are the major cause of accidents. Intelligent vehicles sense the environment and interact with the driver, providing recommendations or ultimately intervening. Unhappily, this way, driver support breaks down to a plethora of “functions,” as shown in the ASV examples above, with each function addressing a

1524-9050/$26.00 © 2009 IEEE Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on August 02,2010 at 11:12:16 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 2

IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS

specific issue or risk. The functions compete for driver attention and can be confusing. Information and comfort functions may also be active at the same time, adding to the confusing effect. Indeed, human factors soon become the bottleneck, as was recognized early [14] and more recently in the AIDE project [15]. In the United States, the Crash Avoidance Metrics Partnership (CAMP), within the project Driver Workload Metrics [16], [17], studied the workload that is induced by different invehicle systems and provided recommendations about methods to assess and predict the workload of future designs. Human factors for collision-avoidance systems are also studied in [18], which points out how, when dealing with multiple-source warnings, integration must occur at a much broader level than just the driver–vehicle interface. In the meantime, the role of the driver as the third pillar of safety (with the vehicle and the environment being the other two) was also recognized: The knowledge of the driver state and intentions can, in principle, be used to tailor the assistance to driver wishes [19], [20]. Ultimately, the need to transfer “cognitive processes” to the vehicle has been understood, opening a future in which a vehicle that reproduces human perception and decision-making processes can interact with the driver on a peer basis [21]. The metaphor of a rider and a horse may be used to envision such interactions [22]. It is important to notice that, to be effective, such a system needs to be able to perceive the environment “like a human,” but it also needs to be able to elaborate motion plans “like a human.” In other words, an effective driver support system should reproduce human perception and the human decision-making process [23], [24], the latter being less studied (as for what concerns intelligent vehicles). Attempts to reduce the number of functions by combining several together have also been carried out. For example, the combination of adaptive cruise control (ACC) and collision avoidance [25], or the use of the “potential field” method (from robotics) to achieve a unified approach to collision-free motion planning [26]. The use of human-driving styles to reproduce humanlike motion plans has also been used in ACC systems [27], [28]. Integration has also been addressed in the mentioned Japanese ASV projects (the latest) and in the Integrated Vehicle-Based Safety Systems project in the United States [29]–[31]. In this line, this paper describes the efforts to integrate advanced driver-assistance systems (ADAS) and in-vehicle information systems (IVIS) functions in PReVENT. A. PReVENT and INSAFES Within the European Framework Programme 6, the integrating project PReVENT [32], [33] was founded to develop intelligent vehicles that were focused on preventive and active road safety. A holistic approach was adopted by PReVENT to support drivers with respect to all major risks around the vehicle. As a result, a number of applications were developed and tested, each addressing a single type of an accident scenario: safe speed and distance [34], far foresighting [35], lateral support [36], lane keeping [37], intersection safety [38],

vulnerable road user protection [39], and collision mitigation [40]. In addition, there were subprojects that were focused on enabling technologies like enhanced maps [41], sensors [42] and sensor data fusion [43], legal aspects [44], and results evaluation [45]. Many public deliverables, including the final reports, can be downloaded from the listed Web sites. It soon became evident that the integration of the different support functions, to provide a virtual safety belt around the vehicle, was at least as important as the development of the single functions. The subproject Integrated Safety Systems (INSAFES) was started in the second phase of PReVENT to study the problems and the possibilities of the integration of ADAS and IVIS [46], [47]. INSAFES can be considered a further step in the roadmap for the vehicle of the future, where cars will eventually act like robots, with “cognitive” abilities [19], [21], [22], [48]. In fact, although many steps still remain to be taken toward the cognitive car vision, INSAFES adopts a clear three-layer structure—perception, decision, and action—which is inspired by human beings [23] or autonomous robots [6]–[9]. Eventually, the “perception” layer will be the place where a consistent and complete representation of the world will be produced, the “decision” layer, atop the perception layer, will host cognitive processes, and the “action” layer will be the place where interaction with the driver, vehicle control, and trading of authority will take place. INSAFES makes progress in all three. B. Challenges of Coexisting Safety and Informative Applications An imaginary vehicle of the near future, aiming to help the driver minimize the risk of a traffic accident, necessarily needs to deal with hazards of various types all around a vehicle. For example, it will need to provide support for both frontal and side collision avoidance, or it will have to support both the longitudinal and lateral controls of the car (e.g., safe speed and lane keeping simultaneously). At the same time, some information must also be given to the driver (e.g., related to navigation advice). A short example list of functions that a holistic support and information system might wish to integrate is given as follows: – frontal collision warning and mitigation; – lane departure warning and lateral collision warning; – blind spot alert, start inhibit; – lane-keeping/lane-change assistance; – curve warning—safe speed assistance; – information on legal speed limits; – information as to incoming hazards; – driving directions. Although most of the above systems are mature or close to mature technologies if considered as standalone applications, simply putting all of them together into one vehicle might be disadvantageous for two reasons: effectiveness and economy. Fig. 1 shows such an arrangement in which various applications are side by side with no integration at all. No one would use such an arrangement because it is evident that at least sensors and output devices must be shared. In

Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on August 02,2010 at 11:12:16 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. AMDITIS et al.: HOLISTIC APPROACH TO THE INTEGRATION OF SAFETY APPLICATIONS

3

resentation are important since no cognitive process thereafter can overcome missed or improperly perceived features in the world. B. Decision Layer

Fig. 1.

Putting ADAS and IVIS together without integration is inefficient.

Fig. 2. INSAFES architecture is based on three layers: unified perception, fused applications, and fused HMI.

addition, a synergy would be obtained if the representation of the world were common. This also ensures that all the systems act on the same view. However, economy is not the most important problem. The fact is that several independent systems might be difficult to use and be contradictory, or at least confusing. As shown in the AIDE project [49], the combination of just two of the above applications (a lane departure warning and a frontal collision warning system) was perceived as less useful than each of the systems alone [15]. Therefore, there definitely is a need for a unified human–machine interface (HMI), delivering the right information at the right time. II. S YSTEM A RCHITECTURE The architecture of Fig. 2 has been adopted by INSAFES to solve the problems noted above and to further enhance the integrated system. A. Unified Perception Layer A unified perception layer responds to the need for economy and robustness. It delivers an all-around model of the world using a set of sensors. The representation of the world is standardized, and every application uses the same view. Even if the holistic view may be redundant for some applications, it ensures that all applications use the same data; this provides robustness and reduces the likelihood of contradictory behavior of the applications. Of course, the reliability and the completeness of the world rep-

Atop the common perception is the “decision” layer. This is where various functions can be implemented. There are basically two means for this. 1) Reuse of applications from a corresponding and existing standalone ADAS. This means that the “decision” block, i.e., the core of the application, is the same (e.g., “Decision C” is the same in Figs. 1 and 2). Only the interface to perception and the HMI are different: Each application picks the elements that it needs from the much richer unified world representation in Fig. 2 and does not directly act on the output devices but rather issues a request for a warning or information to be delivered to the driver. The HMI manager will later decide how to harmonize the different application requests and effectively interact with the driver. The approach given in point 1 above is well suited to the reuse of existing software (and hardware). Nonetheless, the final system, apart from the integration in the HMI below, will essentially be the “sum” of the single standalone applications. In some cases, however, the fusion of two applications could produce a new integrated function, which not only provides the sum of the two original functions but also improves with respect to them. This might be the case, for example, of the combination of lateral and longitudinal support functions: A new function that provides holistic support for motion could adapt the longitudinal support to what happens in the nearby lanes and, for example, behaves differently if an escape maneuver exists or not. The new integrated longitudinal–lateral support function will no longer be the simple sum of its predecessor functions because synergic effects will be obtained. These considerations lead to the following second possibility. 2) Fusion of different functions into a common unified application. This is, for example, shown in Fig. 2, where the original applications A and B now are rewritten in a new common application. C. Action Layer The third layer is responsible for the harmonization of the requests received from the different applications. It controls the HMI and vehicle actuators. To provide a consistent interface between the HMI and vehicle control, a two-block structure is used: – the warning manager block, which controls the HMI; – the actuator manager block, which controls the vehicle actuators. Besides ADAS, the warning manager also interacts with the IVIS applications, informing them when a high priority warning (from an ADAS) has been issued so that the IVIS can replan their action. The ADAS warnings always have priority.




The warning manager may, in special cases, also combine two different types of warning that simultaneously occur into a new combined warning. Overall, the action layer (or the warning manager) responds to the following needs: – to interface with the driver in a consistent and efficient way; – to prioritize between different warnings and system actions; – to reduce driver workload in a complex traffic situation; – to build a flexible system, where new functionality can be added; – to improve the functionality for the user by combining applications. III. S YSTEM I MPLEMENTATION The results of the subprojects in the first phase of PReVENT [34]–[45] were first analyzed, and a number of functions were chosen for INSAFES and prioritized, for either cars or trucks, on the basis of their estimated impact, which was evaluated using accident analyses. A. All-Around Sensor Data Fusion The perception concept in INSAFES is inherited from the research work performed in ProFusion [43], [50] and is further developed to provide a global description of the world all around the vehicle. Many sensors are necessary for complete assessment of the vehicle status and of the surrounding traffic environment (e.g., see below the Centro Ricerche Fiat (CRF) demonstrator). They range from wheel speed sensors to radar, cameras, and laser scanners and even include communication systems such as vehicle-to-vehicle and vehicle-to-infrastructure communications. INSAFES inherits modules from PReVENT subprojects [34]–[37], [40], [41] and combines them to carry out further fusion tasks at a higher level (i.e., track-level fusion (TLF) and situation refinement below), ultimately producing a complete description of the world in terms of the following data structures: – the driver and driver actions; – the road (static and dynamic features); – the objects. 1) Object Refinement—TLF: INSAFES demonstrators use the TLF approach that has been developed within SP ProFusion2 [51]. The TLF is a distributed approach that assumes that the first level of tracking is carried out inside each individual sensor system and that the output (track arrays) feeds the TLF algorithm. It can be applied to automotive sensor networks with complementary and/or redundant fields of view. The advantage of this approach is to ensure system modularity and allow benchmarking; however, it does not allow feedback and loops within the processing. The track arrays input to the TLF algorithm can be either the output of a dedicated tracking system of a single sensor or the output of the processing of a sensor network, as will be shown below.

Fig. 3.

TLF architecture.

Fig. 3 shows the main parts of the TLF algorithm, which are the time and space alignment of track arrays, the division of fusion subproblems according to the area covered by each sensor or sensor system, the track-to-track association procedure that is solved with 2-D and S-D (with S ≥ 3) assignment, the fusion object update from the pairs or S-ples of tracks (group of S associated tracks), and the object management that is the final step before the objects pass to the output. The core of the TLF is the track-to-track association algorithm. This plays a key role to the performance of the TLF ensuring the continuity and maintenance of objects all around the sensor-covered areas and the solution of multisource objects assignment. Data-association research in the TLF concerns techniques to handle various sources of object information from the available sources, e.g., multipoint objects, of different quality, while generating association metrics and 2-D and multidimensional constrained optimization solution algorithms to solve the track-to-track assignment. In road environments and automotive applications, the sensors that are used are very heterogeneous. Thus, improved architecture for association of track arrays is used. The main approach with splitting to fusion subproblems (see Fig. 3) implies that the quality of input track arrays is of the same confidence. However, in practice, the equivalent quality of individual trackers is not always achieved. The approach of Fig. 4 is, therefore, used for track-to-track association in the TLF approach. A similar approach to this is the sequential pairwise track-to-track association referred to in [52]. In this scheme, the most accurate sensor is defined, and according to its estimates, the track arrays of other sensors are combined with them. The combination with other sensors could take place in their common areas in complementary sensor topologies, ensuring the continuity of tracked objects. 2) Situation Refinement: The situation analysis task consists of two main components: The first is to develop the appropriate level of domain-specific knowledge for the road elements (e.g., road borders, lanes, obstacles), and the second is to develop a decision-making process that is able to codify and manipulate the knowledge mentioned above. In situation refinement, the system not only is aware of the states of the road elements but also has knowledge of their relationships. The outcome of situation refinement enriches the environment model, including additional attributes of the ego-vehicle



5

Fig. 5. Workflow of the maneuver classification algorithm (Bel stands for the belief value of the D–S theory).

approach for situation refinement, the following host maneuvers are classified: – lane change (LC); – overtake (OV); – free flow (FF); – cut in (CI); – merging (ME); – following vehicle in path (FP); – following vehicle in next lane (FN). The space of discernment is given as ΩM = {LC, OV, FF, CI, ME, FP, FN, UN} Fig. 4.

Sequential and pairwise track-to-track association in the TLF.

and the obstacles (predicted paths, object-to-lane assignment, evidence for vehicle maneuvers, etc.). Situation awareness is necessary to assess the risk of present and predicted future situations. It depends on the trust that other agents will act in a predictable way, and of course, it can be uncertain due to incompleteness of knowledge and uncertain information sources. The situation refinement work contains a set of Dempster–Shafer (D–S) theory-based reasoning systems for the following. 1) Maneuver-type identification: identify from a set of predefined input parameters the type of maneuver that the host vehicle is likely to follow together with a confidence measure. An example of output is lane change (LC) or overtaking (OV); 2) Driver intention: a D–S reasoning system that calculates a level of intention for the performed maneuver accompanied by a confidence value; 3) Lane assignment: for fused objects that assign to every fused object a lane ID and a confidence value showing in which lane it is placed. The algorithms also include the extraction of the predicted future paths of the ego-vehicle and the tracked vehicles. D–S approach for situation refinement: D–S evidential theory is a probability-based data-fusion-classification algorithm, which is useful when the information sources are unable to provide ultimate certainty in their decisions. Using the D–S

(1)

with {UN} as the unknown maneuver. The following information sources are utilized in the reasoning module: – time to lane crossing with constant lateral velocity; – time to lane crossing with constant lateral acceleration; – predicted minimum distance (PMD); – time to PMD; – curvature ratio (the ratio of the lane curvature to the vehicle path curvature); – distance from the vehicle in path; – distance from the vehicle in the adjacent lane. A basic probability assignment (BPA) function is defined for each information source, which returns the probability (mass) of the maneuver for a given value of the source. The BPA functions were adjusted by means of offline testing with real data. Every time scan, the mass evidence, belief, and plausibility for all the information sources are calculated (see Fig. 5). Then, they are combined recursively. The combination (called the joint m12 ) is calculated from the aggregation of two BPA m1 and m2 in the following way: m1 (B)m2 (C) (2) m12 (A) = B∩C=A 1−K where K=

m1 (B)m2 (C).

(3)

B∩C=Φ




Fig. 7. INSAFES explores different strategies (RM1, RM2, etc.) and compares them with driver behavior (warning and intervention strategies block).

Fig. 6. Scenario. The integrated application must provide support for alternative strategies (the field of view of the sensors is shown).

K represents the basic probability mass that is associated with conflict, which is determined by summing the products of the BPA of all sets where the intersection is null. Finally, a vector of evidence masses and beliefs of all host maneuvers is produced. The maneuver of the greatest mass will be identified as the classification result. B. Fusion of Applications In the early prioritization activity, an application that provides the integration of longitudinal and lateral support was identified as the most promising example of integration at the decision level. The typical scenario for such an application is shown in Fig. 6: The ego-vehicle travels on a multilane road, with traffic and danger points. As in the Safe Speed and Safe Distance (SASPENCE) project [53], the system evaluates humanlike optimal maneuvers [54] starting from the current vehicle state. The difference with SASPENCE is, however, substantial: In SASPENCE, there were two possible strategies for planning, which were used alternatively [53]. The selected strategy (i.e., in-lane versus lane change) followed the detection of an imminent line crossing. SASPENCE, therefore, gives support for the hazards in front of the vehicle on the basis of the maneuver that the driver is executing. It does not evaluate if alternative maneuvers (which the driver is not executing) might be better, nor does it adapt its messages according to the existence or otherwise of better options. Conversely, INSAFES provides, in principle, simultaneous evaluation of many alternatives, as shown in Fig. 7. For example, in Fig. 6, INSAFES evaluates both maneuvers, regardless of which the driver appears to be executing. INSAFES uses all-around sensor data fusion, which lets the system know about the presence of rear vehicles in the nearby lane (as in Figs. 6 and 8) and, therefore, provides integrated support for either traveling in current lane or changing to a nearby lane. It, thus, gives integrated support for 1) collisions, either

Fig. 8.

Evaluation of two alternative maneuvers.

in front or sides; 2) curves, including the increased risk of lanechange maneuvering; 3) hot spots and other hazards, which may be lane dependent; and 4) lane-keeping (not implemented in the CRF car) or lane-change assistance. A dual core processor simultaneously computes two maneuvers at every planning loop, i.e., every ∼100 ms. One maneuver fits the predicted lane (as assessed in the situation refinement). The other maneuver is used to explore a possible alternative (e.g., change lane to the left versus change lane to the right). The alternative maneuver is also called an “evasive” maneuver because it might represent an escape path. The system continuously monitors the feasibility of one evasive maneuver every planning loop. Depending on the number of lanes of the road and which lane is used, the evasive maneuver may be either to the left or to the right. If both are possible, the system cyclically evaluates one evasive maneuver to the left and one to the right. During the lane change, the evasive maneuver becomes the one in the lane (should it be better to return to the original lane). Although the system evaluates two possible maneuvers, it knows which one is going to be used. The computation of a maneuver that the driver is not going to use might, therefore, appear useless, but it is not. In fact, should the system need to warn the driver of a mistake in the current maneuver, the warning might be modulated, depending on whether an evasive maneuver exists and its risk compared with the current. Indeed, the system has, at every moment, enough information to know which is the better maneuver and might, in principle, even suggest it. Below, we show some examples of the kind of information that can be obtained by the simultaneous evaluation of two maneuvers. The question of how to use this information to



Fig. 9. Comparison of car (left) following and (right) overtake alternatives in case the nearby lane is free. (Above) System plans. (Below) Risk levels.

design an HMI for effective maneuver suggestion or, to better achieve an intelligent cooperation [19], [22], involves, however, complex human–machine interactions that were not fully developed in the project and that, therefore, need further study. This point is still open, and some considerations are given in the conclusions. Fig. 8 shows a situation with two alternatives: in lane and lane change. The situation, which is inspired by a real case, was batch-analyzed twice. In one case, a rear obstacle in the nearby lane was artificially added very close to ego-vehicle (marked with “B,” as shown in Fig. 8) to artificially create a very critical and dangerous situation. In the original case, the overtaking vehicle was not present (not so close). The vehicle in front “A” is slower than ego, so that, in principle, the driver can choose whether to brake and follow the vehicle ahead or to overtake, the latter alternative being completely different in the level of risk if an overtaking vehicle ”B” is present or not. Let us first examine the system behavior in the original situation, with no overtaking vehicle “B.” Fig. 9 compares the two alternatives. The in-lane maneuver is shown on the left: Shown above are the speed plans as the ego-vehicle approaches the slower front vehicle “A.” The picture shows a family of plans that start from current speed and acceleration and becomes steeper and steeper as the time flows, and the ego-vehicle is closer and closer to the front obstacle. At about 9–10 s, hard braking is definitely necessary to avoid the collision. On the bottom left of Fig. 9, the “risk index” (a combination of lateral and longitudinal jerk, as in SASPENCE [53]) is plotted. Starting from time ∼2 s, the risk index first grows and then explodes at ∼10 s, in conjunction with the need to brake hard. Let us now see what happens for the evasive maneuver (see the right side of Fig. 9). The plans, which are shown on the top right of Fig. 9, show that speed may increase (while

7

Fig. 10. Evasive maneuver in case the nearby lane is not free.

the vehicle simultaneously moves to the nearby lane, which is not shown). However, these plans remain only theoretical options because the car proceeds in its lane. At time ∼11 s, the car is so close to the front vehicle in its lane that it can no longer accelerate before moving to the near lane. The reference maneuver becomes a lane change with delayed acceleration. Later, when the front car is closer, the maneuver becomes a hard brake, in its lane, followed by a lane change (not shown). In these latter cases, the risk index for the alternative maneuver suddenly jumps to a very high value. In a certain sense, the system was able to detect the ultimate time at which the evasive maneuver is feasible. If we now compare the in-lane and evasive maneuvers, we see that, at the beginning (time 0–2 s), both maneuvers have a low-risk level. No warning at all is necessary, and the system can let the driver do what he/she prefers. At time 5–9 s, the inlane maneuver would require some kind of warning, whereas the alternative maneuver is feasible. At this point, the system should “suggest” the lane change or to brake. Let us now examine what happens if there is a close vehicle “B” in the destination lane (see Figs. 10 and 11). The plans for the in-lane maneuver, of course, do not change. The plans for the lane change, however, change radically, depending also on how close vehicle “B” is. If it is far enough, the situation is similar to Fig. 9, except that when the gap to “A” is short, it is no longer possible to slow down and then change lanes because there is vehicle “B” approaching. The most interesting thing, however, happens if vehicle “B” is close enough that it is not possible to pass in the nearby lane in front of it. In this case, the evasive maneuver computes a different acceleration profile (see the top right of Fig. 10) to let vehicle “B” pass, as better shown in Fig. 11. So far, we have seen the kind of information that can be obtained by the simultaneous evaluation of two alternative strategies. The use of this information and the design of a proper human–machine interface are, however, still an open issue.




A number of use cases were defined based on application and system requirements, as well as general HMI guidelines. The following requirements were identified from the use cases setting the requirements for the warning manager, as well as the structure for the integration of the warning manager in the overall structure of INSAFES. Following are the prioritization and integration requirements.

Fig. 11. Bird’s-eye view of an evasive maneuver where the nearby lane is not free.

The system, at any time, knows if and which of the two maneuvers matches driver commands. If one of the two matches the driver actions, the system might give a warning that is related to the risk level of the maneuver that the driver is executing. Note that this is essentially what happens in SASPENCE [53], where the system evaluates only the current maneuver. However, how could we deal with the fact that the evasive maneuver may exist or not? If the risk level of the evasive maneuver says that it is worse, then a warning must be given in relation to the risk of the current maneuver and must be reinforced should the driver attempt the worse alternative maneuver. However, if the driver is going to be in trouble with the current maneuver and the evasive maneuver is better, a proper effective HMI could be exploited to suggest the alternative. C. Warning Manager In the project, the warning manager was developed completely, whereas the ancillary actuator manager was defined in the general principles. For the prioritization of warnings, each application specifies a category for each warning among three levels as follows. 1) Information (low priority). This category provides the driver with information about a measurable entity, e.g., “blind spot information” informs the driver that there is a vehicle in the blind spot, and “distance information” informs the driver that the leading vehicle is within a certain (time) distance. 2) Alert or cautionary alert (medium priority). The alert category provides the driver with information about low risk, e.g., “distance alert” alerts the driver that the headway to the leading vehicle is below a threshold, or “driver alert” alerts the driver that he/she is entering a lower state of alertness. 3) Warning (highest priority). The warning category provides information of the highest priority to the driver. An active safety warning is a warning that requires immediate intervention by the driver to avoid a possible accident.

• When two functions want to use the same modality (visual, acoustic, or haptic) at the same time, the highest priority warning shall be prioritized. • Warnings shall not be stored or delayed. • Warnings of several modalities shall be prioritized per modality. • When a warning has been issued, all lower or same priority warnings shall be suppressed for that device during a defined time period (a few seconds). • It shall be possible to combine two low-priority warnings to provide a higher or same priority warning. • A warning device that can be triggered from both the ADAS warning manager, and other units (such as IVIS applications) shall incorporate an internal prioritization on output, allowing direct activation of warnings. • Other sound sources shall be muted or attenuated while an audible warning is issued. • The vehicle HMI manager shall be informed of the warning provided to the driver and stop and delay IVIS type of information during a specified time (a few seconds). After the delay, the IVIS message shall be repeated with updated information. • The latency from activation of a warning state to activation of the HMI device shall be less than 100 ms. • Warnings of different modality triggered by the same warning state shall be started within a 100-ms period with 85% confidence. 1) Warning Manager Structure: The basic concept for management of in-vehicle HMI devices proposed by the AIDE consortium [49] relies on the Interaction and Communication Assistance (ICA) module discussed in [55]. The general objective of the ICA is to manage all the interactions of the driver with the in-vehicle systems via an accept/inhibit scheme. The principle is that all in-vehicle systems (applications) ask the ICA for the use of a certain HMI channel. The ICA determines whether to accept the request or to inhibit the system from using the HMI channel and communicates this decision back to the application. If the application receives an affirmative response, the access to the HMI device is granted. In a distributed vehicle environment where the ICA and the warning manager reside in different electronic control units, the signaling process could take up to 300 ms. The above scheme was modified in the INSAFES project [56] according to Fig. 12. Due to the time-critical nature of ADAS warnings, a warning manager was integrated in parallel to the ICA (see Fig. 12). The warning manager has prioritized access to a requested HMI device by incorporation of an HMI device prioritization block. If there is an ongoing message by the IVIS applications when the warning manager takes control, the IVIS message will



9

Fig. 12. Warning manager incorporating HMI device prioritization.

be aborted. The ICA is, at the same time, informed that the warning manager has taken control of the HMI device and for how long. It is the IVIS and ICA responsibility to provide a repetition of an aborted message when the warning manager releases the control back to the IVIS applications. IV. P ROTOTYPES Three different prototypes were prepared. They cluster the original PReVENT functions in different ways. Thus, they give birth to different integrated functions with different focus. – –

–

Demonstrator 1 integrates lateral support functions. Demonstrator 2 integrates longitudinal support functions and all-around collision warning and implements the cognitive layer (see Section III-B) for maneuver suggestion. Demonstrator 3 focuses on integrated HMI (warning manager) for ADAS.

A. Demonstrator D60.1 Demonstrator D60.1 is a Volvo FH12 truck that inherits functions from subprojects [36], [37], [40], and [41] and implements the following: – – – –

an integrated adaptive lateral support function, which combines lane-keeping support and lane-change aid; forward–lateral monitoring; start–inhibit; curve speed warning.

These functions use a unified perception layer based on radar sensors that cover the area on both sides of the vehicle and in front of it. Additional support on the front area is given by a stereo camera system. Furthermore, a lane-tracker camera, ADAS maps, and GPS are used for additional information. The implementation includes the integration of functionality in the decision layer, which is exemplified by the integrated lateral support function, which provides different levels of warning and active steering intervention, depending on in-lane position and on the presence of adjacent vehicles. Also, the warning manager principles are included to ensure that many functions are correctly prioritized.

Fig. 13. Volvo car placement of HMI devices.

B. Demonstrator 60.2 Demonstrator 60.2 is a Fiat Nuova Croma car. This demonstrator combines function from subprojects [34]–[36], [40], and [41], producing three groups of integrated functions: – – –

integrated longitudinal support, from early warnings to precrash functions; all-around collision warning; maneuver suggestion.

A unified perception layer is obtained using a large number of sensors, which cover all the directions, namely, 9 radar (three lateral short-range radar per side, one long-range radar on the front, and two rear long-range radar), GPS and differential GPS, enhanced digital maps, front camera with lane recognition, and two blind-spot cameras. An integrated decision level was obtained following the method described in Section III-B, namely, the simultaneous computation of a reference and evasive maneuvers and the comparison of the relevant risk indexes. However, concerning the maneuver suggestion, during development of the project, it was decided not to directly show to the driver the results of the comparison of the two maneuvers, which remained in an internal processing block (see the Conclusion). C. Demonstrator 60.3 Demonstrator 60.3 is a Volvo S80 car, implementing several ADAS applications with special emphasis on HMI coordination. The demonstrator includes two alternative ways of presenting warnings and information—a distributed HMI versus a centralized HMI display. The distributed HMI devices are positioned according to Fig. 13. The general HMI was presented on the navigation screen (4), which operates as a popup window on a monitor and, in default mode, will present infotainment. The warning manager provides two levels of driver interaction. – –

Information: The driver will be informed of the presence of vehicles in the areas near the ego-vehicle. Warning: There is an imminent risk of a collision with an object in any direction.




TABLE I INSAFES T EST G ENERAL OVERVIEW

The following functions and the respective HMI devices were integrated in the demonstrator (see Fig. 13): 1) lane-change merge assist—informing the driver of an approaching object from the rear in the parallel lane; 2) blind-spot information—informing the driver of an object in the blind spot; 3) side-collision warning—flashing with sound if the blinker is activated; 4) collision warning head-up display—informing the driver of an immediate danger ahead; informing the driver of low following distance (short headway); 5) general warning display—providing a bird’s-eye view of the vehicle and surrounding traffic. Warnings are also integrated in this display; 6) rear warning and information display providing information of low following distance and rear-collision warning. 1) Validation: Table I gives an overview of the validation activities. The experiments were coordinated with the evaluation phases of the other PReVENT subprojects and with the AIDE Integrating Project. INSAFES tests were, thus, focused on specific aspects related to integration not covered by the other projects. Tests that are carried out on the single functions of the contributing PReVENT subprojects were often used as benchmarks for the integrated functions (typically when the integrated functions, in certain simplified conditions, had to coincide with the single inherited function). For example, the adaptive lane-keeping support function (see the first row of Table I) had to reduce to the original lane-keeping function of LATERAL SAFE [36] in case there were no vehicles present in the nearby lanes. The evaluation methods have been adopted from the PReVAL subproject [45], which released guidelines for the assessment of preventive and active safety functions [58] based on experience in a number of previous projects. INSAFES was indeed the first PReVENT subproject to extensively implement the testing guidelines of PReVAL.

Table I lists the integrated functions per test group. For each test group, a number of different scenarios were considered for both technical evaluation and human factor evaluation. For example, the integrated longitudinal support (see function 7, Table I, CRF car) broke down into five scenarios for technical evaluation: approach to front slower obstacle, approach to curve, approach to a landmark present on maps, approach to landmarks that are generated by WILLWARN, and approach to stationary obstacle (collision mitigation). In particular, the last two test the SASPENCE–WILLWARN and the SASPENCE–APALACI integration. Table I also gives the conductor, the test site, and the test vehicle. Technical validation was carried out with the assistance of one driver in the defined scenarios to measure the missed-alarm rate (MAR), the correct-alarm rate (CAR), and the false-alarm rate (FAR), as well as other indicators, which are applicable in each case, to depict the function performance. The ultimate goal of technical validation was to assess to which level requirements and specifications were met. Examples of indicators that were measured (besides the alarm rates) are the timely activation of alarms and function-specific indicators, e.g., the longitudinal deceleration for the integrated longitudinal support function or the correct force feedback at the steering wheel for the adaptive lane-keeping support function. Results generally met the specifications, with exceptions particularly in borderline conditions: For example, in bad weather, the sensorial system of the VTEC vehicle could lose target vehicles, resulting in malfunctions of the first, second, and fifth functions in Table I. Typical values for FARs had to be better than 2% (specification) and were generally met (on some occasions, no false alarm at all was observed within the duration of the tests). Again, there were exceptions in borderline conditions: For example, the adaptive lane-keeping support function was misled by vehicles in the third lane (if any) leading to FARs up to 40% in this specific case. The CAR was typically set to be better than 98% and was met (often 100%). The MAR had to be typically less than 2% (often it was 0%).



Human factor evaluation was carried out with 19 test drivers for the functions that are tested by VTEC and 12 for VCC (see Table I). No human factor tests were carried out with the CRF vehicle, one reason being that the maneuver suggestion function and the underlying cognitive layer would call for a novel type of human–robot interaction that could not be afforded by INSAFES (see the Conclusion). One focus of human factor tests was to evaluate both intended effects and unintended (side) effects, according to the methodology of PReVAL. As an example, an intended effect for the adaptive lane-keeping support function was listed as “Efficient maintenance (and potential increase) of safety margins to road edges and road users,” and an unintended effect was listed as “increased speed.” Human factors have been studied by means of questionnaires to assess user acceptance and workload. In addition, driver performance data were collected, and the test supervisor had to complete the checklist from the Code of Practice of the RESPONSE 3 project [44]. Results were, in general, positive. For the warning manager, the results from on-road tests showed that the warnings were informative and intuitive and given at the right time. However, the warning manager proved to be difficult to test on the road due to the problem of producing on the road multiple and synchronized critical events. The centralized warning display was regarded as a valuable tool for planning the drive and understanding of the INSAFES system. However, the distributed warning-display solution was the preferred warning HMI. V. C ONCLUSION INSAFES is among the first projects to focus on integrated safety. The problem has been tackled at three different levels (perception–decision–action) in the framework of cognitive architecture. At the perception level, integration means a global vision of the world all around the vehicle and the detection of driver intentions. For all-around awareness, object tracking through different sensor areas has been implemented in the project. At the decision level, integration means applications that address vehicle motion in a holistic way, computing ideal humanlike behavior in the given scenario. In other words, the system must produce a picture of all the possible strategies in a given scenario and of their related risks. Then, it can evaluate what the driver is doing and why, and it can also assess whether there are better options. Therefore, in principle, the system knows the alternatives and can better evaluate what the driver is actually doing. At the interaction level, integration means the management of messages to the driver, i.e., to deliver the right message at the right time. A warning manager has been developed for this purpose. It can be further developed in more complex designs, e.g., following the paradigms of adaptive automation [48]. Work at the three levels has gone beyond what could be put in the three demonstrators. The project marks an advancement of driver-support systems toward collaborative systems; however, significant work still needs to be done. In this respect, the

11

Highly Automated Vehicles for Intelligent Transport (HAVEit) project [57] should be mentioned. The future development is the design of effective interaction paradigms, such as the H-metaphor [22], that allow a robotic car to collaborate with the driver on a peer-to-peer basis, like the horse and the rider in the H-metaphor. ACKNOWLEDGMENT The authors would like to thank the partners who participated in the INSAFES project: M. Junker (Irion Management, Germany); E. Bekiaris, L. Gaitanidou, and M. Gemou (Center for Research and Technology Hellas/Hellenic Institute of Transport, Greece); S. Bergqvist, A. Beutner, M. Rilbe, and T. Victor (Volvo Technology, Sweden); U. Beutnagel-Buchner, J. Hötzel, U. Kaiser-Dieckhoff, and T. Sohnke (Robert Bosch GmbH, Germany); C. Contopoulos, N. Floudas, and M. Tsogas, (Institute of Communications and Computer Systems, National Technical University of Athens, Greece); X. Dai, L. Gosh, and S.-B. Park (Delphi Electronics & Safety, Germany); M. Miglietta, T. Santhià, and R. Bera, (Centro Ricerche Fiat, Italy); G. Noecker, A. Hiller, and W. Kronjaeger (DaimlerChrysler AG, Germany); S. Jonasson (Volvo Cars, Sweden); and S. Mammar and L. Nouveliere (Centre National de la Recherche Scientifique/Délégation Ile de France Est, Université d’Evry, France). R EFERENCES [1] R. Bishop, “Intelligent vehicle R&D: ‘A review and contrast of programs worldwide and emerging trends’,” Ann. Telecommun., vol. 60, no. 3/4, pp. 228–263, 2005. [2] J. Piao and M. McDonald, “Advanced driver assistance systems from autonomous to cooperative approach,” Trans. Rev., vol. 28, no. 5, pp. 659– 684, Sep. 2008. [3] S. E. Shladover, “PATH at 20—History and major milestones,” IEEE Trans. Intell. Transp. Syst., vol. 8, no. 4, pp. 584–592, Dec. 2007. [4] S. E. Shladover, C. A. Desoer, J. K. Hedrick, M. Tomizuka, J. Walrand, W-B. Zhang, D. H. McMahon, H. Peng, S. Sheikholeslam, and N. McKeown, “Automatic vehicle control developments in the PATH program,” IEEE Trans. Veh. Technol., vol. 40, no. 1, pp. 114–129, Feb. 1991. [5] S. E. Shladover, “Automated vehicles for highway operations (automated highway systems),” Proc. Inst. Mech. Eng. Part I: J. Syst. Control Eng., vol. 219, no. 11, pp. 53–75, 2005. [6] M. Montemerlo, J. Becker, S. Bhat, H. Dahlkamp, D. Dolgov, S. Ettinger, and D. Haehnel, “Junior: The Stanford entry in the urban challenge,” J. Field Robot., vol. 25, no. 9, pp. 569–597, Sep. 2008. [7] D. Braid, A. Broggi, and G. Schmiedel, “The TerraMax autonomous vehicle,” J. Field Robot., vol. 23, no. 9, pp. 693–708, Sep. 2006. [8] V. Graefe and K.-D. Kuhnert, “Vision-based autonomous road vehicles,” in Vision-Based Vehicle Guidance, I. Masaki, Ed. New York: SpringerVerlag, 1991, pp. 1–29. [9] C. E. Thorpe, Ed., Vision and Navigation: The Carnegie Mellon Navlab. New York: Springer-Verlag, 1990. [10] M. Bertozzi, A. Broggi, and A. Fascioli, “VisLab and the evolution of vision-based UGVs,” Computer, vol. 39, no. 12, pp. 31–38, Dec. 2006, DOI 10.1109/MC.2006.448. [11] J. Hellaker, “PROMETHEUS: Strategy,” in Proc. Veh. Electron.: Int. Congr. Transp. Electron. (Convergence), Dearborn, MI, Oct. 1990, pp. 195–199. [12] T. Mimuro, Y. Miichi, T. Maemura, and K. Hayafune, “Functions and devices of Mitsubishi active safety ASV,” in Proc. IEEE Intell. Vehicle Symp., Tokyo, Japan, 1996, pp. 248–253. [13] [Online]. Available: http://world.honda.com/HDTV/ASV/ASV-3-auto/ index.html [14] M. G. Flyte, “The safe design of in-vehicle information and support systems: The human factor issues,” Int. J. Vehicle Des., vol. 16, no. 2/3, pp. 158–169, 1995.



[15] R. F. T. Brouwer and D. M. Hoedemaeker, “Driver support and information systems: Experiments on learning, appropriation and effects of adaptiveness,” AIDE Project Deliverable D1.2.3 (public). [Online]. Available: http://www.aide-eu.org/pdf/sp1_deliv_new/aide_d1_2_3.pdf [16] L. Angell, J. Auflick, P. A. Austria, D. Kochhar, L. Tijerina, W. Biever, T. Diptiman, J. Hogsett, and S. Kiger, (CAMP) driver workload metrics project: Final Rep., Nat. Highway Traffic Safety Admin., Washington, DC, Nov. 2006, section vehicle safety research, crash avoidance publications, DOT HS 810 635. [Online]. Available: http://www.nhtsa.dot.gov [17] L. Angell, J. Auflick, P.A. Austria, D. Kochhar, L. Tijerina, W. Biever, T. Diptiman, J. Hogsett, and S. Kiger, (CAMP) driver workload metrics project: Final report—Appendices, Nat. Highway Traffic Safety Admin., Washington, DC, Nov. 2006, section vehicle safety research, crash avoidance publications, DOT HS 810 635. [Online]. Available: http://www.nhtsa.dot.gov [18] J. L. Campbell, C. M. Richard, J. L. Brown, and M. McCallum, Crash warning system interfaces: Human factors insights and lessons learned, section vehicle safety research, DOT HS 810 697, 2007. [Online]. Available: http://www.nhtsa.dot.gov [19] T. Inagaki, “Smart collaboration between humans and machines based on mutual understanding,” Annu. Rev. Control, vol. 32, no. 2, pp. 253–261, Dec. 2008. [20] T. Kumagai and M. Akamatsu, “Prediction of human driving behavior using dynamic Bayesian networks,” IEICE Trans. Inf. Syst., vol. E89-D, no. 2, pp. 857–860, Feb. 2006. [21] A. Heide and K. Henning, “The ‘cognitive car’: A roadmap for research issues in the automotive sector,” Annu. Rev. Control, vol. 30, no. 2, pp. 197–203, 2006. [22] F. Flemisch, C. Adams, S. Conway, K. H. Goodrich, M. T. Palmer, and P. C. Schutte, “The H-metaphor as a guideline for vehicle automation and interaction,” NASA Langley Res. Center, Hampton, VA, Dec. 2003. [23] R. Kozma, H. Aghazarian, T. Huntsberger, E. Tunstel, and W. J. Freeman, “Computational aspects of cognition and consciousness in intelligent devices,” IEEE Comput. Intell. Mag., vol. 2, no. 3, pp. 53–64, Aug. 2007. [24] [Online]. Available: https://www.diplecs.eu/ [25] A. Vahidi and A. Eskandarian, “Research advances in intelligent collision avoidance and adaptive cruise control,” IEEE Trans. Intell. Transp. Syst., vol. 4, no. 3, pp. 143–153, Sep. 2003. [26] J. C. Jerdes and E. J. Rossetter, “A unified approach to driver assistance systems based on artificial potential fields,” J. Dyn. Syst. Meas. Control, vol. 123, no. 3, pp. 431–438, Sep. 2001. [27] S. Moon and K. Yi, “Human driving data-based design of a vehicle adaptive cruise control algorithm,” Veh. Syst. Dyn., vol. 46, no. 8, pp. 661– 690, Aug. 2008. [28] S. Moon, I. Moon, and K. Yi, “Design, tuning, and evaluation of a fullrange adaptive cruise control system with collision avoidance,” Control Eng. Pract., vol. 17, no. 4, pp. 442–455, Apr. 2009. [29] J. Ference, “The Integrated Vehicle-Based Safety Systems (IVBSS) initiative,” in Proc. ITS World Congr., London, U.K., Oct. 2006. [30] R. Harrington, A. Lam, E. Nodine, J. Ference, and W. G. Najm, Integrated Vehicle-Based Safety Systems (IVBSS)—Heavy truck on-road, Test Report, (section vehicle safety research, crash avoidance publications), Nat. Highway Traffic Safety Admin., Washington, DC, DOT HS 811 021, Aug. 2008. [Online]. Available: http://www.nhtsa.dot.gov [31] R. Harrington, A. Lam, E. Nodine, J. Ference, and W. G. Najm, Integrated Vehicle-Based Safety Systems (IVBSS)—Light vehicle on-road, Test Report, (section vehicle safety research, crash avoidance publications), Nat. Highway Traffic Safety Admin., Washington, DC, DOT HS 811 020, Aug. 2008. [Online]. Available: http://www.nhtsa.dot.gov [32] [Online]. Available: http://www.prevent-ip.org/ [33] M. Schulze, T. Mäkinen, J. Irion, M. Flament, and T. Kessel, Preventive and active safety applications integrated project, Final report, IP Deliverable 15 (public). [Online]. Available: http://www. prevent-ip.org/download/deliverables/IP_Level/PR-04000-IPD-080222v15_PReVENT_Final_Report_Amendments%206%20May%202008.pdf [34] [Online]. Available: http://www.prevent-ip.org/saspence [35] [Online]. Available: http://www.prevent-ip.org/willwarn [36] [Online]. Available: http://www.prevent-ip.org/lateralsafe [37] [Online]. Available: http://www.prevent-ip.org/safelane [38] [Online]. Avalable: http://www.prevent-ip.org/intersafe [39] [Online]. Available: http://www.prevent-ip.org/compose [40] [Online]. Available: http://www.prevent-ip.org/apalaci [41] [Online]. Available: http://www.prevent-ip.org/en/prevent_subprojects/ horizontal_activities/maps__adas/ [42] [Online]. Available: http://www.prevent-ip.org/en/prevent_subprojects/ vulnerable_road_users_collision_mitigation/usercams/ [43] [Online]. Available: http://www.prevent-ip.org/profusion


[44] [45] [46] [47]

[48] [49] [50]

[51]

[52] [53]

[54] [55]

[56] [57] [58]

[Online]. Available: http://www.prevent-ip.org/response3 [Online]. Available: http://www.prevent-ip.org/preval [Online]. Available: http://www.prevent-ip.org/insafes A. Sjögren, A. Amditis, and G. Noecker, INSAFES final report, sub project deliverable D60.10 (public). [Online]. Available: http://www.preventip.org/download/deliverables/INSAFES/PR-60100-SPD-071231-v10_ D60.10_Final_Report.pdf D. A. Norman, The Design of Future Things. New York: Basic Books, Nov. 2007. [Online]. Available: http://www.aide-eu.org/ S.-B. Park, N. Appenrodt, M. Ahrholdt, F. Tango, A. Amditis, P. Lytrivis, E. Fuchs, T. Tatschke, O. Aycard, T. D. Vu, J. Burlet, P. Lindner, E. Richter, and U. Scheunert, “ProFusion2—Sensor data fusion for active safety applications,” IEEE Trans. Intell. Transp. Syst., to be published. N. Floudas, A. Polychronopoulos, O. Aycard, J. Burlet, and M. Ahrholdt, “High level sensor data fusion approaches for object recognition in road environment,” in Proc. IEEE Intell. Vehicle Symp., Istanbul, Turkey, Jun. 13–15, 2007, pp. 136–141. S. S. Blackman and R. Popoli, Design and Analysis of Modern Tracking Systems. Norwood, MA: Artech House, 1999. E. Bertolazzi, F. Biral, M. Da Lio, A. Saroldi, and F. Tango, “Supporting drivers in keeping safe speed and safe distance: The SASPENCE subproject within the European framework program 6 integrating project PReVENT,” IEEE Trans. Intell. Transp. Syst., to be published. E. Bertolazzi, F. Biral, and M. Da Lio, “Real-time motion planning for multibody systems,” Multibody Syst. Dyn., vol. 17, no. 2/3, pp. 119–139, Apr. 2007. A. Amditis, L. Andreone, A. Polychronopoulos, and J. Engström, “Design and development of an adaptive integrated driver–vehicle interface: Overview of the AIDE project,” in Proc. IFAC 16th World Congr., Prague, Czech Republic, 2005. L. Danielsson, H. Lind, and S. Jonasson, “INSAFES HCI principles for integrated ADAS applications,” in Proc. HCI, 2007, pp. 339–348. HAVEit—Highly Automated Vehicles for Intelligent Transport. [Online]. Available: http://www.haveit-eu.org/ J. Scholliers, K. Heinig, J.-M. Blosseville, M. Netto, V. Anttila, S. Leanderson, J. Engström, M. Ljung Aust, F. Hendriks, J. Ploeg, and J. Chen, “Proposal of procedures for assessment of preventive and active safety functions,” in PReVAL Deliverable 16.3, Dec. 2007. [Online]. Available: http://www.prevent-ip.org/en/prevent_subprojects/horizontal_ activities/preval/preval_deliverables.htm

Angelos Amditis (M’03) received the Diploma degree in electrical and computer engineering and the Ph.D. degree in electrical and computer engineering (telecommunications) from the National Technical University of Athens (NTUA), Athens, Greece, in 1992 and 1997, respectively. He has been teaching various courses (communication and computer networks, communication theory, etc.) at the Department of Electrical and Computer Engineering and the Institute of Communications and Computer Systems (ICCS), NTUA, and the Hellenic Naval Academy for the last five years. He is also currently a Research Assistant Professor and a Project Manager with the Microwaves and Fiber Optics Laboratory, ICCS, NTUA. He is the author of several conference papers and of a Greek high-school-level book on telecommunication and networks. His current research interests include the fields of human–machine interfaces, telematics, data security, computer networks, Internet, Intranets, software development, virtual reality, telecommunications systems, electromagnetic compatibility/electromagnetic interference, radar, etc.

Enrico Bertolazzi received the Laurea degree in mathematics from the University of Trento, Trento, Italy, in 1990. Prior to receiving the degree in mathematics, he was with a small company developing numerical algorithms for computer-aided manufacturing. He is currently an Assistant Professor with the Faculty of Engineering, University of Trento. His research interests in numerical analysis include finite volumes for convective-dominated and hypersonic flow, discrete maximum principle, constrained optimal control, and scientific programming.



Matthaios Bimpas (M’09) received the Diploma degree in electrical and computer engineering and the Ph.D. degree in design and implementation of innovative radar sensors and antenna design from the National Technical University of Athens, Athens, Greece, in 2000 and 2004, respectively. He is currently a Researcher with the Institute of Communications and Computer Systems (I-SENSE Group), National Technical University of Athens. He is also a Professor with the Electronics Department, University of Pedagogical and Technical Education, Athens, and a Professor of sensor theory and antennas with the Department of Aircraft Engineers, Hellenic Air Force University. He has published 20 papers in conference proceedings and journals. His research interests include radar systems design (antennas and radio frequency design and construction), remote monitoring applications, communication theory, and the development of algorithms for fusing information from radar, cameras, and on-board sensors.

Francesco Biral received the Laurea degree in mechanical engineering from the University of Padova, Padova, Italy, in 1997 and the Ph.D. degree in mechanism and machine theory from the University of Brescia, Brescia, Italy, in 2000. He is currently an Assistant Professor with the Faculty of Engineering, University of Trento, Trento, Italy. His research interests include multibody dynamics and optimization, constrained optimal control, model predictive control, and motorcycle and automotive applications of safety systems and automatic control.

Paolo Bosetti received the Laurea degree in materials engineering and the Ph.D. degree in materials and structural engineering from the University of Trento, Trento, Italy, in 1997 and 2002, respectively. He is currently an Assistant Professor with the Faculty of Engineering, University of Trento, in charge of the courses on manufacturing automation, manufacturing process design, and the design of manufacturing systems. His research interests include the design and programming of mechatronic systems, industrial automation, and active control, monitoring, and error compensation in machine tools.

Mauro Da Lio received the Laurea degree in mechanical engineering from the University of Padova, Padova, Italy, in 1986. Prior to his academic career, he worked for an offshore oil research company in underwater robotics (a EUREKA project). He is currently a Full Professor of mechanical systems with the University of Trento, Trento, Italy. He is an expert of modeling simulation and optimal control of mechanical multibody systems (spacecraft to vehicles).

Lars Danielsson received the M.Sc. and Licentiate degrees in electrical engineering from Chalmers University of Technology, Göteborg, Sweden, in 2004 and 2008, respectively. He is currently with the Active Safety Electronics Department, Volvo Car Corporation, Göteborg, as an Industrial Ph.D. candidate associated with Chalmers University of Technology. His main research interest is in sensor data-fusion algorithms for active safety systems, although contributions have also been made in the field of warning strategies and human–machine interface design.

13

Alessandro Gallione received the Laurea degree in electronic engineering from the Polytechnic University of Turin, Turin, Italy, in 1999. Since 2000, he has been with the Fiat Research Centre, Orbassano, Italy, in the group dealing with advanced driver-assistance systems. Since 2008, he has been with Fiat Group Automobiles, Turin, as a Steering Control Systems Specialist in the Chassis Control Systems Team. He was involved in several projects that focused on vehicle lateral-control systems.

Henrik Lind received the M.S. degree in electrical engineering from Chalmers University of Technology, Göteborg, Sweden, in 1986. He is currently a Technical Expert with Volvo Car Corporation, Göteborg, within the field of active safety electronics. He has been working with sensors of various types, including radar, lidar, ultrasonic, and vision. He has also been working in the functional domain, where he has been deeply involved in the collision-warning application and the human–machine interface prioritization with other active safety applications. He is currently working on driver modeling for active safety applications, but his interests span from sensors to systems and actuators.

Andrea Saroldi received the Laurea degree in physics from the University of Torino, Torino, Italy, in 1985. Since 1986, he has been with Centro Ricerche Fiat, Orbassano, Italy, in the group dealing with advanced driver-assistance systems. His main field of activity refers to the processing of sensor data and the development of driver-assistance functions for preventive safety.

Agneta Sjögren received the M.Sc.E.E. degree from Chalmers University of Technology, Göteborg, Sweden, in 1989. She joined AB Volvo after her graduation. She started her career working with signal processing and model-based control, mainly in the area of active safety. She is currently an Area Leader within the Integration and Automation area, Volvo Technology Corporation, Göteborg. She has been the Project Leader for subproject INSAFES in the PReVENT Integrating Project.
