Karen asked: For example how we can in this day and age manage to crash two trains head-on traveling on the same track?
That's usually caused by technology, specifically by an operator texting or otherwise illegally using a mobile device instead of watching the track ahead and observing signals. It's pretty boring looking at the same stretch of track every day when nothing unusual ever happens. But an operator is paid to watch for that unusual event that can cause so much damage if it occurs.
Similarly, how does that V2V technology help when a driver is texting illegally instead of watching the control panel? (Maybe that's addressed in the article, which I haven't read yet.)
While this technology is all well and good any advance in making sure the driver is fully engaged in driving the vehicle would have a larger benefit. Impairments such as driving under the influence are common knowledge and certainly distraction due to texting or other high-tech actvities have also received much needed attention. As typical in any human endeavor there are always unintended consequences - would these high tech safety nets encourage more drivers to rely on the technology bailing them out of a dangerous traffic situation?
We should all know that NHTSA (and those in the automotive industry) have been particpating in the V2V plan for a long time. This isn't a paper plan -- their proposal has been backed up by data generated by many hours of testing done on the roads in Michigan.
That said, I find it almost ironic that some of the collision avoidance technologies suggested here in the proposal have been already executed by ADAS, thus this paper spends a lot of time comparing V2V with ADAS.
I get that there are things that could be only accomplished by V2V. I think it's useful. But as the proposal points out, in the end, our smartphone might be enough to satisfy this V2V mandate of the future.
mhrackin makes an excellent point about the NHTSA's blind spots - such as not anticipating the cost of software and an seeming inability to understand that standards should have an overall objective that is achievable and achieved by the framework of the standards.
This all seems like a nice set of tinker-toy scenarios - maybe because I'm drawn to the cartoons more than the text - but I don't see a baseline concept of 'vehicle' and 'communication' and 'event' - all of which require fine-grained definitions before any code is architectured.
Finally, I'm very concerned about the NHTSA's ability to develop a certification framework that will ensure that these systems work all the time and every time - witness the Toyota throttle contol module cases of the past few years. These have shown the NHTSA as a toothless animal (I hesitate to call it a tiger - maybe a jackal since they show up after the meat is killed) unable to define standards for even the most basic of vehicle systems - speed control, braking, steering and incident reporting. This allowed a bunch of amateur engineers at Toyota to crank out millions of badly designed software modules, most of which are still on the highway today.
If these things were flying the FAA would have grounded them before the first test flight, let alone going to manufacturing.
If we are going to let software protect us in hazardous situations (and it does today, even though it may not be obvious) that software must be known, understood and tested in real conditions. The days of 'it complies, it must work' are long gone.
I'm not sure how a system like that proposed by the NHTSA will be developed and implemented, but, withougt standards and realistic testing with hard pass/fail boundaries I will stick to walking in my central Wisconsin woodlands - maybe a tree will fall on me - well, OK, but that's not due to software...
This plan sounds really exciting in its potential to reduce accidents and save lives, but aren't there some even more basic hazards we could take care of first. For example how we can in this day and age manage to crash two trains head-on traveling on the same track?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.