USDOT seeks responses to a task order proposal for two of its traffic flow optimization concepts

April 18, 2013 at 6:33 pm

The U.S. Department of Transportation (USDOT) is seeking responses to a task order proposal for two of its traffic flow optimization concepts

The Task Order Proposal Request (TOPR) is issued under the FHWA IDIQ contracts listed below.  Task Order Proposal must be submitted by 3:00 pm eastern standard time on April 30, 2013. Please direct any questions to the contracting officer, Daniel Confer. He can be reached at Daniel.Confer@dot.gov .

ALL Contractors are eligible to compete on this Task Order Proposal Request but they need to partner with the following firms:

  • DTFH61-12-D-00040 – Battelle Memorial Institute
  • DTFH61-12-D-00041 – Booz Allen Hamilton
  • DTFH61-12-D-00042 – Cambridge Systematics
  • DTFH61-12-D-00043 – Iteris
  • DTFH61-12-D-00044 – Kittelson & Associates
  • DTFH61-12-D-00045 – SAIC

The scope of work of this task order is to: (i) develop a prototype of Dynamic Speed Harmonization with Queue Warning, which are two component applications of the Intelligent Network Flow Optimization (INFLO) bundle, (ii) conduct a small-scale demonstration of the prototype, and (iii) collect “before” (pre-demonstration) and “after” (during demonstration) data from the small-scale demonstration which will be used to support the assessment of the impacts of the prototype as well as a regional deployment of the two applications in an operational system. The USDOT expects the Contractor to apply sound software development and project management principles in conducting this work.

The INFLO bundle is a collection of high-priority, transformative applications that target maximizing roadway throughput, reducing crashes, and reducing fuel consumption through the use of frequently collected and rapidly disseminated multi-source data drawn from wirelessly connected vehicles, travelers’ communication devices, and infrastructure. This Statement of Work specifically addresses the prototyping of Dynamic Speed Harmonization (SPD-HARM) with Queue Warning (Q-WARN), a small-scale demonstration of the prototype, and collection of before and after data. SPD-HARM and Q-WARN are two component applications of the INFLO bundle.

Although the INFLO bundle includes a third application, namely the Cooperative Adaptive Cruise Control (CACC), further research outside of the scope of this task order will be required prior to prototyping the CACC application. The USDOT wishes to advance SPD-HARM and Q-WARN from concept formulation (completed in 2012 during Phase 1 of the DMA Program) to prototype development and small-scale demonstration of the prototype (to be completed in Phase 2 of the DMA Program) to test if the two applications can be successfully prototyped and deployed in the future. The data and findings from the small-scale demonstration will help USDOT make more informed decisions regarding the technical feasibility and potential impacts of deploying the two applications more widely. Similar prototyping and small-scale demonstrations will be conducted for each of the DMA high-priority bundles. In Phase 3, the DMA Program will seek suitably tested and promising application bundles from the six high priority bundles for possible inclusion in a larger scale pilot deployment operational test.

A short description of the two INFLO applications is provided below. For a detailed description, please refer the INFLO Concept of Operations (1 Mahmassani, H., Rakha, H., Hubbard, E., and D. Lukasik. Concept Development and Needs Identification for Intelligent Network Flow Optimization (INFLO): Concept of Operations, Prepared by SAIC for USDOT, June 14, 2012.)

The two applications may be implemented with varying levels of complexities and interrelationships. These levels of complexity and potential interaction may change over time as underlying technologies mature and wireless connectivity between vehicles and the infrastructure becomes increasingly ubiquitous. The USDOT seeks near-term prototype concepts that are likely to yield system and user benefits even at early stages of connected vehicle technology deployment. Further, the concepts prototyped in this task should support an evolutionary path wherein the impacts associated with these applications grow as the number of connected vehicles increases.

Dynamic Speed Harmonization (SPD-HARM): The INFLO SPD-HARM application concept aims to maximize throughput and reduce crashes by utilizing infrastructure-to vehicle (I2V) and vehicle-to-vehicle (V2V) communication to detect impending congestion that might necessitate speed harmonization; generating appropriate target speed recommendation strategies for upstream traffic; and communicating the recommendations to the affected vehicles using either I2V or V2V communication.

The SPD-HARM concept reflects an operational environment in which speed recommendation decisions are made at a Traffic Management Center (TMC) or a similar infrastructure-based entity, and then communicated to the affected traffic. In such an environment, the SPD-HARM application resides within the infrastructure-based entity and is external to the vehicle. Such an approach was taken since an adhoc V2V communication is not well suited to providing a comprehensive view of the roadway traffic conditions, which is fundamental to effective speed harmonization. Communication of target speed recommendations to the affected vehicles will always give priority to crash avoidance/mitigation safety applications when such applications determine that a safety alert is necessary.

Queue Warning (Q-WARN): The INFLO Q-WARN application concept aims to minimize or prevent impacts of rear-end or secondary collisions by utilizing I2V and V2V communication to detect existing queues and/or predict impending queues; and communicate advisory queue warning messages to drivers in advance of roadway segments with existing or developing vehicle queues. The Q-WARN concept reflects an operational environment in which two essential tasks are performed: queue determination (detection and/or prediction) and queue information dissemination. In such an environment, the Q-WARN application may reside in the vehicle or within an infrastructure-based entity, or utilize a combination of both. The queue warning messages may either be communicated by the infrastructure-based entity using I2V communication or broadcast by vehicles that are in a queued state to nearby vehicles and infrastructure based entities. It is important to note that the Q-WARN application concept is not intended to operate as a crash avoidance system (e.g., like the forward collision warning safety application). In contrast to such systems, Q-WARN will engage well in advance of any potential crash situation, providing messages and information to the driver in order to minimize the likelihood of a crash avoidance or mitigation actions later. As such, Q-WARN-related driver communication will always give priority to crash avoidance/mitigation safety applications when such applications determine that a safety-related alert is necessary.

 

 

Enhanced by Zemanta

Wheels of the future: This awesome infograph highlights the next wave of vehicle technologies to hit your car

May 30, 2012 at 1:41 pm

(Source: Symphony Services via Mashable.com)

Image Courtesy: Mashable.com

Human in the Loop? or NOT? – Slate Magazine Says Google’s Self-Driving Car Makes Sense

October 12, 2010 at 6:52 pm

Slate’s Farhad Manjoo says Google’s approach to dealing with distracted driving is a sensible one. We all know texting while driving is dangerous. The solution: self-driving cars.

Amplify’d from www.slate.com

On Sunday, the New York Times reported that Google is building a car that can drive itself. The search company’s small fleet of self-driving cars—guided by roof-mounted sensors and a battalion of cloud-connected servers—has driven more than 140,000 miles with minimal human intervention. The cars can obey traffic signs, merge on to the freeway, and avoid pedestrians and bicyclists. I was stunned by the news; two years ago, I interviewed several auto-safety engineers about the potential for self-driving cars, and they all told me that the technology was decades away. Google told the Times that its cars are still an experiment, and the company hasn’t decided to turn the tech into a commercial product. The tech still has kinks—Google’s cars don’t know how to obey traffic cops’ hand signals, for instance. Still, self-driving automobiles appear to be on the way to revolutionizing modern transportation. Google’s technology could make cars safer, more efficient, and a lot more pleasant.

Indeed, it’s fascinating to think about how automated driving will change how we spend our time in the car. Americans squander nearly an hour each workday commuting. That’s exactly why legislating concentration seems like a futile approach. Working from the road has become a hallmark of the American economy—we’re all being pressed to be more productive, and the many hours each week we’re trapped in our cars seem like the perfect time to get something done. Many industries (like freight companies and plumbing outfits) require workers to be tied in to the central office using onboard computers, and even office workers feel the push to stay connected while on the road. What’s more, research suggests that while both teenagers and adults (PDF) know the dangers of texting while driving, we’re all overconfident about our own abilities to multitask on the road—you think it’s dangerous for me to look at my phone while I’m driving, but you’re pretty sure you can handle it. (And texting laws are so spottily enforced that you’re pretty sure that you can get away with it, too.)

Read more at www.slate.com

 

A Nightmare For #IntelliDrive ? Hackers Wirelessly Crash Car’s Computer At Highway Speeds

August 11, 2010 at 3:31 pm

This is inevitable in the world of electronic data and what bothers me is the fact that it can be done with relatively cheap labor (total cost of $1500) and some good amount of graduate engineering research work. If such a thing were to happen in the world of talking cars (IntelliDrive), would it open up the possibility of creating “zombie” cars whose networks can be manipulated and controlled externally to create horrific crashes? Not sure but that is terrible to even think about. Whatever be the case, the designers of the modern cars (especially the ones designed for the IntelliDrive era) should take this possibility into account and come up with fool proof data security.

Amplify’d from jalopnik.com
Hackers Wirelessly Crash Car's Computer At Highway Speeds

We’ve told you before about experiments to hack into the increasingly complicated programming in modern vehicles. How complicated? A typical luxury sedan will carry three miles of wiring, scores of processors and close to 100 million lines of software code, or roughly 20 times more than used in a F-35 Joint Strike Fighter.

Those previous experiments showed what could be done with a physical connection to a vehicle’s computer. The new work by teams from the University of South Carolina and Rutgers tried a different tack: spoofing the wireless sensors in wheels used by tire pressure monitoring systems, required in all new U.S. vehicles since 2008.

The researchers didn’t find a wide-open door so much as the security employed by a 1920s speakeasy: once they learned the secret knock, the unidentified test car’s controls let them in no questions asked. The team sent fake warning messages from 40 meters away, and in another experiment, got the test car to flash a warning that a tire had lost all pressure while beaming the signal from another car as both drove 68 mph.

Because each sensor uses a unique ID tag, it was also possible to track specific vehicles, in a way that would be far less noticeable than roadside cameras.

Read more at jalopnik.com