Transportation Engineering and SmartDrivingCars, Vol. 1, No.3
Crowd Sourced Data
by Prof. Alain L. Kornhauser, Ph.D.
Data are a precious byproduct of the mobility, safety and environmental enhancements delivered by SmartDrivingCars. The capture, harvest, storage, dissemination, use and regulatory oversight of this invaluable byproduct needs a professional custodian. The ITE is the ideal society to oversee and perform this service.
Today, our eyes and ears sense the environment and our brain effectively figures out how our hands and feet should move in order to drive and usually not crash. For the most part, we do this very well. However, if, for whatever reason, we needed to recreate what just happened, we would be hard pressed. We are simply not able to recall in sufficient detail what we confronted, what actions we took and what actually happened. Consequently, essentially all of the intricate details describing what we experience is simply lost.
However, with SmartDrivingCars (SDC) , sensors necessarily convert the reality of the driving environment into data. These data are subsequently manipulated to provide the digital inputs to electronic controllers that activate the steering, throttle, brake, turn signals and other associated driving actuators. While there are, and always will be, limitations as to how “well” (reliably and thoroughly) the sensors convert reality into data and how “well” theSmartDrivingCar responds to the control inputs, there exists a deterministic coupling between the set of sensory data input and the set of data fed to the various controllers. Simply stated, during each short time interval, say 1/10th of a second, data are created that describe the current state of the SmartDriving Car, the environment in which it is operating and the actions that are being requested of each of its controllers. This means that whatever is happening at any instant of time, as well as what happened leading up to that instant and what happened after that instant, could be re-enacted, if so desired.
Such capabilities are essentially unachievable in today’s cars but are a fundamental byproduct of SDCs. The value of having the opportunity to re-enact the driving performance of the SmartDrivingCar (SDC) cannot be overstated. What is necessary; however, is that these data be captured and temporarily stored by each SDC and be subsequently harvested by some external entity that can make those data available to those that have developed and use the tools that deliver their inherent value to society.
The capture and harvest of these data from a substantial (>~25%) of the SDCs may well be the only practical way to both uncover and quickly address unsafe and previously unknown rare events. The data are absolutely necessary to design and test improvements that will enable the SDC’s automated driving system to safely and effectively traverse or to otherwise avoid those circumstances all together. As we all know, we don’t know what we don’t know. It is imperative that the data that allows us to recreate these events be captured as a normal operational activity so that those data are available if the even was one of particular interest. Since everything is operating in real time, going backwards in time to capture and store data is not an option. The data capture and storage must be done pro-actively.
Addressing rare events, while likely the most important, is but one of many uses for these data. As has been shown with respect to monitoring real-time travel times on today’s highways to enhance the effectiveness of today’s turn-by-turn navigation systems , such crowd-sourced data will be an effective way to monitors the effectiveness of the SDC’s lane keeping system. Using simple cellular based communications systems a database can be maintained identifying which lanes between which mileposts are sufficiently well designated, signed and supported so that your particular SDC can deliver “level 3” functionality. Such designations could then be used by the SDC’s navigation system to more properly tailor a route for you. Such crowd sourced data could also be used by the local transport authority to plan and schedule maintenance and improvements.
Numerous other uses exist for such data; the important message is that each SmartDrivingCar necessarily creates these data in real time. They could easily be used and erased. Alternatively, with slightly more effort, they can be used, stored, harvested and put to good use. I’m suggesting that ITE take on the role of harvesting and putting to good use these data.
Associated with this effort is the collateral burden of privacy. This is a non-trivial issue for which I offer a straightforward, but not necessarily simple approach: Each SDC should be equipped with the capability to store and harvest the appropriate data and that the functionality be user-enabled and completely voluntary. It was my experience with the CoPilot turn-by-turn navigation system that a substantial percentage of CoPilot users voluntarily shared with ALK the GPS data that their CoPilot stored in real time. These users were only asked to share the data so as to help ALK improve the product. Their only direct benefit was helping ALK improve the product. The customer response was uplifting. I believe that this, plus one other thing, is all that will be necessary with respect to the real-time SDC automated driving data.
That other thing is a “hold harmless/no self-incrimination” clause.
Since we are dealing here with data that can reconstruct the driving behavior, including the events leading up to and through an accident, we are dealing with extremely serious implications that could point fingers all over the place, including back to the owner of the SDC. Given such serious implications, it is extremely unlikely that any individual would behave like a CoPilot user. The risks are enormous and the reward is infinitesimal. Unless there is legislation that characterizes these data as being self-generated and consequently self-incriminating and that additional protection be provided by “hold-harmless” clauses. It is my understanding that these legal issues are not easy; however, I call on ITE to work to have these enacted; else, all of the discussion above about the value of the data will all be in vain. No one will allow these data to be captured, let alone stored and harvested.
· identification and classification of road environments for which the automated driving function can be expect to function properly,
· the identification of improvements that need to be made in the road environment (for example, better paint, better signs, etc.), in the sensory systems, in the processing code and/or in the control systems, and
· the identification of situations and use cases that were simply not anticipated in the design considerations to date. (For example, when airbags were first placed in front of the passenger seat, no one expected that they might injure a child sitting in the front seat. However, as soon as this rare event was experienced, precautions and preventative measures were designed and implement to avert this unexpected consequence. It is likely that there will be extremely rare driving situations in which the response of the SDC will be less than desirable. It is critically important that as soon as these rare events are encountered, that they be addressed as soon as possible. The effective handling of these situations will require the availability of these data sets.
· This means that all situations in which the SDC performed well could be documented and understood and more importantly, all the situations in which the SDC did not perform up to expectations could also be studied with the expectation that the code that constructs the data outputs to the control systems from the sensory data inputs could be modified to improve the SDC performance. If performance could not be improved, then such data can be used to identify the locations and conditions under which
To date we have had to rely on people’s memory to sort out what happened. With SmartDrivingCars, we’ll have the data. Or we need to make sure that we have the data. The self-enhancing aspects of data availability will enable us to achieve even greater mobility, safety and environmental …
As is common, data is very expensive to collect
What is needed ids for the makers of SDCs to include the data storage capabilities to capture and store the data as well as the creation of the the software and the communications/ddata interfaces to appropriately and efficiently harvest the data. The custodian of the data (ITE) will need to store the data, manage its dissemination, oversee its use and lead/participate in the creation of the tools to properly use the data.
All that said, this effort needs two very importantpublic oversight layers. One focused on ensuring that personal privacy is protected and the other, and more important, aspect is to have legislation created that guarantees that any and all individuals are held harmless in the use of the data. In other words, no individual shall in any way be adversely affected by the existence of such data.
+++++++++++++++++++++++++++++++++
Last month I began by defining SmartDrivingCars, described their opportunity to substantially enhance mobility and quality of life and set the vision of this column as addressing: How does the Transportation Engineer of the future best help to accelerate the development and adoption of SmartDrivingCars?
With that as our mission, let’s start with fundamentals. To me the most fundamental of fundamentals is the realization that SmartDrivingCars will necessarily coexist with conventional cars, buses and trucks for a very long time and that peaceful and even synergistic coexistence is best.
Automated Highway System (AHS) were conceived in the 1930s, 40s, 50s and 60s, studies and tested in the 70s, 80s and 90s and went nowhere.
Excuses abound as to why AHS never got anywhere. Most likely, AHS never had a chance: Individual consumers were expected to purchase vehicles whose salient feature (automation) only worked on exclusive roadways that were to be designed and built to accommodate only these specially equipped vehicles. This untenable chicken-egg problem had no way of evolving from nothing to something. Even the most visionary public sector would never risk building roadways to accommodate privileged yet-to-exist vehicles and not even the earliest consumer would buy a specially equipped automated vehicle unless a substantial roadway infrastructure existed where he could “strut his stuff”. No manufacturer would invest to build an automated car that required its own exclusive roadway until there existed some amount of those roadways. “Instrumenting” 7.6 miles of I-15 in 1997 convinced no one to invest in building automated cars. An automated roadway investment many orders of magnitude larger would have been needed. Consider the lack luster adoption of electric vehicles even in the presence of substantial rebates, a favorable public persona and facts such as “less than 5% of all car trips are greater than 40 miles”. Even these advantages aren’t sufficiently comforting when compared to a seemingly ubiquitous conventional car to trigger viral adoption. Risk aversion dominates investment decisions. AHS was DoA.
To break AHS’s impossible “chicken-egg” dilemma, the word “System” had to be purged from AHS. No longer should the focus be on creating an exclusive union of automated vehicle with its own exclusive guideway. Rather, it should be similar to how conventional drivers operate on an individual “user” basis rather than on an orchestrated “system” basis. Each driver is responsible for his/her own decisions to stay in a lane and not crash into anything. Drivers have a range of capabilities, some good, others not so much. Removal of the Systems concept allows the SmartDrivingCar to simply be viewed as just another driver with its own set of capabilities. Let drivers choose to take advantage of the improved performance by letting the car drive itself where and when those capabilities are better. Else, the driver simply continue to drive. This coexistence with the conventional adds complexity to the SmartDrivingCar, but allows that complexity to be developed and improved on the individual vehicle without requiring any changes in any of the conventional vehicles or the existing infrastructure.
Thus, attention is shifted to the beginning: making the first vehicle co-exist and work well within a large part of the existing environment. Success with one vehicle, while possibly expensive, creates a demand for even that one co-existing vehicle. If the cost of replication is very small (as is the case for “Moore’s Law technology”, then that second and subsequent replications have a chance at having an enticing value proposition that leads to viral consumption. The Darwinian key is the small replicating costs coupled co-existence with the existing vehicles infrastructure.
What is role of the future Transportation Engineer? The above hints that there is nothing “to do” for her to do. Not true!
Instead of focusing on exclusive automated highways, Transportation Engineers could focus on investments that not only improve the performance and safety of conventional drivers, but also SmartDrivingCars. Coexistence will require these SmartDrivingCars to be able to “see” and react appropriately to the same visual cues that enable conventional drivers, if alert, to operate safely and effectively.
This is a unique opportunity for the Transportation Engineer to improve the roadway environment for both alert conventional and SmartDrivingCarss. Since the existing roadway and traffic control infrastructure has been largely built around the use of human vision as the communications interface that results in safe driving, then it can be expected that the winning SmartDriving technologies will rely on these same visual cues to instill safe driving.