Details Emerge about the Cooperative Intersection Collision Avoidance Systems (CICAS) Initiative

(Last updated 5/15/05)

New details about the CICAS Initiative, one of nine "New Initiatives" announced by the U.S. DOT a year ago, emerged at the recent 2005 ITS America Annual Meeting in Phoenix, AZ. CICAS is a logical extension of the earlier Intelligent Vehicle Initiative (IVI) that demonstrated several futuristic intersection safety applications at the FHWA’s Turner-Fairbank Research facility in mid-2003. Instead of simply demonstrating the potential of these new applications, however, CICAS plans to help set the stage for the ultimate deployment of key intersection safety "countermeasures." ICDN Editor Jerry Werner recently discussed the initiative’s strategy and early plans -- including the thinking as to which applications may emerge sooner and which later -- with Mike Schagrin, Manager of the CICAS Initiative in the USDOT’s ITS Joint Program Office.

ICDN: I understand that CICAS (pronounced "see-kass") is bringing together two former IVI groups that had been working independently. Is that correct?

Schagrin: The automotive OEMs (original equipment manufacturers) and states have been working separately and independently for a number of years under the IVI (Intelligent Vehicle Initiative) Program, and now we’re bringing them all together to work collectively on a common vision and concept under the CICAS Initiative.

ICDN: Up until now these two groups haven’t been interfacing with each other?

Schagrin: Prior to CICAS, no. The OEMs were working on specific tasks under the IVI umbrella, such as DSRC (dedicated short-range communication) issues, the ED (enhanced digital) map, and driver workload.

ICDN: Was this work conducted under the umbrella of CAMP?

Schagrin: Yes. CAMP, which stands for the "Crash Avoidance Metrics Partnership," includes seven OEM auto manufacturers and is led by GM and Ford. CAMP has been in existence for a number of years under the IVI Program. We’re using that same partnership and contract mechanism to get to the seven OEMs again. Under the CICAS Program we’re forming a partnership, bringing everybody together to work collectively on developing countermeasures for the intersection crash problem.

ICDN: Could you explain in plain English, not researcher jargon, what are the four intersection safety problem areas that CICAS is addressing?

Schagrin: The four areas are:

1. Stop sign violation
2. Red light running
3. Making a left-hand turn at a signalized intersection across the path of oncoming traffic.
4. The stop-sign "gap-assist" problem.

The fourth category involves the scenario where vehicles that come to a stop at a stop sign and cross traffic, which may be traveling at high speeds, doesn’t have a stop sign. In rural areas of Minnesota, for example, many highways have crossroads with stop signs. Often, drivers at those stop signs will misjudge the speed and distance of cross-traffic as they attempt to make a turn or go straight across the highway after stopping. Having misjudged the gap between them and the other vehicle, they then get hit. Because of the high speeds involved, these types of accidents are often very severe with high fatality rates.

ICDN: Am I correct in saying that these four scenarios or problem areas that you described encompass the majority of accidents related to intersections?

Schagrin: There are about 9500 deaths per year at intersections. The large majority of those fatalities are as a result of the kinds of crashes we’re talking about.

ICDN: Can I assume that the CICAS program is an extension of the Intelligent Vehicle Initiative (IVI) program that was talked about at the 2003 IVI Annual Meeting (link: "Inside the USDOT’s ‘Intelligent Intersection’ Test Facility")? Are you basically taking the same problem areas? Those earlier efforts involved demonstrating prototype technologies, and now you’re taking those efforts further, right?

Schagrin: IVI definitely focused on early research, and now we’re developing applications and positioning these technologies to be ready for deployment. It’s still a research program, but we’re going to start prototyping and demonstrating these countermeasures. We plan to hold field operational tests (FOTs) that will involve thousands of cars over a multiple-year time period. Those FOTs will help demonstrate the value, that is, the costs and benefits of these systems, as well as how well they are accepted by users. We have to ensure that these countermeasures have an acceptably low level of false alarms and that they are in fact effective in mitigating these types of crashes.

Figure 1: Progression of CICAS applications.

ICDN: You mentioned in your recent presentation at the ITS America Annual Meeting that it’s not clear whether those countermeasures will be implemented in the vehicle, in the infrastructure, or might involve some combination of the two approaches. Is it a prime objective of your collaborative OEM/infrastructure teams to try to identify where best to do these countermeasures?

Schagrin: Right. For example, with the signal and stop sign violation problem areas, we’re initially working on having a driver-vehicle interface, or "DVI," that involves an in-vehicle warning. That warning could also be extended to some kind of control, or more specifically, some kind of braking function that could be used to help avoid a crash. We’re also looking at various countermeasures for the gap-assist problem areas, but in those cases there’s been more research and we’re better positioned to demonstrate some driver-infrastructure interfaces -- in other words, roadway signs.

Subsequently (see Figure 1), we will also likely be demonstrating and testing some in-vehicle countermeasures for the gap-assist problem areas, although these areas are very complicated and additional research is needed. Our current thinking is that "dynamic mapping" of the intersection is needed to support many of the gap-assist countermeasures. That whole area needs to be fleshed out further before the car companies can come in and say, "this is the kind of countermeasure we want to develop for the in-vehicle system," because they’re not sure yet. They want to see the dynamic mapping concept proven out and then want to understand what are the best countermeasures for those kinds of scenarios. They want to understand better what’s possible, what’s doable.

ICDN: Do most or all of the countermeasures you’re focusing on require vehicle-to-infrastructure communication?

Schagrin: Yes. All the scenarios I’ve talked about depend upon communication between the vehicle and the infrastructure. However, a number of different types of information could be communicated. For example, transmitting signal-timing information and the geometric design of the intersection to the vehicle are some of the big hooks to the infrastructure.

ICDN: You’re transmitting signal timing so that the vehicle can compute whether or not it can stop in time at a red light, for example. Right?

Schagrin: That’s correct if the computation is done in the vehicle, which is one option. Either the vehicle or the infrastructure would display a warning to the driver. If the infrastructure knows what the signal timing is and knows where the vehicle is – speed and distance – the threat assessment algorithm would process whether or not it needs to generate an alert or not.

ICDN: So the algorithm that generates the warning could run either in the vehicle or on the infrastructure?

Schagrin: That’s right. We’re looking at both scenarios.

ICDN: So you might support FOTs of both scenarios to identify the tradeoffs?

Schagrin: Yes. We’re first looking at doing the processing in the infrastructure. Initially this dynamic map I mentioned earlier is going to be generated by the infrastructure and then transmitted to the vehicles as they enter the intersection area. From that information, the vehicle can then compute whether or not it needs to generate a warning. In the future, vehicles communicating directly with each other with little or no infrastructure involvement might generate that dynamic map.

ICDN: What you’re talking about in these four scenarios are closely related to what are called the "use cases" in the VII effort, are they not? In fact, they’re some of the primary safety drivers for VII, is that a fair statement?

Schagrin: The VII group has identified roughly four or five use cases involving intersection collisions, and they are priority areas. Safety is a big issue, of course.

ICDN: Does that mean for CICAS to work VII needs to be in place?

Schagrin: For CICAS to work we need to have the enabling communications capability, which is DSRC in the new 5.9 GHz band. That’s the only communication technology that can meet the latency and other requirements we need.

ICDN: "Latency" meaning how quickly vehicles can communicate to the infrastructure and to each other in order to respond to pending safety issues? This type of response has to initiate in milliseconds, right?

Schagrin: Right. You can’t do high-speed communication through any other current communications technologies, and therefore that’s why we’re locked into DSRC right now. That’s not to say that things could change in the future with the introduction of other communications technologies, but right now DSRC is the only suitable technology for safety applications.

ICDN: At the 2005 TRB Annual Meeting, you presented a timeline diagram that showed how CICAS’ milestones and test cases would dovetail with the VII milestones. I didn’t see that slide in your more recent presentation at the ITS America Annual Meeting.

Schagrin: I left that out of my slide presentation, but the concept is still there. We’re looking at developing the CICAS applications by themselves first. We want to first demonstrate that they work in isolation in very controlled environments. When we feel comfortable that they work appropriately, we’ll bring them into the VII prototype platform. By bringing them into the VII platform along with other VII applications, we’ll see if they will work in a multi-application environment, to make sure there are no discontinuities, conflicts or incompatibilities. Once we’re satisfied with that, then we can move the whole multi-application platform into the VII FOT. That’s the staged process we’re talking about.

ICDN: Do you have any dates in mind for field operational testing, or is it premature to talk about dates at this point?

Schagrin: I can give you a rough sense. We’re allowing two years for CICAS application development and prototyping. We need to get further along to see the details as to how it’s all going to play out, but we’re looking at starting some kind of FOT activity in the 2007 timeframe. It could be a full-scale activity, it could be a small subset, but somewhere in 2007 we’re hoping to start real-world testing. The work that I’m doing with the auto manufacturers through CAMP and with the states is a "pre-FOT" activity. We’re currently involved with developmental work, and any FOT type of activity would be through a separate procurement process.

ICDN: When you talk about "countermeasures," you’re talking about a range of options all the way from warnings to possible automatic control of vehicles to avoid accidents. I presume that the early application development and testing would involve warnings, and the system might evolve more into control as you gain more experience, is that how you see it playing out?

Schagrin: Right. We’ll start off with simple warnings and simple intersections. Those warnings could be audible, they could be visual, they could be haptic. You could also be looking at some kind of braking system that could be produced fairly early. It wouldn’t be a full braking system, but some kind of scheme that would help a driver react more quickly. In the long-term under a gap-assist type of scenario, for example, I could envision some kind of braking system that would not allow someone who’s already stopped at a stop sign to drive into a dangerous situation. You’re not actually braking the vehicle to slow it down, you’re trying to keep it from moving into a dangerous situation and getting hit.

ICDN: So the application in this case might control the car’s throttle?

Schagrin: It could involve the throttle, it could involve the brake. I wouldn’t want to project how that would actually happen, but it’s a concept that needs to be explored more fully.

ICDN: In your presentation at ITSA05, you talked about countermeasures for an impending stoplight violation. You mentioned that one countermeasure might provide a warning to the driver – "you’re about to violate the stop light" – and another might potentially extend the green or yellow time.

Schagrin: No, I never said green or yellow. You might want to extend the red light for cross-traffic if the car approaching an intersection at high speed isn’t going to be able to stop in time and poses a threat to cross-traffic. This type of solution is not without its problems, though. If in fact we’re able to extend the red light to cross-traffic and people now know that would happen, they could, of course, start "gaming" the system -- running red lights and knowing they could get away with it. So one of the key issues is to what extent you would need to have some kind of enforcement capability. While we’re not necessarily designing enforcement into the system, it’s obviously going to be an issue for discussion.

Ultimately deploying any kind of system like this would also depends on the policies and laws of particular states and localities, particularly whether or not some kind of enforcement capability would be allowed. Our objective is to create a set of tools that different public agencies can employ as they find them beneficial.

Figure 2: Dynamic Mapping example.

ICDN: Let’s explore the idea of "dynamic mapping" further. (See Figure 2.) Essentially you want to very precisely know where all the vehicles are at intersections, in particular, and dynamic mapping is a requirement for some of these advanced approaches that you’re talking about, right?

Schagrin: Dynamic mapping really applies to the gap assist area, more than to stop sign or stoplight violation. Dynamic mapping means you know where all the objects are that are moving within the area of the intersection: how fast they’re moving, where they are, how far they are from the intersection. For example, take the case where somebody’s at a stop sign waiting to go forward and you want to help him or her with that gap. If the car’s database and computer knows from this map where all the vehicles are, it can tell the driver whether it makes sense to pull out from that stop sign. It could also warn the driver, for example, that a pedestrian on the left-hand side could be potentially hit if the driver makes a left-hand turn.

ICDN: Dynamic mapping also includes knowledge of the location of all pedestrians within an intersection?

Schagrin: Any It includes any dynamic objects in that intersection -- a. Any type of vehicle, pedestrians, and bicyclists.

ICDN: That sounds pretty futuristic. Do you think you’ll be doing some field operational tests involving this capability?

Schagrin: It’s quite possible. Another ongoing project – a "Tier 2" project – is investigating a number of things related to pedestrian detection and warning. (See description on USDOT's website.) If you recall, Tier 1 projects, such as CICAS, are all about high risk and high payoff. It’s not business as usual – we’re not necessarily looking at conservative approaches, we’re looking at what is possible. Some things may pay off and some things may not.

Dynamic mapping could extend to other applications outside of the intersection. If vehicles themselves can create this dynamic map, for example, you could be positioned to understand the dynamics at any intersection, not just those that are instrumented. Many intersections involve no traffic control whatsoever.

Dynamic mapping could also be useful for non-intersection applications, as well. For example, you might be able to use this capability to better understand the state of the road near you when you want to change lanes. "State of the road" meaning who’s around you, where are they in relation to you, and how fast are they moving with respect to you. You could potentially extend this technology to a lot of other applications outside the intersection and beyond just safety, too.

ICDN: The ability of vehicles alone to create these dynamic maps is not a near-term vision, is it?

Schagrin: We’re actually exploring the vehicle-to-vehicle type of communications necessary to do dynamic mapping in parallel with the creation of dynamic maps using infrastructure sensors. The infrastructure-sensor capability is much more near-term. We have to figure out how cost-effective that approach is, because it’s going to be costly to instrument an intersection.

In the long run it will probably be much more cost-effective to instrument vehicles with DSRC and have them create this mapping, but it would be many years out before you have enough market penetration to reliably do that kind of mapping. In the near term we’re looking at instrumenting some intersections and seeing if the concept works. If it appears it’s going to work, then we can start investing more resources in the vehicle-to-vehicle side of things. We’re exploring a number of options right now. The field operational test may or may not include any kind of vehicle-to-vehicle mapping.

ICDN: We’ve talked about a number of different safety applications, but clearly a lot of things need to be in place before any of these applications would see widespread field deployment. What do you see as some of the bigger challenges in making these types of technologies ultimately available to the traveling public?

Schagrin: Positioning – knowing the vehicle’s location very precisely – is a key factor. Under the IVI program, CAMP had done some work with enhanced digital (ED) maps. Accuracy was an issue. Some applications need to know not only "which road?" but "which lane?" Obviously, determining which road is easier to characterize than figuring which lane. However, some of the CICAS concepts require more knowledge than simply which lane a car is in. So in the early stages of the CICAS program we’re looking at how to do better positioning enhancement in terms of accuracy and coverage. In many cases, a GPS signal is just not good enough.

ICDN: Even "enhanced GPS?"

Schagrin: The problem is related to situations where trees cover the road or you’re in "urban canyons" and don’t get sufficient satellite coverage to determine positioning. We’re looking at ways of enhancing that positioning capability, both in terms of capability and accuracy. A big issue in the early stages of CICAS is how to make those enhancements affordable.

For the gap-assist countermeasures, dynamic mapping is a new area that has not been proven yet in terms of its capability and affordability. So doing the research and development for dynamic mapping is another key technology area that needs to be worked through and developed.

Of course, affordability in terms of the capital costs for deploying the initial subsystems on both the infrastructure and on the vehicles, as well as operations and maintenance costs, are always big issues. User acceptance is another key issue. The user will likely disable a countermeasure that has too many false alarms. Users won’t trust countermeasures that miss opportunities to provide alerts for impending crashes. That whole area of user acceptance needs to be fleshed out more. These are all risk areas, things we need to work through as part of the development and field operational testing activities of CICAS.

Mike Schagrin can be reached at Mike.Schagrin@fhwa.dot.gov