Goal:
The goal of this abstract is to propose a completely new,
comprehensive system of regulation and control for self-driving/autonomous
vehicular traffic on a municipal and eventually nationwide basis. Such a
system, fully realized would seriously curtail (or even prevent) such mishaps
of deaths caused by unregulated autonomous vehicles operating on open roads
with manually driven cars, non-powered vehicles, and pedestrian traffic.
References:
None
Hypothesis:
If self-driving vehicles are to be the next wave of the
future, then a completely new and comprehensive system of traffic control will
be required. The current approach a placing self-driving vehicles onto open,
unregulated roads along with manually driven vehicles and pedestrians has
already proven to be a tragic misdirection. A completely new, comprehensive,
(eventually nationwide) control system is needed to prevent further tragic
mishaps.
Experiments:
None
Methods:
The abstract proposes the combining of existing technologies
along with entirely new ones to retrofit roads and vehicles, with the addition
of a network of control centers or towers similar to the systems used by air
traffic controllers.
Results:
None
Conclusion:
A project of this magnitude must begin with an extended
series of studies for feasibility, and expense projections to determine the optimum
method for integrating the required technologies onto existing road systems and
vehicles. With the ultimate goal being the complete automation of all vehicular
traffic, this abstract merely proposes a beginning, groundwork study; one which
can be used as a starting point and a guide to a multi-year, multi-municipality
endeavor.
Improved System for
Self-Driving or Autonomous Cars
How Self-Driving Cars
Work: “While design details vary, most
self-driving systems create and maintain an internal map of their surroundings,
based on a wide array of sensors, like radar. Uber’s self-driving
prototypes use sixty-four laser beams, along with other sensors, to construct
their internal map; Google’s prototypes have, at various stages, used
lasers, radar, high-powered cameras, and sonar.
Software
then processes those inputs, plots a path, and sends instructions to the
vehicle’s “actuators,” which control acceleration, braking, and steering. Hard-coded
rules, obstacle avoidance algorithms, predictive modeling, and “smart” object
discrimination (i.e., knowing the difference between a bicycle and a
motorcycle) help the software to follow traffic rules and navigate obstacles.”
The Problems
I.
The
Current Model: Attempting to replicate human-based
vision systems is an error and the cause of many problems with current systems.
The idea of self-driving cars is to improve
on the human-based system, and not to multiply and/or increase the flaws of
that system. If the goal of such systems is not
to improve on the shortcomings of human-operated vehicles, then drivers may
as well continue to driving their cars themselves.
II.
Identification,
Control, & Redundancies: Self-driving cars need
to be identified as such, for public safety and as possible hazards to health
and property. They also need to be tracked at all times. They also require redundant control systems
in case of failure of one of the systems while the vehicle is in moving in
‘live’ traffic. Each car in autonomous mode should
have at least two (preferably three) redundant Drive Control modules
(computers) which can operated either in tandem, or, in the event that one or
more are damaged, individually. While operating in tandem, a (voting) majority
of these modules must agree on any
drastic change in the operation of the car at speed, before that change is
enabled by the actuators. If two or more of the modules are damaged, then a
human owner or responsible passenger must be able to take the wheel to steer
the car for the rest of the trip. (These
modules could be smartphone-based, but ideally ‘should’ be separate from, and
independent of the owner’s personal smartphone or similar device in the main
functions. However, they could conceivable be networked with that phone when
the owner inserts the phone into the vehicle’s ‘command cradle’. See section on
gray boxes.)
III.
Traffic
& Situational Blindness: Trying to integrate a
largely human-like vision system within the restrictions and conditions of
today’s roads is an error because it does not take into account human reaction
time (in human assisted or human commandeered
driving), or even ‘machine error’; something that will exist until such
systems are perfected.
IV.
Isolated
Technology is an error in direction. An onboard
self-driving, autonomous system needs to be supported by external systems with
an areal and aerial point-of-view
which considers each car and each parcel of space around each car, just as air traffic control systems maintain for
jets.
V.
Lack
of System-wide Security: Currently, self-driving cars (and
drones) can be compromised by deleterious external attacks. Networking these
vehicles for greater control and safety exposes them to the possibility of external
interference in the form of hackers and malicious software. If such an integrated system is going to be generating, sending
and receiving a constantly active and live data stream to and from each
vehicle, a means must be found to
secure that data. (See below)
VI.
Lack
of Complete System-wide Integration: Such systems must have complete control of the car’s actuator
systems, including acceleration and braking systems, electrical systems, and
communication (for the B.E.A.C.O.N.
system, see below.) Ideally, and until autonomous cars can become truly self-operating and independent,
the car’s systems will still need to provide quick ‘surrender and release’
access to an onboard experienced human owner
or responsible passenger, even to the point of immediately surrendering
control to the owner or responsible passenger when necessary or on command.
VII.
Imposing
a Radically New Technology on a Non-technological Thoroughfare: Autonomous
or semi-intelligent vehicles (with primitive low-resolution camera-based vision
systems) on a non-technologically enhanced roadway are a huge disaster waiting
to happen. Instead, each autonomous car that accesses the road should be
enrolled immediately and automatically in an overseeing Control Grid and traffic flow
regulating system, e.g.,
intelligent roadways. Such a system would be designed to regulate traffic and
to control the number of autonomous cars on the road at all times. (Traffic
density control (or the number of cars allowed on a specific stretch of roadway
at a given time) could be achieved with a feeder tollgate or I-PASS system.) This
enrollment will assist in regulating vehicular density, and hence, the optimal
speed at which each car can travel to maintain its own virtual separation or ‘safety buffer’ zone by
limiting the number of vehicles to reasonable levels. (The aeronautical term for this zone is called a ‘separation’ area.)
This zone around each vehicle will maintain a safe distance between all cars
traveling at a certain or known speed in
known traffic conditions. (A ‘virtual safe’ zone is virtual in that it is
dictated not so much by the actual space available to each car, but rather by
the distance said car can safely
travel at a certain, regulated speed from
any other car, given the status of
current or existing traffic conditions, and the level of congestion.) As this
virtual safety ‘bubble’ decreases (due to increased traffic congestion) then
the operating speed of the vehicle is also decreased, to avoid sudden
collisions, much as planes operate.
VIII.
Unregistered,
untracked Semi-Autonomous Vehicles: Again,
self-driving cars must be identified
as such, as they are potentially dangerous, and even lethal. Therefore, each
car that enters onto the road (the Control Grid) for autonomous driving should
immediately be issued a one-time only registration designation of some type so
its movements while on the grid can be tracked, controlled, and regulated. This
identification system can be IPV6 based, and should be issued anew each time a
vehicle operates autonomously or in self-driving mode. A new address would be
issued new each time as a way to identify the details of that particular trip,
including date of trip, length, route, and trip particulars, such as incidents,
accidents, and traffic issues. In other words, the IP address is for the trip,
not the vehicle. (IP addresses used in
this fashion could be recycled if date and time and/or other uniquely
identifying data are added to them for each trip.) One look at the address should immediately identify the device as a
moving vehicle of some type. If following this system, then each vehicle would
have two IP addresses: a traditional one for the command module, (the phone
device), and a proprietary one for the vehicle itself. Such a system would
immediately log the time and place when the vehicle and its command module, (and
presumably the owner), are physically separated from each other.)
IX.
Unregulated
Semi-Autonomous Vehicles: Autonomous (self-driving) cars (and any system designed to accommodate them)
have to predetermine and enforce the safest
traffic speed for any situation dictated by the number of cars on the road,
traffic congestion, the weather, road construction, accidents as they occur, no
matter what the cause, such as natural ground-based phenomenon, weather, or
human error. The allowable speed should increase or decrease as situations
warrant.
X.
Lack
of Pre-designated Roadways for Emergency Manual Operation: Eventually,
when driverless cars have grown in number, and use, there will need to be some
method of accommodating these driverless cars if they were to stop suddenly, or
breakdown in traffic. At that time, unregulated roadways (or side/service
roads/shoulders) should be designated for emergency vehicles, or for cars,
whose passengers have emergencies. Such instances would allow those vehicles to
merge into the emergency lanes, where they can wait for help or towing (or
airlifting) without blocking traffic.
XI.
Lack
of Pre-Designated, Strictly Regulated Roads for Autonomous Vehicles: As
of this writing, there are no pre-designated roads for self-driving
(autonomous) cars, and there needs to be, for all the previously stated
reasons, mainly that they constitute potential hazards to life and property. In
designing the system, decisions will need to be made about which roads will be
adapted to become part of the Control Grid (suitable for
autonomous/self-driving cars as described above), and which roads will not. Those
not part of the Control Grid will not allow self-driving cars to operate in
that mode (on ‘non-intelligent’ roads that are not part of the Control Grid). Those
vehicles will be manually driven, or risk being taken off the road. In other
words, no self-driving car will be allowed to operate in that mode on a normal
road, where a suddenly glitch can damage, cause harm, or even kill.
XII.
Weaponized
Vehicles: Vehicles, by their very nature, are dangerous, lethal
weapons, especially in congested urban and metropolitan areas with large,
thoroughfares where pedestrian and vehicular traffic are in close proximity to
one another. Such settings make it all too simple a matter to turn any vehicle
into a deadly weapon launched against the unsuspecting masses. Technology will
not immediately eradicate such occurrences, but systems (such as the one
described in this document) can go a long way towards preventing them. Intelligent,
autonomous vehicles which can be controlled remotely (in extreme emergencies),
intelligent, and barricaded roadways
with the ability to immediately disable any vehicle (both electronically and with brute force) that tries to
cross its barriers and plow into pedestrian traffic, are all possible with this
system. The day and age of (carelessly?) intermingled human and vehicle traffic
in large cities and urban areas has now, by necessity, passed.
The Solutions
Networked Vision Systems:
Instead of just relying on locally based vision systems, as
human beings do, the vision systems for autonomous cars should be based on an
internalized network (local to the vehicle), which combines localized visual,
GPS and cell tower triangulation, along with heat, sound, and other proximity
based monitoring systems. Such a network would give a much more comprehensive
view than one merely based on human-mimicking localized vision, and fully
leverage readily available technologies for keeping passengers safe. Of course,
this visual data should also be collected and stored (in the ‘gray boxes’) and uploaded
to the control system for later review, if and whenever needed. (See section on gray boxes.)
Redundant Control Systems:
Each vehicle should be equipped with double or triple
redundant control modules that can operate the car’s guidance, stopping, and
acceleration systems (individually or in tandem). Each subsystem should be able
to do the job alone (in case two of the three modules become damaged or
incapacitated) or as part of a localized network. If part of such a network,
the modules would have to agree on the best course of action in an accident, impending accident or traffic situation,
or, if the owner and/or passengers in the car are either incapacitated or
unable to make decisions. In addition, these decisions, locally made
(in-vehicle, and not across a network that can experience lag) would, of
course, be made much, much faster than a human driver, (possibly incapacitated
or under great duress), ever could.
Controlled Environments
& ‘Intelligent’ Roads: These new, ‘semi-intelligent’ and
autonomous cars will eventually have to
have equally intelligent roadways, thoroughfares on which ‘non-intelligent’
vehicles will, at some point, not even be allowed. Such roadways will allow for
much better traffic spacing and control. By allowing virtual safe zones around
each vehicle (again determined and computed by speed and flow of traffic in a
given area), the system would mitigate or serious decrease in the number of
unforeseen events and accidents to which human drivers are prone, especially
when driving within close proximity to each other in crowded lanes under
stop-and-go traffic conditions.
Proximity Sensor Arrays:
As previously mentioned under the heading of Network Vision Systems (see
above), autonomous or self-driving cars need much more than ‘just’ vision
systems based on mimicked human sight built around (cheap?) low-resolution
cameras, cameras as easily fooled (in some situations) as the human eye. Again,
autonomous cars should exceed the
abilities of human drivers, enhancing and improving the best of their (human)
abilities, not merely duplicating them.
Other Redundant Systems:
These autonomous cars should be built with safety through
redundancy (and relative simplicity) in mind. Examples of such system backups are triply or
doubly redundant navigation systems (see
above) redundant sensor arrays for light, heat proximity, and sound, access
to GPS and triangulated smartphone data for mapping both ‘A to B’ driving, and
for avoiding unanticipated obstacles in the road, or unexpected events that
create roadblocks or traffic stops. For the near future, (until the technology
and its supporting systems are much more
mature and well developed) there should still be a licensed driver in the car
ready to take command of the vehicle in case of systemic failure. In addition,
there should be specially modified training for teaching ‘future drivers’ how
best to operate and commandeer and self-driving vehicle in an emergency.
Communications &
Support Systems (Live Control Towers and Operators)
Ideally,
such a network of augmented roads and semi-intelligent autonomous cars should
have a support system of traffic controllers and traffic flow moderators, be
they human-based (similar to air traffic controllers) or automated, monitored
systems. This support system would regulate, among other things, the virtual
safety zone allotted to each car (again, that zone based on the status of
traffic and the number of cars on the road), traffic speed, number of cars
allowed on the road, and the routing of traffic, especially during road
construction delays, or accidents. Eventually, the support system delineated in
these pages should be well suited to handle flying vehicles also.
‘Gray Box’ Data Collection
System: Each vehicle should be outfitted with a data collection and
storage system, similar to the ‘black box’ used by airlines. This box will
collect and store data from all onboard systems, along with route data, vehicle
condition and status, miles traveled, most recent tune-up or hardware
adjustments, repairs, odometer, Speedometer, and even available fuel and fuel
type. The most pertinent data (trip details) will be constantly sent to the Control
Grid centers, while other ‘less important’ data will be stored locally in the
gray boxes until needed. The information stored on these devices will be of utmost
importance during incidents where fatalities, damage to property, or other catastrophes
occur, and blame or culpability needs to be assessed and apportioned out. Tampering
with the box or its digitally stored information would incur penalties and
fines up to and including greater culpability on the drivers’ part, especially
attempts to hide or destroy crucial evidence prior to or during criminal
investigations. Consequences can include (significantly) increased fines, imprisonment,
especially in cases of willful neglect (with deadly consequences), or criminal
activities. The content of the gray box, in other words, does not belong to the owner.
Data Predictive Systems:
The Control Grid will collect data from cars, roads, GPS and
other monitoring devices (such as traffic copters and police data), and use it
to make predictions about (possible) traffic conditions, current and future,
such as predicting congestion, bottlenecks, and accidents. This data will be constantly
updated and presented to drivers and vehicles as another means to monitor road
and traffic conditions as a live traffic report, outside of the range of normal human vision and traffic situational
awareness. Most importantly, it will ALSO know when and which cars are being
manually operated.
Emergency Recovery
Systems: The goal of such a system built around self-driving
vehicles is to reduce, ultimately, the occurrence of accidents and fatalities;
however, such events will still occur. When they do, the system must be
prepared to act quickly to rectify such incidents with as little downtime as
possible. Achieving this goal would include emergency towing, airlifting, and
medical services, traffic rerouting and detouring, and the removal of wreckage
and human casualties. This system, of course, would be self-acting, not
requiring notification from an external source (such as waiting for someone to
report such an accident.) Being, in effect, ‘self-monitoring’, the road system
would know when an accident had occurred, and set in motion a series of events,
which would dispatch emergency services to the area immediately. If there were
a ‘live’ (as in fully staffed) control system, that crew would have instant access
to the site from the various sources already mentioned, and from local police
and emergency service providers. (Data sources such as onsite video, GPS and
Google Maps data, and satellite data showing where traffic had congealed and or
stopped.) Moreover, of course, a live data stream of ‘non-moving vehicles
massed around a central point’ from the users’ own smart devices would greatly
augment and enhance those other data sources. (Abrupt stops between two or more vehicles on a heavily traveled
roadway would be a definite red flag.)
Aerial Assistance
& Rescue: Besides typical ground deployed
municipal services (such as fire, rescue, ambulance, and law enforcement),
there should also be teams of fully staffed helicopter-based EVAC and rescue
personnel at specified intervals along the Control Grid (intelligent roads). These
teams would have the capacity to remove injured passengers and incapacitated vehicles from the road, airlift them to the
nearest hospital, or (in the case of vehicles) remove them to the nearest
off-road holding area where they can no longer impede traffic.
Traffic Control, Congestion
and Modification: In addition to the impressive data
sensor arrays onboard each autonomous vehicle, (and the regulating and
monitoring technology built into and along the roads themselves), these systems
will be augmented by the previously mentioned Control Centers, one each for
each major road or system of roads, or predetermined zones (Control Grids). These
Traffic Control Centers should be networked across several traffic zones
between cities, counties, and even states (for the monitoring of interstate
traffic patterns during heavy traffic). Such a system of networked Control
Centers would be able to anticipate and even predict traffic situations,
accidents, road blockages (such as during road construction and repair). With
this knowledge, traffic flow and speed could be increased or decreased,
re-routed, or halted as need be. The data collected would be much like the
information used to predict weather patterns.
Stand-alone Technologies:
Each vehicle will have two operating systems or modes: a stand-alone system
that can act in an independent mode, and another complimentary system, which would
be part of the larger, external Traffic Control System network. The stand-alone
system, like an ever-watchful co-pilot, would monitor traffic in a
predetermined area around the vehicle (in miles or city blocks), along with
weather, accident and emergency stoppages, and emergency or service stop areas
(such gas stations, hospitals, and so forth.) There should be at least two
system redundancies, or as many as three. Each redundant system would have its
own, separate access to the same data stream from the Control Grid system, in
case the data stream for one of the systems is somehow being corrupted or
misinterpreted, due to that subsystem’s hardware, which may have failed due to
possible damage.
Security: IoT
security technologies will have to be developed to ensure the system integrity
from external attack, including commandeering attempts from hackers, virus and
malware attacks, hijacking, or other types of system invasions, which would
compromise the safety of the vehicle. These systems should also employ a dual
or triple redundancy system, which would act quickly and decisively if a sudden
change in system operation is detected, up to either halting the vehicle,
steering it off road (to a previously designated safety area) or disengaging completely
from the Traffic Control System. (Alternatively, the vehicle’s operating system
could be rebooted ‘live’, while the vehicle is in use, defaulting to a
rudimentary driver-assisted system, or ‘safe mode’.)
Safe Driving Mode: In
the (hopefully unlikely event) of a system-wide failure of more than a
pre-defined percentage of control systems and redundancies, including all the
vehicle’s onboard systems, (intelligent) road malfunctions, or total loss of
communication or tower control, a ‘Safe driving mode’ will be evoked. Those
safe driving mode protocols (either system-wide for all vehicles in a given
area) or for just certain vehicles will remain in effect until normal
communication is restored. Safe driving mode protocol does several things. It
immediately maneuvers the single vehicles out of fast moving traffic, or
decreases driving speeds for multiple vehicles. It alerts the owner or
responsible passenger(s) if the Control Grid is impaired, switches vehicles to (assisted)
manual steering mode, and uses GPS to guide the owner or responsible passenger
to the nearest ‘pit stop’, service or gas stop, or other facility for further
assistance.
If
no further help is required, the vehicles are returned to the Control Grid when
possible. (Note: This ‘safe mode’ could even help a non-driver in guiding a
car short distances to either an off-road location, or an emergency services
provider, such as a hospital, service station, police station, or someone who
can provide emergency assistance. One of the possible ways to achieve this feat
is via an augmented reality visor which would guide the non-driver in
maneuvering the vehicle to safety, while also using the driver’s eyes and ears
as additional inputs to the digital data stream coming from the sensors and the
visor itself. If not completely damaged, secondary, emergency steering assist actuators
could help the temporary driver operate the incapacitated vehicle.)
Full Car Systems Integration:
The command cradle will integrate the car’s systems with
the command device (Android, or other phone device). While inserted, the phone
device will constantly communicate with the car’s systems directly via USB,
Thunderbolt, or other means (Wi-Fi, Bluetooth, cellular) when removed from the
command cradle. The command device will also act as a monitoring device when
removed, reporting on such system metrics as tire pressure and integrity (no
flats or air leaks), remaining fuel, battery potency, location (where the car
is parked), theft attempts, and if the car is being/has been tampered with,
moved, towed, or stolen.
The Command Cradle: The
command cradle and the phone device that rests in it (running the B.E.A.C.O.N.
application) is the heart of each vehicles onboard control and navigation
system. It connects the owner or responsible passenger and vehicle to the Control
Grid and communications towers. It also tracks the vehicle’s position on the
road, its speed, health status, trip destination, ETA, time since departure,
and other details, including available fuel, and major car sub-systems
condition, such as transmission, breaks, and electronics ‘under the hood’. The command
cradle (with the device running the B.E.A.C.O.N. app) can also be removed from
the vehicle and taken with the owner or responsible passenger, making it a ‘highly
capable’ remote control. The owner or responsible passenger can then stay in
touch with the vehicle, and always know its whereabouts and condition. It can
even be used to summon the vehicle to the owner’s location for pickup. Finally,
the vehicle itself will be able to run many of the same applications from the
hardware within its own ‘gray box’, which never
leaves the vehicle while it is still in use. The gray box and the device
(usually a smartphone) running the B.E.A.C.O.N. work in tandem and with the Control Grid to monitor and
control the vehicle both on the road, and while parked.
The Control Grid: The
centerpiece of the Traffic Control System will be the Control Grid, consisting
of a human-monitored array of localized systems, which will monitor traffic
conditions in a given area using a wide array of networked mapping and GPS
technologies. This ‘grid’ system, integrated with the systems of other areas
(cities, counties, states), will monitor traffic congestion and use this data
to regulate traffic speed and flow, and emergency, municipal vehicle status and
road repair, re-directing traffic as needed. The Grid is live, constantly
updated, and available to each command device while it is in the command cradle
of each vehicle. (Reminder: Each ‘Control Grid’ consists of the road in question, the
corresponding Control and Monitoring towers, the rescue, EVAC and aerial teams,
and the software that coordinates them all.)
Driving Plan: For
trips over a certain, pre-determined distance, vehicles will have to submit to
a ‘pre-flight’ driving plan (similar to a float plan), which would map various
available routes (based on distance, speed, traffic conditions between ‘A and
B’), and other variables. This report could be submitted at any time up to
starting the vehicle. Maximum and minimum speeds will then be determined,
either enforced, or non-enforced, depending on conditions. For local trips, during
certain high traffic holidays, and to areas known to have congested traffic
(like shopping or recreation areas) submitting a driving plan would result in
receiving a report detailing the status of traffic for the destination being
driven to, and suggestions for alternate routes. In case of emergencies, these
suggested routes will be enforced.
Emergency Roads/Lanes:
Predetermined emergency or shoulder roads will be designated
for emergency and municipal vehicles. The vehicles on these roads could default
to manual operating mode. They can also be commandeered by the Traffic Control
System when necessary.
Vehicle Designations: A
standard designation will be assigned to each vehicle upon sale: Federal, Emergency (including Police
and Medical), Municipal, Commercial,
and Private. Each ‘class’ of vehicle
would have certain default privileges and road rights, which would predefine
allowed and expected behavior (mostly) during times of emergency.
The Technologies
Enhanced GPS-Based Systems
(For constant, live data stream updates on all car positions
on all roads at all times, individually and as part of the wider network of
moving vehicles.)
The
previously described system of traffic controllers would use enhanced GPS-based
systems, cell tower triangulation, and other pertinent satellite data, along
with on-site high-speed drone-mounted cameras to access traffic data. (Networked, drone-based traffic cams need
not be in constantly in the air; they can be launched as needed from nearby
traffic signage, lights or other stationary objects, and returned to the nest
when they are no longer needed. The nest can also serve as a charging and data
uploading/downloading station.) More importantly live data feeds from the
control systems (computers and other smart devices, such as phones, and the
road itself) and from every car active on a given Control Grid (road) would
provide an important source of data for monitoring and controlling traffic
flow.
Live Road Data: This
data can be collected from the actual road surface and its surrounding network
of sensors and detectors:
a. A
sub-surface mesh, plate, system, or embedded device(s), (either continuous or
spaced at predetermined intervals) to measure total vehicle weight and the distance
between them
b. A
laser or infra-red based network beams placed strategically along the sides off
the road to count and identify vehicle type, size, traveling speed and distance
between cars
c. FLIR/Infra-red
night vision cameras
d. Wider-spaced,
high-speed UHF RFID readers for being able to pinpoint the exact location of
municipal vehicles (and larger vehicles, such as trucks carrying goods) at all
times
e. An
array of heat, light and sound detectors also regularly spaced
f.
Specially designed or retro-fitted data
cellular towers controlling predetermined miles along Control Grid roads
(overhead)
g. High-speed
Wi-Fi access points also on those data (cellular) towers.
h. Indicator
lights embedded in the surface showing the overall speed of traffic using
standard traffic light colors for fast (green), slow (yellow), and not moving
ahead (red). The speed of the pulsing of these lights would coincide (roughly)
with how traffic is moving. (Visual data for the manual/emergency driver or
vehicle owner or responsible passenger, actually numeric data for their
devices, and the Control towers)
i.
A revolutionary (and for now
theoretical) new technology that infuses a ‘swarm’ of magnetic or pressurized
sensors (such as tiny beads, coils, or springs) within the road itself, which
would then be able to gauge traffic flow and weight directly from the pressure
of vehicular traffic passing over the road’s surface. A swarm of these tiny embedded devices would cover a particular road,
while a hive would describe a
particular network of such devices. These sensors would be electro-magnetically
charged in such a way, which when re-polarized by shock, sound, or pressure,
would reflect traffic flow, direction, weight, frequency (per vehicle or group
of vehicles), and congestion. The devices could also be (only) pressure
sensitive, with changes in pressure used to indicate traffic condition. This
data could then be pooled or used with all the other data types being
collected.
Note: All
the data streamed from these roads, combined with the data from individual
vehicles, and when required, air support teams, make up a crucial part of the
overall Control Grid. The various data streams are intentionally redundant and
should coincide (approximately) with each other, with small variations in
percentages, given the different speeds at which datum are collected and reported
from their various subsystems. Vehicular data would be stored in the previously mentioned ‘gray boxes’
in the car itself. These devices would be heavily armored and protected against
tampering, destruction, altering, or vandalism, including from the owner
or any other unauthorized mechanics, technicians, or hackers.
Vehicular Data: Each
vehicle on the road will generate and store its own live, constantly updated
data stream, including:
e. Side-panel
beam reflectors, for interfacing with various data-generating road devices (See Live
Road Data above.)
h. Driver
data from either the vehicle operator or the command module
j.
‘Smart’ tires that can detect the
condition of the road (slippery, snow, rocky/pebbly, sticky), and read data devices transmitting
devices embedded in the road (see k.)
k. Magnetically
charged or pressure-sensitive devices (tiny beads, coils, or springs) embedded
within the asphalt itself, called swarms.
(See above.)
Note: All
data generated or collected by these devices will be store in the gray boxes,
which include a non-removable massive storage device, redundant network
devices, processors, and external device communication ports (USB). Also
included is a digital recorder for storing voice communication between the
car’s driver/owner/occupants and the control towers.
Cell Tower Based Systems:
For tracking cars from cell to cell, to supplement the GPS data and intelligent
road information.
Redundant and Decentralized
Driving Modes: Each vehicle, despite type or
designation, can operate in a few modes:
a.) Centralized
(logged in to the Traffic Control System)
b.) Decentralized
(operating independent of the system)
c.) Redundant,
the standard mode, which runs two or more ‘operating systems’, each used as a
system of checks and balances for the other as a precaution against system
hijacking.
d.) Disabled
(mechanical or systems failure)
e.) Stopped
(non-moving, cause unknown)
f.) Off-grid
(whereabouts of vehicle unknown, or total failure of all redundancies for that
vehicle)
g.) Safe-Mode
Assisted Driving for non-drivers, and incapacitated drivers, and incapacitated
systems, either onboard the vehicle, or failed communication links with the
control tower/grid
The
operating status (or mode) of a vehicle should always visible (on-screen) to
the owner or responsible passenger and the control tower(s). Because this data
is constantly updated, the last status before a connection is lost should appear on systems, the vehicle
and the control system.
Alternative Vision Systems: Instead
of only relying on one type of vision system, self-driving cars should have
access to several vision systems working in tandem, such as specially designed traffic satellites, LIDAR systems for
detecting objects in proximity, along with heat
proximity detectors and Sonar &
Echo location. This type of redundancy would severely reduce the chance
that a vehicle moving at high speed will miss or be blind to an object just
because of its color or the angle at which it passes in front of the car.
Currently Available Technologies
Infrared/FLIR
Worst Case Scenario:
When Autonomous Cars Kill
The
first notion that should be banished immediately is that an autonomous,
computer controlled car would react like a human in a crisis. Actually, it
should not, it should react much, MUCH faster, and with more data on hand. (In
addition, it would not be burdened by any dilemma of trying to decide whose
life is more valuable. It would also not react in panic or fear.)
Second,
it would default to the current (legal) precedent, which states that, in
most cases
the pedestrian has the right-of-way, just in case a fatality is inevitable, but
first...
...the
computer-controlled vehicle would try VERY hard to save both lives, if
possible, BUT AGAIN default to the previous clause, when necessary. (That first
clause being, that in
most instances,
the pedestrian has the right-of-way.)
First,
the car's systems would have been scanning in a predetermined radius around the
vehicle hundreds of times a second, constantly accessing and assessing raw data
on everything happening around the car for at least thirty meters (about a
hundred feet) from its own onboard systems.
It
would scan in all the spectra available to it looking for, among other things life
forms, (human or other) and unseen, immovable obstacles, and manually operated
vehicles, like bicycles, strollers, and carts.
Finding
such, it would immediately calculate speed, weather and road conditions, time
of day/night, and other data to determine the best action to save both parties.
(This process all happens in computer time: much faster than a human could
react, especially in a similarly stressful situation). The computer should not
EVER be surprised by anything 'popping up' in the middle of the road; it is not
human, after all. If something unexpected does happen, the system would be
programmed to react much faster and better than a human driver ever could.)
Detecting
a potential obstacle, it would also immediately assess the status of traffic around
the car, and search for the best reaction to save owner and pedestrian, OR avoid
the unseen deer, or boulder.
Having
consulted all the sensors and the data at its command, it would veer, slow, stop,
dive into a ditch (it knows the terrain around the car at all times), or,
failing that, plow the car into the overpass. That act would save the
pedestrian. The system would simultaneously launch life-saving maneuvers in the
car (such as airbags) to cause as little damage as possible to its occupants. It
would also summon emergency services, transmitting full details on the
incident, and any pertinent information about possible victims’ pre-existing
medical conditions.
All
this would be achieved much quicker than a human ever could, without fumbling,
fear, or panic.
Why
have computer-controlled cars that can ONLY act human in a crisis?
Legal Implications, Ramifications, and Responsibilities
Who
is legally culpable when a self-driving vehicle maims, kills someone, or
destroys property?
As we advance further into the new
technological age of autonomous, semi-intelligent (and, one presumes,
intelligent devices), new legal responsibilities and ramifications must be
addressed, but with no set legal precedent before them on which to base any laws
or judgments in an unforeseen (and, statistically speaking, eventually
unavoidable) tragedy, including loss of property or life.
Who or what agency is legally responsible when
an autonomous device maims, kills, or destroys? Who is responsible for legal
damages or punishments, or other liabilities? Who goes to court or is to be
sued for damages when a lawsuit is pending?
These important and even dire questions must
be addressed now as autonomous vehicles are being designed, manufactured and
deployed in greater and greater numbers.
Who is responsible if a self-driving car takes
a life or the ability to pursue a livelihood?
Although there are no set legal precedents,
there are similar examples (such as airbags failing to deploy), which may serve
as a template and a guide to codify a set of laws to address these issues.
Conclusion: Finally, all the involved parties: the vehicle owner (or
operator), the car manufacturer and the software and autonomous system
builders must share some percentage
of the blame when cars kill or destroy property. Determining that percentage
(per guilty party) would most likely vary from case to case, depending on the
circumstances of the incident. Was it a software failure? Could the human owner
or responsible passenger have intervened? Did the car’s hardware systems fail
somehow? Did the supporting systems (described in this document) fail somehow,
or was it a combination of all these things? Was it an ‘act of God’, such as
weather interference, earthquake, or hurricane, or even, electro-magnetic
pulse, or some other type of technological interference? New technologies call
for new legal precedents, and new procedures, which can no longer draw solely
on past cases, judgments, and rulings for deciding guilt or paying damages. Selling,
buying, and operating autonomous equipment must come with a legally
binding contract, which specifically delineates future apportionment of blame when
the need arises.
B.E.A.C.O.N.
(Stands for Broadcasting Emergency/Alert Communications, Orientation & Notification)
Automatic communication
and notification app for Android & iPhone user
The B.E.A.C.O.N. App
addresses a few issues that all smartphone and iPhone users are constantly
plagued with, sudden loss of power, which leads to sudden loss of the ability
to communicate with friends, family and loved ones. In an emergency, this can
be extremely stressful and potentially dangerous and cause undue worry,
especially where teens and minors are concerned, or people with medical
conditions. It can also cause significant problems for anyone who may be
waiting for someone (such as a school-aged child or other type of dependent) to
arrive at a set time and place, then suddenly losing contact with that person
with no way of knowing what, if anything, may have occurred or happened to
them. (This can be particularly worrisome to parents or other
caregivers, or even spouses.)
The app has other features
which, when activated, and automatically pinpoint the user’s location, and make
it possible for him or her to quickly find emergency services or local
landmarks, such as fire, police, or post office. It can also be automatically
activated during a personal medical emergency (like Life Alert or any such
service) to automatically call family, friends, caregivers, or doctors with
vital information detailing the medical condition, location, and data on the
type of occurrence (automatically recorded sound and/or video.)
B.E.A.C.O.N. The app will
come in a free and a paid version. (The free version is to get users to try
the app and help debug and develop it by using it and providing feedback data (via
a data recording feature built into the app). Free users also provide valuable
verbal feedback on Google Play and Apple iTunes stores and their user feedback
forums, where they rate the app provide valuable feedback on its features,
shortcomings, and features they would like to see. The free version also is
invaluable in ‘spreading the word’ about the app in general, helping to build
the customer base for the commercial version of the app. The money from the commercial
version provides funds for further development of the app and of course the
company and its owners. The commercial version is the only one that can be used
in-vehicle as a Command Module in the command cradle. The free version does not
include this functionality.)
1. The
app can send a warning text to pre-determined list of numbers to alert
recipient when owner’s phone battery is low, and about die. (Recipient will
then know not to try to contact, or worry needlessly.)
2. B.E.A.C.O.N. can
send a regularly pulsed beacon containing info such as current GPS
location, and battery percentage to predetermined numbers. (This beacon can
be set with a warning notification to the user, giving the option of canceling
it at any time.)
3. B.E.A.C.O.N. can
supply an alternative number that can be used to reach owner in the case of
emergency if the battery has died. This number can be a landline (house or work
phone) or an alternative smartphone.
4. In
an accident (violent jarring or manual notification from the owner)
the beacon can be used to send a pre-recorded message to emergency
services and family members automatically, providing GPS location data, and any
pre-recorded info about existing medical conditions.)
5. The “I’m
Lost” feature will immediately locate and identify nearby
prominent landmarks that can be of assistance, such as police and fire
stations, post offices, and gas stations, and send a notification to pre-determined
number.
The app will
need to access Contacts & default texting apps, Wi-Fi and phone functions,
and GPS and battery status. It will also need to be
able to make calls and send texts.
The free version
will not include access to all the features. Which will be active in commercial
version and not active in the free version can be determined at a later stage
of the app’s development.
Note: the B.E.A.C.O.N. app is part of a larger system of control for autonomous
or self-driving cars and vehicles, which is simultaneously being submitted to
DARPA’s Information Innovation Office (I2O). I am the creator of both systems.
