Handling faults in autonomous vehicles

Abstract

The control system of an autonomous vehicle includes an A-Kit module that runs the autonomous logic and generates a desired trajectory from sensor data. A B-Kit module receives the desired trajectory and generates inputs for actuators, such as steering, braking, and throttle actuators, based on the desired trajectory. A safing logic (which may be located in the A-Kit, the B-Kit, both the A-Kit and the B-Kit, or elsewhere within or outside the vehicle) receives sensor fault indications and executes contingency trajectories, such as safing maneuvers, to bring the vehicle to a safe state.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to co-pending U.S. patent application Ser. No. 63 / 318,444, filed Mar. 10, 2022, and entitled "Handling Faults in Autonomous Vehicles," the entire contents of which are hereby incorporated by reference.

[0002] This patent application relates to fail-safe systems for autonomous vehicles, and more particularly to performing safing maneuvers, such as following a safe trajectory, in response to detecting a fault. [Background technology]

[0003] Autonomous vehicles typically include a variety of cameras, LiDAR, and other sensors to monitor nearby conditions such as lane markings, roadside objects, and the location of nearby objects such as other vehicles. A controller contains the autonomous logic that processes the data received from these sensors and determines inputs for the throttle, braking, and / or steering actuators that control the operation of the vehicle.

[0004] However, these sensors may become faulty or even fail. The fault or failure may be due to operating conditions, tampering, physical damage, component failure, lost connections, and other reasons. The loss of one or more sensors may impede the ability of the autonomous vehicle to operate properly. Summary of the Invention [Means for solving the problem]

[0005] What is needed is a way to safely control an autonomous vehicle when data from sensors is lost, corrupted, or otherwise reduced in quality.

[0006] In one embodiment, the vehicle's control system includes an A-kit module that runs autonomous logic and generates a desired trajectory from sensor data. A B-kit module receives the desired trajectory and generates inputs for actuators, such as steering, braking, and throttle actuators, based on the desired trajectory. A safing logic (which may be located in the A-kit, the B-kit, both the A-kit and the B-kit, or elsewhere within or outside the vehicle) receives sensor fault indications and executes a safing maneuver to bring the vehicle to a safe state.

[0007] In some aspects, the techniques described herein relate to an apparatus or method for controlling an autonomous vehicle including an A-Kit module that receives sensor data and operates autonomous logic to generate a desired trajectory and a contingency trajectory that defines a safing maneuver; a B-Kit module that receives the desired trajectory and generates corresponding inputs for steering, braking, and / or throttle actuators of the vehicle based on the desired trajectory; and safing logic configured to receive sensor fault indications and the contingency trajectory, and configured to implement a safing maneuver and operate corresponding inputs for steering, braking, and other throttle actuators to bring the vehicle to a safing state.

[0008] In some aspects, the A-kit transmits a contingency trajectory to a B-kit module, which executes the safing logic and implements the contingency trajectory.

[0009] In some aspects, the B-Kit module receives secondary sensor data and operates a reduced level of autonomy logic within the safing logic to implement the safing maneuver.

[0010] In some aspects, the secondary sensor data is received from OEM sensors accessed via a Controller Area Network (CAN) bus on the vehicle.

[0011] In some aspects, the safing logic receives commands for a safing maneuver received from a companion vehicle via a wireless V2V link.

[0012] In some aspects, the commands are provided by autonomous logic within the companion vehicle.

[0013] In some aspects, the commands are provided by a human located within the companion vehicle.

[0014] In some aspects, the safing maneuver results in the vehicle being stopped on the side of the road or the vehicle following a companion vehicle.

[0015] In some aspects, the drone is activated in response to the fault indication, receives or generates drone sensor data, operates autonomous logic, generates an emergency response trajectory, and automatically transfers the emergency response trajectory via a wireless link to the safing logic, which receives the emergency response trajectory from the drone via the wireless link, executes the emergency response trajectory, and performs the safing maneuver.

[0016] In some aspects, the contingency response trajectory is generated on the B-Kit module based on sensor data received from the drone.

[0017] In some aspects, the fault is one or more of a sensor fault, an autonomous logic fault, or an interface fault that results in a failure to continually generate a desired trajectory within a certain time interval. [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 is a block diagram of the components of an autonomous vehicle.

[0019] [Diagram 2] FIG. 2 illustrates one scenario for handling a fault.

[0020] [Diagram 3] FIG. 3 is an embodiment in which the B-Kit module receives information from a secondary sensor.

[0021] [Figure 4] FIG. 4 is an embodiment in which the B-Kit module receives commands for a safing maneuver from a companion vehicle.

[0022] [Diagram 5] FIG. 5 illustrates another embodiment in which the drone is carried on a vehicle or a companion vehicle.

[0023] [Figure 6] 6A-6D illustrate a use case in which detection of a fault on a following vehicle causes a change in the behavior of the lead vehicle.

[0024] [Figure 7] 7A-7C are further examples of safing maneuvers.

[0025] [Figure 8] 8A-8C are yet another safety maneuver. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Detailed Description As shown more particularly in FIG. 1, a vehicle can be driven either by autonomous logic 10 or by a human driver 42 .

[0027] A human driver 42 provides input to the system controller 70 via typical human input devices 40, such as a throttle pedal (TH), a brake pedal (BR), and a steering wheel (ST). It should be understood that the reference to a "throttle" herein does not imply that the vehicle must be powered by an internal combustion engine. The vehicle may be propelled by an electric motor or other alternatives to fossil fuels.

[0028] The human driver 42 can also view the display 50 and activate other inputs 75 .

[0029] The autonomous logic 10 receives inputs from sensors 15, such as one or more cameras, LiDAR, radar, position sensors, and / or receives data from other sources via communication links 62 and other inputs. The autonomous logic typically includes perception logic that determines from such sensor data that one or more current conditions exist and then executes autonomous planning side logic to generate one or more trajectories in response to those detected current conditions. Autonomous logic, such as that described in U.S. Patent Publication No. US2022 / 0198936A1, entitled "Shared Control for Vehicles Travelling in Formation," or in U.S. Patent Publication No. US20210129843A1, entitled "Behaviors That Reduce Demand on Autonomous Follower Vehicles," each of which is hereby incorporated by reference, may be implemented in many other ways.

[0030] The autonomous logic 10 produces autonomous control signals 101 , 102 , which may include a desired trajectory for the vehicle, so that corresponding throttle, braking, and steering signals can be generated by the controller 70 .

[0031] The autonomous logic 10 may be part of an A-Kit module 20 .

[0032] The A-Kit module 20 is responsible for generating instructions that describe the plan for the vehicle, such as the path to follow. The A-Kit module also provides a ready signal RDY once the autonomy logic 10 determines that it has enough information to devise and approve a trajectory for the vehicle to drive autonomously. The A-Kit 20 may also exchange data with a companion vehicle or command center or an aerial drone via communications 62, such as a vehicle-to-vehicle (V2V) link.

[0033] The B-kit module 30 receives inputs such as commands from the autonomy logic 10 in the form of trajectories 101, 102 (including one or more trajectories to follow) from the A-kit and generates autonomous control signals 32 (including, for example, throttle (TH), brake (BR), and steering (ST) control signals) to the controller 70. The B-kit 30 may also exchange data with a companion vehicle or command center or an airborne drone via a wireless interface 63 such as a V2V link. The B-kit 30 may also generate a ready (RDY) signal to report to the controller 70 whether it is operating properly.

[0034] It should be understood that the A-Kit 20 and B-Kit 30 modules are preferably independent of one another. For example, a fault in the A-Kit 20 electronics or control programming should at least be recoverable by the B-Kit 30 to enable the vehicle to reach a safe state.

[0035] The controller 70 receives both the human control inputs 40 from the human driver 42 and the autonomous control inputs 32 (TH, BR, ST) from the B-kit module 30 and selects a set of control inputs to apply. The selection may use the RDY signals from the A-kit 20 and B-kit 30 to determine if those components are operating properly. The controller 70 feeds at least selected ones of the throttle control inputs to a pulse width modulated (PWM) repeater (not shown). The repeater may select the inputs that are fed to the vehicle's electronic control unit (ECU) 80. The steering and braking inputs may be controlled via a controller area network (CAN) bus.

[0036] The ECU 80 generates electronic control signals that are used by one or more actuators 90, which may include vehicle throttle 91, braking 92, and steering 93 actuators, which in turn operate the physical throttle, braking, and steering subsystems on the vehicle. In some implementations, the ECU may not control one or more of the actuators, such as steering 93.

[0037] The controller 70 may also receive inputs from the actuators 90 indicating their current status.

[0038] In some implementations, the controller 70 may provide a visual or audio alert output to the output device 50. The output device may include a speaker and electronics that may play indicator lights and / or pre-recorded audio messages to the human driver 42.

[0039] The controller 70 may also receive data from the human 42, such as via a microphone or other input device 75, such as a keyboard.

[0040] Fault handling scenarios 2 illustrates one scenario for handling faults, where the A-kit module 20 receives sensor data 15 and operates the autonomous logic 10 to continuously generate a desired trajectory 101 that should be executed in the normal state of the vehicle, such as when no faults are present. The desired trajectory 101 is then continuously transmitted to the B-kit 30. The desired trajectory 101 may continually change based on the current status of the vehicle. For example, the desired trajectory may change based on the desired route, or the presence of objects in the vicinity of the vehicle, such as road markings, roadside objects, and other vehicles, as well as traffic conditions, weather, ambient conditions, and the like.

[0041] B-Kit module 30 receives desired trajectory 101 and generates "steering" in the form of inputs to steering, braking, and / or throttle actuators 90 based on desired trajectory 101. In some cases, autonomous control signals 32 may be passed from B-Kit to controller 70 and / or directly to ECU 80 before causing the control signals to be input to actuators 90.

[0042] Here, the A-kit 20 may also be involved in detecting one or more fault conditions. Such faults may include failures detected by one of the sensors 15 or within one or more of the sensors 15 themselves. However, these faults may also be detected within other components, such as within the autonomous logic 10 itself, or within other processors, or within other components of the A-kit 20.

[0043] In some circumstances, the A-kit module 20 also continuously transmits one or more contingency trajectories 102 to the B-kit 30. The contingency trajectories 102 are typically also generated continuously based on current conditions by the governing logic or other portions of the autonomous logic 10. A given contingency trajectory 102 is executed by the B-kit module to perform a safing maneuver in response to a particular fault or faults.

[0044] A safe maneuver, as defined by an emergency response trajectory, may include stopping the vehicle, pulling over to the side of the road, exiting an exit, changing the vehicle's speed or position relative to another vehicle, or some other maneuver that brings the vehicle to a known safe state.

[0045] 3 is another environment in which, in addition to receiving trajectories 101 and 102 from the A-kit 20, the B-kit 30 also receives information directly from secondary sensors 105. These secondary sensors may include OEM sensors that are accessible via the vehicle's Controller Area Network (CAN) bus. The B-kit module 30 may use these additional sensor inputs 105 to further determine how or when to execute either the normal desired trajectory 101 or the emergency response trajectory 102.

[0046] 4, the B-Kit module 30 may receive an emergency response trajectory 102 (or some other command that constitutes a safing maneuver) from a companion vehicle, such as via its V2V link 63. The B-Kit module may also include an additional controller 72 focused on processing such emergency response trajectories, such as when the autonomous logic 10 fails, or on processing emergency response trajectories received from a companion vehicle.

[0047] In yet another scenario, the safing maneuvers 102 may be provided by a human located in the companion vehicle. For example, braking, throttle, and steering inputs may be provided via the V2V link to directly control the vehicle's actuators in an emergency situation.

[0048] 5 illustrates another embodiment in which a drone 150 is carried on the vehicle or on a companion vehicle to assist in generating emergency response trajectories and / or executing safing maneuvers. The drone 150 may be activated in response to detection of a fault and programmed to hover in the vicinity of the faulted vehicle. The drone 150 may carry sensors 154 and generate its own sensor data or it may receive sensor data from the companion vehicle. It may automatically forward such sensor data to the A-Kit for processing by the autonomous logic 1.

[0049] In some aspects, the techniques described herein relate to an apparatus for controlling an autonomous vehicle including an A-Kit module that receives sensor data and operates autonomous logic to generate a desired trajectory and a contingency trajectory that defines a safing maneuver; a B-Kit module that receives the desired trajectory and generates corresponding inputs for steering, braking, and / or throttle actuators of the vehicle based on the desired trajectory; and safing logic configured to receive sensor fault indications and the contingency trajectory, and configured to implement a safing maneuver, operate corresponding inputs for the steering, braking, and other throttle actuators, and bring the vehicle to a safing state.

[0050] In some aspects, the techniques described herein relate to an apparatus, where an A-kit transmits a contingency trajectory to a B-kit module, and the B-kit module executes safing logic and implements the contingency trajectory.

[0051] In some aspects, the techniques described herein relate to an apparatus, where a B-Kit module receives secondary sensor data and operates a reduced level of autonomy logic within the safing logic to perform a safing maneuver.

[0052] In some aspects, the techniques described herein relate to an apparatus, where secondary sensor data is received from an OEM sensor accessed via a Controller Area Network (CAN) bus on a vehicle.

[0053] In some aspects, the techniques described herein relate to an apparatus, where safing logic receives commands for a safing maneuver from a companion vehicle via a wireless V2V link.

[0054] In some aspects, the techniques described herein relate to an apparatus where commands are provided by autonomous logic within a companion vehicle.

[0055] In some aspects, the techniques described herein relate to an apparatus where commands are provided by a human located in a companion vehicle.

[0056] In some aspects, the techniques described herein relate to an apparatus where a safing maneuver results in the vehicle being stopped on the side of the road or the vehicle following a companion vehicle.

[0057] In some aspects, the techniques described herein relate to an apparatus, the apparatus further including a drone initially carried on a vehicle or companion vehicle, activated in response to a fault indication, receiving drone sensor data, operating autonomous logic, generating an emergency response trajectory, and automatically transferring the emergency response trajectory to a safing logic via a wireless link, the safing logic receiving the emergency response trajectory from the drone via the wireless link, executing the emergency response trajectory, and implementing the safing maneuver.

[0058] In some aspects, the techniques described herein relate to an apparatus, where an emergency response trajectory is generated on a B-Kit module based on sensor data received from a drone.

[0059] In some aspects, the techniques described herein relate to an apparatus where the fault is one or more of a sensor fault, an autonomous logic fault, or an interface fault that results in an inability to continually generate a desired trajectory within a time interval, or even assist in generating an emergency response trajectory 102.

[0060] In some embodiments, the drone 150 may itself include autonomous logic 152. The autonomous logic 152 in the drone 150 may generate the emergency response trajectory 102 and automatically transfer it to the B-Kit 30, such as via wireless link 63. The B-Kit module 30 may receive this emergency response trajectory 102 from the drone and execute the resulting safing maneuver.

[0061] The contingency trajectory may also involve generating a safing maneuver for the companion vehicle. For example, a fault may occur in only one of a pair of vehicles traveling in a convoy. However, the contingency trajectory should involve generating a safing maneuver such that both vehicles reach the safe stage.

[0062] The table below lists several examples of safety maneuvers, corresponding system functions, and a description of each. [Table 1-1] [Table 1-2]

[0063] Use case for vehicles moving in formation 6A-6D illustrate a use case for the system 100 described above, where two vehicles are traveling in a lined formation, such as a convoy. Detection of a fault on a following vehicle F (such as by the A-kit 20) causes a change in the trajectory, e.g., a change in the behavior of another vehicle, such as a leading vehicle L. As shown in FIG. 6A, the convoy or other vehicle lined formation is composed of a leading vehicle L and a following vehicle F. At this point, the convoy is operating normally, with each vehicle traveling at a speed of 55 miles per hour. In this example, the following vehicle F is a robotic vehicle controlled by the autonomous logic 10 that is programmed to follow the leading vehicle L, which is driven by a human.

[0064] At some point as shown in Fig. 6B, a fault is detected in the follower F. The follower then executes a safing maneuver to slow down, such as by the A-kit 20 generating an emergency response trajectory 102, which is then executed by the B-kit 30. However, the leader L is not yet aware of the fault condition and therefore proceeds at 55 mph for a short period of time. Eventually, the leader L is notified of the fault, either by using its own sensors to detect the slowing follower F, or by the follower F sending a message to the leader L, in the form of control data transmitted via the wireless link 62 or 63.

[0065] In Figure 6C, discipline data transmitted over radio links 62 or 63 causes the leader L to also slow down and possibly reduce or increase the space between the vehicles. In Figure 6D, both the leader L and the follower F are now traveling at a lower speed with a space between them that depends on the fault condition.

[0066] Figures 7A-7F are further examples of safing maneuvers. In the initial state shown in Figure 7A, the leader L and follower F are traveling at 55 mph and the follower detects a fault. In the state shown in Figure 7B, the space between the vehicles is modulated such that the follower is now traveling closer to or farther from the leader.

[0067] FIG. 7C is another example of a response to a fault where a safing maneuver now causes the vehicle to proceed at a slower speed, for example 45 mph.

[0068] 8A is an example where the following side F has stopped in its lane as a result of executing a safing maneuver. The leading side L continues its journey.

[0069] FIG. 8B is an example embodiment in which a fault is detected by follower F and reported to lead L, and a safing maneuver is performed for both vehicles to exit through a nearby exit.

[0070] FIG. 8C is an example where, after a fault, the follower F is controlled by commands received wirelessly via links 62 or 63 from the command center 700 instead of using its own autonomous logic 10. The command center may run its own autonomous logic or may be controlled by a human. It may be possible for a visual sensor (camera or LiDAR) on the follower F to be transmitted to the command center 700 via wireless links 62 or 63. In another case where there is a visual sensor failure on the follower F, a visual sensor on the lead L or a companion vehicle such as the drone 150 may be automatically forwarded to the command center to assist in controlling the follower F.

[0071] Other Scenarios The autonomous logic on the vehicle with the failed sensor may suggest or limit the movement of the companion vehicle. In one example, after detecting the fault, the following vehicle F may request the companion vehicle L to accelerate if the fault is associated with a condition that may prevent the following vehicle F from being able to stop quickly or safely. In another example, the portion of the autonomous logic involved in emergency response planning in the leading vehicle L may command the autonomous logic in the leading vehicle L to slow down or accelerate as soon as possible, i.e., well before the human driver in the leading vehicle would notice or react to the fault.

[0072] Additionally, "safing data" may include something other than trajectories, etc. in which case the B-kit has sufficient intelligence to process the safing data and derive a safing maneuver on its own. In one embodiment, the safing data may simply include the positions and speeds of all nearby traffic.

[0073] Drone sensor data (e.g., “safing data”) may be replaced or augmented by vehicle-to-vehicle data received from third party vehicles or from vehicle-to-infrastructure (VTI) data available from transportation infrastructure.

[0074] The safing data may also originate from the companion vehicle. In one embodiment, this can be a video feed from a rear-facing camera on the leading side that is automatically forwarded to the failed following side via a V2V link.

[0075] The fault detection logic may be located in any or all of the A-kit (A), B-kit (B), controller (C), or ECU (E), or human (H). Thus, generally speaking, the emergency response trajectory may also be located in or generated by any of the A-kit 20, B-kit 30, controller 70, ECU 80, or human 42.

[0076] The "commands" executed in response to a fault may include generating control data. The autonomous logic involved in performing a safing maneuver may also reside in any of the A-Kit 20, B-Kit 30, Controller 70, ECU 80, or human 42 in the companion vehicle.

[0077] The safing action can occur in many places, including the vehicle with the malfunction, a companion vehicle, or a flying drone, or a command center. In any of these cases, autonomous logic or a human can be the source that initiates the safing maneuver.

[0078] A safing action may simply be the execution of an emergency response action, however, a safing action may also involve other streams of data coming from anywhere, such as remote action from a command center, another vehicle, or a drone.

[0079] The sequence of events may be as follows: 1. Emergency response actions are continuously generated by autonomous logic within the A kit. 2. Fault detection logic in the A kit detects a fault. Notification of this event is broadcast to B kits etc. in the same vehicle or companion vehicles. 3. The fault response logic receives the broadcasted notification and, in response, determines and initiates an emergency response trajectory. 4. A response may include multiple actions in multiple locations. For example, a response may be to reconfigure an asset (such as to launch a drone) or activate a control device (such as a joystick on a lead side), redirect or modify control and / or data streams (such as generating video from a drone) (such as via emergency response autonomous commands). 5. The response may be performed over a long period of time, i.e., at least the time it takes to move the following party F off the road and to a safe location, such as on the shoulder or to the next exit road.

[0080] Further implementation options It should be understood that the exemplary embodiments described above can be implemented in many different ways. In some instances, the various "data processors" and / or "logic" can be implemented by a physical or virtual general-purpose computing device having a central processor, memory, disks or other mass storage devices, communication interfaces, input / output (I / O) devices, and other peripheral devices. A general-purpose computer can be transformed into a processor and execute the processes and methods described above, for example, by loading software instructions into the processor and then causing the execution of the instructions to perform the functions described.

[0081] As is known in the art, such a computer may contain a system bus, where a bus is a set of hardware lines used for data transfer between components of a computer or processing system. A bus or buses is essentially a shared conduit connecting different elements of a computer system (e.g., one or more central processing units, disks, various memories, input / output ports, network ports, etc.) that enable the transfer of information between the elements. One or more central processing units are attached to the system bus and provide for the execution of computer instructions. Also attached to the system bus are typically I / O device interfaces for connecting disks, memories, and various input / output devices. A network interface allows for connection to various other devices attached to a network. One or more memories provide volatile and / or non-volatile storage for computer software instructions and data used to implement an embodiment. A disk or other mass storage device provides non-volatile storage for computer software instructions and data used, for example, to implement various procedures described herein.

[0082] Embodiments may therefore typically be implemented in hardware, custom designed semiconductor logic, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), firmware, software, or any combination thereof.

[0083] In an embodiment, the procedures, devices, and processes described herein are computer program products that include a computer-readable medium (e.g., one or more removable storage media, such as DVD-ROMs, CD-ROMs, diskettes, tapes, etc.) that provide at least a portion of the software instructions for the system. Such computer program products can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions can also be downloaded via a cable, communication, and / or wireless connection.

[0084] The embodiments may also be implemented as instructions stored on a non-transitory machine-readable medium that may be read and executed by one or more procedures. A non-transitory machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a non-transitory machine-readable medium may include storage media, including read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and others.

[0085] Furthermore, firmware, software, routines, or instructions may be described herein as performing certain actions and / or functions, however, it should be understood that such descriptions contained herein are for convenience only and that such actions actually result from a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, etc.

[0086] It should also be understood that the block and system diagrams may contain more or fewer elements, be arranged differently, or be represented differently, but it should also be understood that certain implementations may require block and network diagrams, and that some block and network diagrams illustrating the execution of embodiments may be implemented in a particular way.

[0087] Thus, further embodiments may also be implemented in various computer architectures, physical, virtual, cloud computers, and / or some combination thereof, and thus the computer systems described herein are intended for illustrative purposes only and not as limitations of the embodiments.

[0088] The foregoing description particularly illustrates and describes exemplary embodiments. However, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the legal scope of the present patent as encompassed by the appended claims.

Claims

1. 1. An apparatus for controlling an autonomous vehicle, comprising: an A-Kit module that receives sensor data and runs autonomous logic to generate a desired trajectory and a contingency trajectory that defines a safing maneuver; a B-kit module that receives the desired trajectory and generates corresponding inputs for steering, braking, and / or throttle actuators of the vehicle based on the desired trajectory; a safing logic configured to receive a sensor fault indication and the emergency response trajectory, and configured to implement the safing maneuver and operate corresponding inputs for the steering, braking, and other throttle actuators to bring the vehicle into a safe state; and An apparatus comprising:

2. the A-kit transmits the contingency trajectory to the B-kit module; the B-Kit module executes the safing logic and implements the emergency response trajectory; 2. The apparatus of claim 1.

3. 2. The apparatus of claim 1, wherein the B-Kit module receives secondary sensor data and operates a reduced level of autonomy logic within the safing logic to implement the safing maneuver.

4. The apparatus of claim 3 , wherein the secondary sensor data is received from an OEM sensor accessed via a Controller Area Network (CAN) bus on the vehicle.

5. 2. The apparatus of claim 1, wherein the safing logic receives commands for the safing maneuver received from a companion vehicle via a wireless V2V link.

6. The apparatus of claim 5 , wherein the command is provided by autonomous logic within the companion vehicle.

7. The apparatus of claim 5 , wherein the command is provided by a human located within the companion vehicle.

8. The apparatus of claim 1 , wherein the safing maneuver results in the vehicle being stopped on the side of the road or the vehicle following a companion vehicle.

9. a drone, the drone being initially carried on the vehicle or a companion vehicle, activated in response to the fault indication, receiving drone sensor data, operating autonomous logic, generating an emergency response trajectory, and automatically transferring the emergency response trajectory to the safing logic via a wireless link; Further equipped with 2. The apparatus of claim 1, wherein the safing logic receives the contingency response trajectory from the drone via the wireless link, executes the contingency response trajectory, and performs the safing maneuver.

10. 10. The apparatus of claim 9, wherein the contingency trajectory is generated on the B-Kit module based on sensor data received from the drone.

11. 2. The apparatus of claim 1, wherein the fault is one or more of a sensor fault, an autonomous logic fault, or an interface fault that results in a failure to consistently generate a desired trajectory within a time interval.

Images