Plug-compatible interface between cars and their human and/or computer drivers

Abstract

A plug-compatible interface between a car and its human and/or computer driver makes both car and driver a black box, or abstraction, to the other. The two black boxes can then be developed and built independently before being integrated together only at the final stage. Designers on both the car and driver sides of the interface need design only to the interface and need not worry about how things are done on the other side of it. When cars and computer drivers are built to interact over a plug-compatible interface, any computer driver works with any car. If a computer driver becomes outdated, it can be updated or replaced much more quickly and cheaply than replacing the entire car.

Claims

1. A method of making a standard, physical plug-compatible interface between a car and a driver of the car, able to connect wired or wirelessly, to allow the driver to control the car by issuing electronic driving commands that include at least speed and direction commands, where the method includes at least the steps of: defining interface specifications of the wired or wireless physical connection between an electronic communication device of the car and an electronic communication device of the driver over which the driving commands can be sent, defining interface specifications of the format and content of the driving commands, hiding, other than the interface specifications, the implementation details of how functions are carried out within the car and the driver so the car and the driver can be loosely coupled, and making the interface specifications public.

2. The method of claim 1 where the driver of the car is a computer running a self-driving program.

Description

DETAILED EXAMPLES

(1) Here we provide examples of making a car and driver two black box abstractions loosely coupled through an interface. An interface is a connection across which energy, matter and/or information flow. An interface like this will usually have three parts: data, power, and a physical connection.

(2) The left side of FIG. 2 shows an integrated, tightly coupled CAR and DRIVER in the same black box. This is the prior art.

(3) The right side of FIG. 2 shows a modular, loosely coupled CAR and DRIVER in separate black boxes, joined by an INTERFACE. The examples of our invention look more like this.

(4) These separate black boxes for CAR and DRIVER show abstractions that allow details to be hidden, with an INTERFACE loosely coupling the two. Of course the two black boxes each need to perform their function, and that function needs to be well defined. But how they perform the function is not defined. The implementation is hidden.

(5) For the CAR, these things are hidden: Is it an electric car? Gasoline car? Two-wheel drive? Four-wheel drive?

(6) For the DRIVER, these things are hidden: Is the driver a human? A computer? A combination of human and computer? Is the driver in the CAR or driving it remotely?

(7) The INTERFACE between the CAR and DRIVER loosely couples the two together, providing just enough of a connection for each of them to perform its function well. The data provided across the INTERFACE needs to be sparse, but not too sparse, and adequate, but not copious. The better the balance struck between too little and too much, the better the INTERFACE works.

(8) Human drivers are (obviously) not integrated into the car, and almost all cars have a standard driver interface worldwide. A driver can get out and walk away at any time. Another driver can take his or her place and quickly drive away.

(9) By contrast, today's computer drivers are integrated, or built into the car, and all carmakers have a different driver interface. Replacing the computer driver with one of a completely different design would be like replacing the car's engine. It can be done, but it is not meant to be done.

(10) With a plug-compatible interface, computer drivers are almost as loosely coupled and un-integrated as human drivers. That makes computer drivers almost as easy to replace as human drivers.

(11) Here we will provide three detailed examples of how our invention works in: (1) a car with only a human driver, (2) a car with a human driver but some level of autonomy, and (3) a car with only a computer driver.

(12) The design of an interface has a lot to say about how much it helps. Information hiding describes how computer program interfaces enable modular programming by hiding the details of how the modules work. Users of modules need not understand the complexities inside the modulesthey are black boxes. Computer program interfaces are an important part of software architecture, as they are key to organizing any complex piece of software.

(13) Indeed, as noted in the discussion above, the computer industry has a long history of using interfaces between software modules (called application program interfaces or APIs). An interface between a car and driver looks a lot like those application program interfaces, so we draw on that history.

(14) Application program interfaces are different from user interfaces, like the graphical user interface (GUI) in the Windows operating system. A car/driver interface, like an application program interface, is between two machines, not between a human and a machine. With a car/driver interface, even if a human is driving the car the human needs to use a machine (like a steering wheel and a pedals connected to a microprocessor) as a user interface to create the commands sent across the interface.

(15) Computer scientists have developed some helpful principles to use to make good application program interfaces that work well over the long term. Making good interfaces of any kind can be difficult to do, and those principles may help those who want to implement our car/driver interface.

(16) Rather than describe those principles in detail, we will emphasize just one point. It is tempting to think that an interface should be as full-featured and complete as possible. But the reverse is usually true. An interface needs to be as simple as possible (but no simpler). That is, it should have what is needed but no more.

(17) By limiting the interface to its bare essentials, the benefits of having an interface can often be obtained without locking those who design to the interface into the same technology in the future as they have now. The balance can be hard to findjust how simple is too simple? For that reason, although we have disclosed quite simple interfaces as examples here, experience may tell us that we need to bulk up our interfaces a bit.

(18) In each of the examples the interfaces can be private, partner or public. These terms are largely self-explanatory, but are defined in our glossary above. While private and partner interfaces have some of the benefits of an interface outlined above, a public interface has all of them.

(19) But public interfaces also have some drawbacks to the developer of the interface. Competitors have a better chance to compete when an interface is public. And public interfaces are much harder to change than private or partner interfaces. They must be fairly stable to have much value, and that makes it hard for them to evolve as technology evolves.

(20) Implementation of the three types of interface is easy. Simply put, the specifications of a private interface are kept confidential within a company. The specifications of a partner interface are disclosed only to partners under a confidentiality agreement. The specifications of a public interface are published.

Example 1: Human Driver

(21) In this example, we have a human driver using a steering wheel for turning, paddles for braking and acceleration, and buttons for other functions. When the human driver uses these controls they generate signals that are converted by software we call a driver control unit (Driver.txt in our computer code listing) into commands.

(22) These commands are sent across an interface where they are converted by software we call a car operating system (Car.txt in our computer code listing) into control signals that are sent to the various car resources (motors, brakes, lights) that do what the driver wants done.

(23) The physical connection is an Anderson connector power plug and socket. Power provided by the CAR side of the interface is direct current at 12 Volts and up to 20 Amps.

(24) The data connection is serial communication through a wireless or wired network virtual socket. The data format for commands is given in FIGS. 9A and 9B. In this example, the data commands are for core and other driving-related resources (defined below). None are given for comfort resources (also defined below), which we leave to a separate interface not specified here but which is in principle the same.

(25) Core Resources: the traction motors, steering gear and brakes that change the direction and speed of the car.

(26) Other Driving-Related Resources: things like headlights, signal lights and windshield wipers that are related to driving but do not actually change the direction or speed of the car.

(27) Comfort Resources: things like entertainment, communication, heating and cooling, seat and mirror adjustments, and navigation devices that are not directly related to moving the car.

(28) In this example, driver commands go from DRIVER side to CAR side of the interface, but there are also status and other communications that go back from CAR side to DRIVER side.

(29) On the DRIVER side of the interface, a human driver will need to decide when to change the direction or speed of the car, or to take some other action. Once that decision is made, a human driver will need to give these commands somehow, like using the traditional interface of steering wheel and accelerator and brake pedals or using an untraditional interface like the ill-fated steering joystick used in the Saab Prometheus prototype car in the early 1990s.

(30) The wheel and pedals will need to be hooked up to, or include, a microprocessor running a program that will convert the analog inputs from the wheel and pedals into the commands to be sent across the interface. In this example, we have included a program called Driver.txt that can run on a Windows laptop that has plugged into one of its USB porta a SteelSeries Steering Wheel.

(31) This example uses a steering wheel/paddles combination used on computers with driving simulation programs. But many other things can be used to get driving commands from a human driver. The standard steering wheel and accelerator and brake pedals can be used, with their output being converted into driving commands rather than analog signals. As technology evolves, many other driver control units become possible.

(32) On the CAR side of the interface, the car will need to implement the commands received from the DRIVER side of the interface by changing those commands into control signals sent to the particular resources available on the car. In this example, we have included a program called Car.txt that can run on a Raspberry Pi that has hooked into its USB ports a Wi-Fi dongle and USB cables running to two Arduino Unos.

(33) On the CAR side of the interface, you can perform a right or left turn by steering the front wheels, steering the back wheels, torque vectoring, wheel by wheel braking, a combination of these things, or something else. You can do braking by friction brakes, engine braking, regenerative braking, a combination of these things, or something else.

(34) In this example, the program called Car.txt keeps track of all the car resources that are available and creates the proper signals to send to those resources to implement the driver's commands. How the Car.txt programa car operating systemworks is described in detail in Car Operating System, patent application Ser. No. 15/049,004.

Example 1A: Human Driver (Different Commands)

(35) In this example, a different data connection is made, and the command set is made much simpler. A USB male and female connector and an Anderson connector power plug and socket are the physical connections. The serial communication speed is 115,200 baud.

(36) The bare minimum for a human to drive a car is that the human give the car a direction and a speed. To do that, we have reduced the command set in FIG. 10 to the bare minimum. We have made the commands as short as possible since at 115,200 baud the speed is limited to a maximum of about 1,000 characters a second.

(37) Commands

(38) Speed up

(39) Slow down

(40) Turn right

(41) Turn left

(42) Forward or reverse

(43) Parking brake on or off

(44) Right turn signal on or off

(45) Left turn signal on or off

(46) Horn on or off

(47) On the CAR side of the interface the car will need to figure out what resources (like motors, steering, or brakes) will be needed to carry out the driver's commands in the real world. Some sort of closed loop system using feedback will probably work best. The program CAR.txt could be modified to conform to this interface.

Example 2: Human Driver with Some Automation

(48) In this example, we use the same power and data interfaces as in Example 1:

(49) The physical connection is an Anderson connector power plug and socket. Power provided by the CAR side of the interface is direct current at 12 Volts and up to 40 Amps.

(50) The data connection is serial communication through a wireless or wired network virtual socket. The data format for commands is given in FIG. 10.

(51) In this example, however, the commands that come from the DRIVER side of the interface are generated by a computer driver using self-driving technology. Self-driving technology typically produces the same kind of steering, throttle and brake commands as a human driver. But this can differ depending on what type of self-driving technology is offered.

(52) In this example, the human driver uses a steering wheel like the one described in Example 1 to control the car, but those control signals are used by software on the DRIVER side of the interface. The software compares the human driver control signals to those generated by the self-driving technology and decides which ones to process into commands to send over the interface. This is shown in part (b) of FIG. 6, and can be done by those skilled in the art.

(53) Alternatively, there can be two separate DRIVER sides of the interface, both connecting to the CAR side of the interface. The two separate streams of commands can then be reconciled on the CAR side of the interface to send the needed control signals to the resources available on the car. This is shown in part (a) of FIG. 6, and can be done by those skilled in the art.

(54) When a computer driver enters the picture, the simpler example in Example 1 needs to become a little more complicated. The commands and data can be differentmore abstractsince machines need not have the same interface as humans. It may be best to move to a more sparse command set than in Example 1, perhaps something like Example 1A, or even a simple vector showing direction and speed as in FIG. 7.

(55) The DRIVER side of the interface may also need to send warnings and the like to communicate between the self-driving technology and the human driver or other occupants of the car. That may include as well as things like sending a warning to prepare for a collision that the computer driver senses is imminent, so that the CAR side of the interface can do belt tensioning. Of course that kind of warning could be generated on the CAR side of the interface as well.

(56) The sensors that the computer driver needs also need to be provided for. There can be a lot of sensors. For example, in October 2016 Tesla Motors announced an upgrade of its Autopilot self-driving technology. All new cars were being built with eight cameras that provide 360-degree visibility at up to 820 feet of distance. Tesla cars previously had just one forward-looking camera, as well as a forward radar and 12 long-range ultrasonic sensors positioned to see 16 feet around the car in every direction.

(57) The new Tesla cars still come with just one radar sensor, but have enhanced processing to provide additional data about the car's surroundings. The radar can see through heavy rain, fog, dust, and even a car in front of it, according to Tesla. Tesla also said it updated the car's 12 ultrasonic sensors to improve the distance at which they can detect hard and soft objects from the previous 16 feet.

(58) Those sensors can be considered part of the DRIVER side of the interface or the CAR side. If the sensors are considered part of the DRIVER side of the interface, then the CAR side of the interface will need to provide places to mount the sensors and to run wires from the sensors to the computers that run the self-driving technology. If the sensors are considered part of the CAR side of the interface, then there will need to be another interface between the sensors and the DRIVER side of the interface to get the signals from those sensors.

(59) On the DRIVER side of the interface, the computer driver does not need to specify whether the speeding up or slowing down is done for adaptive cruise control, automated emergency braking, parallel parking assistance, or something else. The driver does not need to specify whether the turning right or left is for lane-keeping assistance, parallel parking assistance, or something else.

(60) When a human and computer driver together drive the car, they will need to work closely together. As noted above, that cooperation can be done on the CAR side of the interface or the DRIVER side. The interface implementation may change depending on the choice made, but the concept of an interface will not change.

(61) Care will need to be taken. It is easy for the human and computer drivers to work at cross purposes instead of collaboratively. The irony is that the more we automate, the more skilled and practiced the human drivers have to be.

(62) Why is that? Because driving is a very tricky activity. When we first learn to drive, driving seems overwhelmingly complex. But after a few months of driving, most activity becomes automated, done subconsciously without thought or mental effort. Soon most drivers become comfortable enough to drive at high speeds down crowded highways while talking, eating, daydreaming, or even worse.

(63) At that point, driving is easy. Except when it isn't, and that is when accidents occur. For any individual driver, the chance of an accident is low. For a nation, the number of accidents, injuries, and deaths is astoundingly high. Self-driving technology can help

(64) The danger lies when a computer driver takes over some of the driving tasks. If drivers daydream and do other tasks while driving now, imagine when the car has taken over much of the driving. When a computer driver can take over driving for minutes or even hours, no driver is going to be paying much attention. If there is a problem the computer driver cannot handle, the human driver is unlikely to be ready to take over.

(65) Moreover, when human drivers do little driving, their skills will atrophy. Although the law says that a human driver must take over when the computer driver fails, in reality they will be unable to. They will be out of the loop. Having computer drivers will reduce accidents and injuries. But when an accident does occur, it will probably be a big one.

(66) Solving the problem will take a lot of experience, a lot of research, and a lot of thought. And, unfortunately, a lot of death and disaster. The horse is a good metaphor for how a partially autonomous car would work. Like a horse which can be loosely guided when conditions are simple, a computer driver can easily take over mundane tasks. When the human driver needs to, however, he or she can tightly guide the horse. A good horse and rider make a great combination.

(67) Or perhaps we can take it even further. That is, let the human driver give high level guidance about where to go, how fast to go, and where to turn. But let the computer driver do the precise drivingsending control commands about how much and when to steer, brake, and accelerate. That way, until the computer driver can do everything, the human driver is always in the loop, always doing the high-level control.

(68) Eventually computer drivers may be good enough to take over completely, as in Example 3. But the path toward full self-driving must go through the dangerous stage of collaborative human/computer driving. Having an interface between CAR and DRIVER will help lessen the danger and speed up progress in self-driving technology.

(69) The main issue now is with partially autonomous cars, which present a very difficult issue since we need both human and computer drivers in every car. The point is that these issues have nothing to do with any particular car, but with all cars. It does not matter whether the car is gasoline or electric, or made by GM or Toyota. These issues can be handled for every type of car.

(70) Interactions between a driver and a car can become very complex as more functions are offered. The chance of conflict between the driver (particularly computer driver) and the car increase. Having an interface can reduce complexity.

(71) There will be many things to keep in mind as possibilities to handle through the interface specifications. But this can be done as the technology develops. For example, early on it will be important to think about how to handle lane-keeping, braking to avoid something in front, and other things that are already implemented by the car. They need not be done on the DRIVER side of the interface, and conflicts should probably be avoided.

(72) There are many different possibilities where humans and computers work together to drive the car. The Society of Automotive Engineers has a scale of 0 (human only) to 5 (computer only), with levels 1 to 4 increasing in the responsibility given to the computer driver. The interface handles all levels from 0 to 5, and there are different ways to configure the situation. In levels 1 to 4, for example, the human could be on either side of the interface.

(73) Alerts to the human driver can also be part of the interface, as well as control of other car accessories like lights and windshield wipers. As self-driving technology evolves, thought will need to be given on how to handle the increasing amount of options displayed to the driver using the dashboard, heads-up displays with augmented reality features, a central monitor or new curved displays, among others. Deciding what, when, where and how information is given to the driver or passengers is important. The interface can adapt to handle it all.

(74) On the CAR side of the interface, cars will have various devices to implement the commands coming from the DRIVER side of the interface. These will include, of course, devices that change car dynamics, like traction motors, brakes and steering. But they might also include communication and other devices that communicate with the outside world of a car. These may be indicators, like turn signals or caution lights. Or communication devices to send data to the cloud or from the car to infrastructure (V2X). Or assistance devices like belt tensioners or windshield wipers. All can be added, if desired, to the interface.

Example 3: Computer Driver

(75) This example is of full automation where no human is involved in driving the car. Of course a human will usually need to give the computer driver directions on where to go, but a computer will be driving the car and controlling its speed and direction from moment to moment.

(76) Surprisingly, the interface in the case of only a computer driver is the easiest to deal with. In this example, the interface is the same as in Example 1A above. The CAR side of the interface need not know that the DRIVER side is a computer rather than a human. That changes nothing as far as the CAR side of the interface is concerned.

(77) The self-driving technology will need to conform its output to command specification for the DRIVER side of the interface. It will then need to send those commands to the CAR side of the interface. The physical USB and Anderson connectors will also need to be provided by the self-driving technology provider as part of its system.

DRAWINGS

(78) FIG. 1 shows an example (humorous) of how both sides of an interface have to fit together just right to work.

(79) FIG. 2 compares an interface between car and driver with the prior art.

(80) FIG. 3 shows that a human driver and a computer driver can use the same plug-compatible interface.

(81) FIG. 4 shows a car and driver as black boxes loosely coupled together through an interface, where the driver can be a human, or computer, or both.

(82) FIG. 5 shows how a plug-compatible interface lets any driver be coupled with any car.

(83) FIG. 6 shows two ways(a) and (b)to combine human and computer drivers.

(84) FIG. 7 shows that a vectorwith car speed being the vector's magnitude and car direction being the vector's directiongives the minimum information needed to control a car.

(85) FIG. 8 shows an example of a physical interface between the car and driver.

(86) FIGS. 9A and 9B show one example of a data interface between the car and driver (for Examples 1 and 2).

(87) FIG. 10 shows a second example of the data interface between the car and driver (for Examples 1A and 3).

(88) FIG. 11 shows an example of a plug-compatible interface between a semi-trailer and tractor that consists of two air hoses, an electrical cable, and a fifth-wheel/kingpin combination. The industry-standard interface lets any tractor in North America couple with any semi-trailer, taking just minutes to hook up and drive away.