Decentralized Minimum Risk Condition Vehicle Control

Abstract

A vehicle computer includes a memory and a processor programmed to execute instructions stored in the memory. The instructions include: receiving a first minimum risk condition (MRC) event recommendation from a first platform controller and a second MRC event recommendation from a second platform controller; selecting one of the first and second MRC event recommendations as a selected MRC event; and controlling an autonomous host vehicle according to the selected MRC event.

Description

Technical Field

[0001] The present disclosure relates to the field of autonomous vehicles, and more particularly to the field of autonomous vehicle control. Background Art

[0002] The Society of Automotive Engineers (SAE) has defined several levels of autonomous vehicle operation. At Levels 0-2, a human driver monitors or controls most driving tasks, typically without assistance from the vehicle. For example, at Level 0 ("no automation"), the human driver is responsible for all vehicle operations. At Level 1 ("driver assistance"), the vehicle may sometimes assist with steering, acceleration, or braking, but the driver remains responsible for the vast majority of vehicle control. At Level 2 ("partial automation"), the vehicle can control steering, acceleration, and braking in certain situations without human intervention. At Levels 3-5, the vehicle assumes more driving-related tasks. At Level 3 ("conditional automation"), the vehicle can handle steering, acceleration, and braking in certain situations, as well as monitoring the driving environment. However, Level 3 requires occasional driver intervention. At Level 4 ("high automation"), the vehicle can handle the same tasks as Level 3 but does not rely on the driver to intervene in certain driving modes. At Level 5 ("full automation"), the vehicle can handle nearly all tasks without any driver intervention. Summary of the Invention

[0003] Fully autonomous vehicles, such as Level 5 autonomous vehicles, must be prepared to handle highly complex traffic situations without human intervention. Minimum Risk Condition (MRC) parameters define how an autonomous vehicle will respond to certain types of faults. That is, an autonomous vehicle can determine which minimum risk condition event to execute in response to a specific fault. A minimum risk condition event is an action taken by the autonomous vehicle. Examples of minimum risk condition events (in increasing order of severity) include doing nothing, pulling over to the side of the road at an ideal location, pulling over to the side of the road immediately, and letting the autonomous vehicle stop in its lane.

[0004] An example vehicle computer capable of performing decentralized MRC control includes a memory and a processor. The processor is programmed to execute instructions stored in the memory. The instructions include receiving a first minimum risk condition (MRC) event recommendation from a first platform controller and receiving a second MRC event recommendation from a second platform controller. The instructions also include selecting one of the first and second MRC event recommendations as a selected MRC event and controlling the autonomous host vehicle according to the selected MRC event.

[0005] In the vehicle computer, the processor may be programmed to receive the first and second MRC event recommendations due to the first and second platform controllers respectively detecting a vehicle system fault. The vehicle system fault detected by the first platform controller is different from the vehicle system fault detected by the second platform controller.

[0006] In the vehicle computer, the processor may be programmed to generate a third MRC event recommendation. In this case, selecting the selected MRC event includes selecting from among the first, second, and third MRC event recommendations. Furthermore, the processor may be programmed to generate the third MRC event recommendation due to the processor detecting a vehicle sensor failure.

[0007] In the vehicle computer, the processor may be programmed to control the autonomous host vehicle according to the selected MRC event by outputting a motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller. In this implementation, the processor may be programmed to receive the motion control signal from the autonomous vehicle controller and output the motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller.

[0008] In the vehicle computer, the processor can be programmed to select one of the first and second MRC event recommendations as the selected MRC event based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation. The severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different. In this implementation, the processor can be programmed to select the first MRC event recommendation as the selected MRC event if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation. The processor can be programmed to select the second MRC event recommendation as the selected MRC event if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation.

[0009] In the vehicle computer, the processor may be programmed to select a fourth MRC event recommendation based on an overall severity of the first and second MRC event recommendations, wherein the fourth MRC event recommendation is different from the first and second MRC event recommendations.

[0010] An example vehicle system implementing decentralized MRC control includes a first platform controller programmed to output a first MRC event recommendation and a second platform controller programmed to output a second MRC event recommendation. The vehicle system also includes a minimum risk condition (MRC) controller programmed to receive the first and second MRC event recommendations, select one of the first and second MRC event recommendations as a selected MRC event, and control an autonomous host vehicle according to the selected MRC event.

[0011] In the vehicle system, the MRC controller may be programmed to receive the first and second MRC event recommendations due to respective detections of system faults by the first and second platform controllers, the system fault detected by the first platform controller being different from the system fault detected by the second platform controller.

[0012] In the vehicle system, the MRC controller is programmed to generate a third MRC event recommendation due to the MRC controller detecting a vehicle sensor failure. Selecting the selected MRC event includes selecting from among the first, second, and third MRC event recommendations.

[0013] In the vehicle system, the MRC controller may be programmed to control the autonomous host vehicle according to a selected MRC event by outputting a motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller. In this embodiment, the MRC controller may be programmed to receive the motion control signal from the autonomous vehicle controller and output the motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller.

[0014] In the vehicle system, the MRC controller may be programmed to select one of the first and second MRC event recommendations as the selected MRC event based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation. The severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different. The MRC controller may be programmed to select the first MRC event recommendation as the selected MRC event if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation. The MRC controller may be programmed to select the second MRC event recommendation as the selected MRC event if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation.

[0015] A method for decentralized MRC control includes receiving a first minimum risk condition (MRC) event recommendation from a first platform controller, receiving a second MRC event recommendation from a second platform controller, selecting one of the first and second MRC event recommendations as a selected MRC event, and controlling an autonomous host vehicle according to the selected MRC event.

[0016] The method may further include generating a third MRC event recommendation, and wherein selecting the selected MRC event includes selecting from among the first, second, and third MRC event recommendations.

[0017] In the method, selecting one of the first and second MRC event recommendations as the selected MRC event can be based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation. The severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different, and if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation, the first MRC event recommendation is selected as the selected MRC event, and if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation, the second MRC event recommendation is selected as the selected MRC event. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 An example autonomous vehicle with decentralized minimum risk conditional vehicle control is shown.

[0019] Figure 2 is a block diagram illustrating an example implementation of decentralized minimum risk conditional vehicle control.

[0020] Figure 3 is a flow chart of an example process for decentralized minimum risk conditional vehicle control. DETAILED DESCRIPTION

[0021] The illustrated elements may take many different forms and include multiple and / or alternative components and facilities. The illustrated example components are not intended to be limiting. In practice, additional or alternative components and / or implementations may be used. Furthermore, unless expressly stated otherwise, the illustrated elements are not necessarily drawn to scale.

[0022] Figure 1 An autonomous host vehicle 100 with decentralized minimum risk condition (MRC) control is shown. Figure 1As shown, the host vehicle 100 includes a virtual driver system 105, an automated vehicle platform 110, and a minimum risk condition controller (also known as an MRC controller) 115. At least some portions of the virtual driver system 105 and the MRC controller 115 can be implemented by a vehicle computer. Although shown as a sedan, the host vehicle 100 can include any passenger vehicle or commercial vehicle, such as a car, truck, sport utility vehicle, crossover, van, minivan, taxi, bus, etc. The host vehicle 100 is an autonomous vehicle that can operate in an autonomous (e.g., unmanned) mode, a partially autonomous mode, and / or a non-autonomous mode.

[0023] The virtual driver system is a computing platform implemented through sensors 125, controllers, circuits, chips, and other electronic components that control various autonomous operations of the host vehicle 100. The virtual driver system 105 includes an autonomous vehicle controller 120 that is programmed to process data captured by the sensors 125, which may include lidar sensors, radar sensors, cameras, ultrasonic sensors, etc. The autonomous vehicle controller 120 is programmed to output control signals to components of the automated vehicle platform 110 to autonomously control the host vehicle 100 based on the data captured by the sensors 125.

[0024] The automated vehicle platform 110 refers to the components that perform autonomous vehicle operations according to instructions from the virtual driver system 105 (and specifically from the autonomous vehicle controller 120). As such, the automated vehicle platform 110 includes various actuators 135 (see FIG. 1 ) incorporated into the host vehicle 100. Figure 2 ), which control the steering, propulsion, and braking of the host vehicle 100. The automated vehicle platform 110 also includes various platform controllers 130 (sometimes referred to in the art as "modules") (see Figure 2 ), such as chassis controller, powertrain controller, body controller, electrical controller, etc.

[0025] The MRC controller 115 is implemented by being programmed to autonomously control circuits, chips, or other electronic components of the host vehicle 100 based on minimum risk condition events (hereinafter referred to as "MRC events"). An MRC event is an action taken by the host vehicle 100 due to a system failure. Examples of MRC events (in descending order of severity) include stopping the host vehicle 100 in its lane, immediately pulling over the host vehicle 100 to the side of the road, pulling over the host vehicle 100 to the side of the road in the near future (i.e., at an ideal location rather than immediately pulling over the host vehicle 100), or allowing the host vehicle 100 to continue to its destination. The MRC controller 115 is programmed to select an MRC event based on the type of system failure detected.

[0026] Selecting an MRC event involves the MRC controller 115 considering information received from one or more controllers included in the automated vehicle platform 110. Each controller of the automated vehicle platform 110 (e.g., chassis controller, powertrain controller, body controller, electrical controller, etc.) is programmed to detect faults in one or more vehicle systems associated with the corresponding controller. For example, the powertrain controller may be programmed to detect various engine or transmission faults. Each controller is programmed to recommend an MRC event based on the type of fault detected. For minor faults, the platform controller 130 may be programmed to recommend that the host vehicle 100 complete its mission. For more severe faults, the platform controller 130 may be programmed to recommend that the host vehicle 100 pull over to the side of the road at a desired location (such as a parking lot) or drive to a service station. For more severe faults, the platform controller 130 may be programmed to recommend that the host vehicle 100 immediately pull over to the side of the road, for example, on the shoulder of the road. For the most severe faults, the platform controller 130 may be programmed to recommend that the host vehicle 100 stop immediately, even if the host vehicle 100 is in the driving lane.

[0027] The MRC controller 115 is programmed to receive recommendations from each platform controller 130 in the host vehicle 100. The MRC controller 115 is also programmed to select MRC events based on the recommendations of the platform controllers 130. The MRC controller 115 can be programmed to select MRC events associated with the most serious vehicle system failure types. That is, upon receiving information indicating that the lighting system and the braking system have failed, the MRC controller 115 can be programmed to select a recommendation for an MRC event associated with a braking system failure. In some implementations, the MRC controller 115 can be programmed to provide its own recommendations for MRC events. For example, the MRC controller 115 can be programmed to detect failures associated with the virtual driver system 105, including failures associated with the sensors 125 included in the virtual driver system 105, failures of the autonomous vehicle controller 120, and the like. If the autonomous vehicle controller 120 fails to recommend an MRC event as expected, the failure of the autonomous vehicle controller 120 can be detected by the MRC controller 115.

[0028] When a fault is detected, the MRC controller 115 can be programmed to determine its own recommended MRC event, which it considers when considering the MRC events recommended by the platform controller 130. The MRC controller 115 is programmed to initiate the selected MRC event by commanding the autonomous vehicle controller 120 to autonomously operate the host vehicle 100 according to the selected MRC event. Even so, the MRC controller 115 can arbitrate between different MRC recommendations of the platform controller 130 and arbitrate against its own recommendations. In addition, by allowing the platform controller 130 to make MRC recommendations, the MRC implementation of the host vehicle 100 is "distributed" or "decentralized," which increases the robustness of the MRC implementation.

[0029] MRC controller 115 may be incorporated into autonomous vehicle controller 120 , may be a separate device (eg, a standalone controller operating external to autonomous vehicle controller 120 ), or incorporated into a different controller.

[0030] Figure 2 1 is a block diagram illustrating an example implementation of decentralized MRC control. Specifically, each platform controller 130 has its own MRC control logic, which the corresponding platform controller 130 executes to provide recommended MRC events to the MRC controller 115. Figure 2 In an implementation of the present invention, the MRC controller 115 is separate from the virtual driver system 105 and the automated vehicle platform 110. The MRC controller 115 receives MRC event recommendations from various platform controllers 130 of the automated vehicle platform 110, from the autonomous vehicle controller 120, or from a combination of the two. The MRC controller 115 processes these recommendations, selects one of the recommendations (or determines its own selected MRC event based on, for example, sensor data, the overall severity of the MRC event recommendations, etc.), and outputs motion control commands to the actuators 135 of the automated vehicle platform 110 to implement the selected MRC event. In some cases, the motion control commands can be generated by the virtual driver system 105 (e.g., by the autonomous vehicle controller 120) and output to the actuators 135 of the automated vehicle platform 110 directly from the autonomous vehicle controller 120 or via the MRC controller 115.

[0031] As shown, the MRC controller 115 includes (or can access) a memory 140 and a processor 145. The memory 140 is implemented by a circuit, a chip, or other electronic components and may include one or more of the following: a read-only memory (ROM), a random access memory (RAM), a flash memory, an electrically programmable memory (EPROM), an electrically programmable erasable memory (EEPROM), an embedded multimedia card (eMMC), a hard drive, or any volatile or non-volatile medium. The memory 140 can store instructions and data that can be executed by the processor 145 of the MRC controller 115, such as a table that associates various system faults with various MRC events and logic for arbitrating between different recommended MRC events. The instructions and data stored in the memory 140 can be accessible to the processor 145 and possibly other components of the host vehicle 100.

[0032] The processor 145 of the MRC controller 115 is implemented by circuits, chips, or other electronic components and may include one or more microcontrollers, one or more field programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more customer-specific integrated circuits, etc. The processor 145 is programmed to receive recommended MRC events and arbitrate between different recommended MRC events by selecting one of the recommended MRC events or possibly selecting different MRC events. For example, the processor 145 is programmed to receive a first MRC event recommendation output by one of the platform controllers 130 and a second MRC event recommendation output by another of the platform controllers 130. The processor 145 is programmed to select an MRC event from the first MRC event recommendation and the second MRC event recommendation by, for example, selecting the recommended MRC event associated with the most severe system fault.

[0033] Processor 145 may also be programmed to select a different MRC event, such as an MRC event that is more severe than the recommended MRC event, upon detecting a fault not represented by the recommended MRC event. In this case, processor 145 is programmed to detect faults that would not be detected by one of platform controllers 130 and generate, for example, a third MRC event recommendation due to the detection of these types of faults. Such faults detectable by MRC controller 115 may include, for example, a fault in one or more of sensors 125, a fault in autonomous vehicle controller 120, and the like. Processor 145 is programmed to select the third MRC event recommendation (i.e., an MRC event associated with the sensor 125 fault) if the sensor 125 fault is an MRC event that is more severe than the first and second MRC event recommendations. Processor 145 is programmed to look up MRC events associated with the sensor 125 fault in a table stored in memory 140.

[0034] Figure 3 is a flow chart of an example process 300 that may be implemented by one or more components of host vehicle 100 to implement decentralized MRC control. Process 300 may be initiated any time host vehicle 100 is operating in an autonomous or partially autonomous mode of operation.

[0035] At block 305, the MRC controller 115 receives an MRC event recommendation (e.g., the first and second MRC event recommendations discussed above) from each of the platform controllers 130. The MRC controller 115 may receive the MRC recommendations from each of the platform controllers 130 via a communication bus. Each platform controller 130 may generate an MRC event recommendation due to detection of a vehicle system fault by the platform controller 130. In some cases, even if no fault is detected, the platform controller 130 may recommend an MRC event that recommends that the host vehicle 100 complete its mission (i.e., continue to proceed to its destination). The MRC event recommendation may be associated with a specific system fault, such as in a table stored in the memory 140, and the platform controller 130 may recommend an MRC event by querying the table for an MRC event associated with the system fault and transmitting the recommended MRC event to the MRC controller 115.

[0036] At decision block 310, the MRC controller 115 determines whether it has detected any other system faults. That is, the MRC controller 115 searches for system faults that would not be detected by any of the platform controllers 130 but that could be detected by the MRC controller 115. For example, the MRC controller 115 may determine whether any of the sensors 125 have failed. If the MRC controller 115 determines that at least one sensor 125 has failed, or if there are any other unspecified system faults, the process 300 may proceed to block 315. If the MRC controller 115 determines that there are no other unspecified faults, the process 300 may proceed to block 320.

[0037] At block 315, the MRC controller 115 recommends an MRC event based on the fault detected at decision block 310. For example, if the MRC controller 115 identifies a sensor 125 fault or an autonomous vehicle controller 120 fault, the MRC controller 115 may generate an MRC event recommendation (e.g., a third MRC event recommendation) based on the sensor 125 fault. That is, the MRC event recommendation may be associated with a specific system fault, such as in a table stored in the memory 140. The MRC controller 115 may recommend an MRC event associated with the sensor 125 by querying the table.

[0038] At box 320, the MRC controller 115 selects one of the recommended MRC events. The recommended MRC events include those received at boxes 305 and 315, if applicable. Therefore, the recommended MRC events may include a first MRC event recommendation and a second MRC event recommendation. The MRC event recommendations may also include a third MRC event recommendation, and may also include other recommendations. In one possible approach, the MRC controller 115 may be programmed to select the MRC event associated with the most serious action to be taken by the host vehicle 100. In other words, each MRC event recommendation may be associated with a severity, and the MRC controller 115 may be programmed to select the MRC event recommendation with the highest severity. For example, if the first MRC event recommendation includes having the host vehicle 100 immediately pull over to the side of the road and the second MRC event recommendation includes having the vehicle stop in its lane, the MRC controller 115 may be programmed to select the second MRC event recommendation because it is the more serious action to be taken by the host vehicle 100. Alternatively or additionally, for example, the MRC controller 115 may be programmed to select a different MRC event (e.g., a fourth MRC event recommendation) at box 320 than the one recommended at boxes 305 and 315 if the overall severity of the recommended MRC events suggests that more severe action should be taken than the actions reflected by those recommended MRC events.

[0039] At block 325, the MRC controller 115 generates a motion control signal. The motion control signal may cause the automated vehicle platform 110 to autonomously operate the host vehicle 100 to perform the selected MRC event. In some cases, the MRC controller 115 may not generate the motion control signal. Instead, the motion control signal may be generated by the virtual driver system 105. In this case, the MRC controller 115 may transmit the selected MRC event to the virtual driver system 105, and the virtual driver system 105 may generate the motion control signal in response to receiving the selected MRC event.

[0040] At box 330, the MRC controller 115 outputs a motion control signal to control the host vehicle 100 according to the selected MRC event. The motion control signal can be output to one or more platform controllers 130, such as a powertrain controller and a chassis controller. The platform controller 130 that receives the motion control signal may not be the same platform controller 130 that is recommended by the MRC event ultimately selected at box 320. The platform controller 130 can start various actuators 135 to perform the selected MRC event owing to receiving the motion control signal. In addition, in some cases, whether the MRC controller 115 or the virtual driver system 105 generates the motion control signal at box 325, the MRC controller 115 can provide the motion control signal to one or more of the platform controllers 130. Alternatively or additionally, the virtual driver system 105 can provide some or all of the motion control signals directly to the appropriate platform controller 130.

[0041] In general, the computing systems and / or devices described may employ any of a number of computer operating systems, including but not limited to various versions or variations of the following operating systems: FORD Applications, APPLink / SmartDevice Link middleware, Microsoft Operating system, Microsoft Operating systems, UNIX operating systems (for example, those released by Oracle Corporation in Redwood Shores, California) operating systems), AIX UNIX operating system released by International Business Machines Corporation of Armonk, New York, Linux operating system, Mac OSX and iOS operating systems released by Apple Inc. of Cupertino, California, BlackBerry OS released by BlackBerry Ltd. of Waterloo, Canada, Android operating system developed by Google Inc. and the Open Handset Alliance, or provided by QNX Software Systems CAR Infotainment Platform. Examples of computing devices include, but are not limited to, an in-vehicle computer, a computer workstation, a server, a desktop computer, a notebook, a laptop computer, or a handheld computer, or some other computing system and / or device.

[0042] Computing devices generally include computer-executable instructions, in which case the instructions are executable by one or more computing devices (such as those listed above). Computer-executable instructions can be compiled or interpreted from computer programs created using a variety of programming languages ​​and / or technologies, including but not limited to Java, PHP, and PHP, alone or in combination. TM , C, C++, Visual Basic, JavaScript, Perl, etc. Some of these applications can be compiled and executed on a virtual machine, such as a Java virtual machine, a Dalvik virtual machine, etc. Typically, a processor (e.g., a microprocessor) receives instructions, such as from a memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. A variety of computer-readable media can be used to store and transmit such instructions and other data.

[0043] Computer-readable media (also referred to as processor-readable media) include any non-transient (e.g., tangible) medium that participates in providing data (e.g., instructions) that can be read by a computer (e.g., by a computer's processor). Such media can take many forms, including but not limited to non-volatile media and volatile media. Non-volatile media can include, for example, optical or magnetic disks and other permanent memories. Volatile media can include, for example, dynamic random access memory (DRAM), which typically constitutes main memory. Such instructions can be transmitted by one or more transmission media, including coaxial cables, copper wires, and optical fibers, including wires comprising a system bus connected to a computer processor. Common forms of computer-readable media include, for example, floppy disks, floppy disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tape, any other physical medium with a pattern of holes, RAM, PROMs, EPROMs, FLASH-EEPROMs, any other memory chips or cassettes, or any other medium from which a computer can read.

[0044] The databases, data warehouses, or other data storage devices described herein may include various mechanisms for storing, accessing, and retrieving various data, including hierarchical databases, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), and the like. Each such data storage device is typically included in a computing device that employs a computer operating system, such as one of those operating systems mentioned above, and is accessed over a network in any one or more of a variety of ways. The file system can be accessed from the computer operating system and may include files stored in a variety of formats. In addition to the language for creating, storing, editing, and executing stored procedures, an RDBMS typically uses a structured query language (SQL), such as the PL / SQL language mentioned above.

[0045] In some examples, system elements can be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.) and stored on associated computer-readable media (e.g., disks, memories, etc.). A computer program product can include instructions stored on a computer-readable medium, such instructions for performing the functions described herein.

[0046] With respect to the processes, systems, methods, heuristics, and the like described herein, it should be understood that although the steps of such processes, etc. have been described as occurring in a particular order, such processes can be implemented by performing the steps in an order different from that described herein. It should also be understood that certain steps can be performed simultaneously, other steps can be added, or certain steps described herein can be omitted. In other words, the descriptions of the processes herein are provided for the purpose of illustrating certain embodiments and should in no way be construed as limiting the claims.

[0047] Therefore, it should be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided will be apparent from reading the above description. The scope of protection should be determined with reference to the appended claims and the full scope of equivalents to which such claims are entitled, rather than with reference to the above description. It is anticipated and intended that future developments will occur in the technology discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In short, it should be understood that this application is capable of modification and variation.

[0048] All terms used in the claims are intended to be understood by those skilled in the art as having their ordinary meanings unless an explicit indication to the contrary is made herein. In particular, the use of singular articles such as "a," "an," "the," and the like should be understood to refer to one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

[0049] The Abstract is provided so that the reader can quickly ascertain the nature of the technical disclosure. It is understood that this Abstract will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the Detailed Description above, it can be seen that various features are grouped together in various embodiments in order to simplify the disclosure. This method of disclosure should not be interpreted as reflecting that the claimed embodiments require more features than are expressly recited in each claim. Rather, as reflected in the claims below, the inventive subject matter lies in fewer features than all the features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

[0050] According to the present invention, a vehicle computer is provided, the vehicle computer having: a memory; and a processor programmed to execute instructions stored in the memory, the instructions including: receiving a first minimum risk condition (MRC) event recommendation from a first platform controller and receiving a second MRC event recommendation from a second platform controller; selecting one of the first and second MRC event recommendations as a selected MRC event; and controlling an autonomous host vehicle according to the selected MRC event.

[0051] According to one embodiment, the processor is programmed to receive the first and second MRC event recommendations due to each of the first and second platform controllers detecting a vehicle system fault, wherein the vehicle system fault detected by the first platform controller is different from the vehicle system fault detected by the second platform controller.

[0052] According to one embodiment, the processor is programmed to generate a third MRC event recommendation, and wherein selecting the selected MRC event comprises selecting from among the first, second, and third MRC event recommendations.

[0053] According to one embodiment, the processor is programmed to generate the third MRC event recommendation due to the processor detecting a fault associated with a virtual driver system.

[0054] According to one embodiment, the processor is programmed to control the autonomous host vehicle according to the selected MRC event by outputting motion control signals to at least one of the first platform controller, the second platform controller, and a third platform controller.

[0055] According to one embodiment, the processor is programmed to receive the motion control signal from an autonomous vehicle controller and output the motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller.

[0056] According to one embodiment, the processor is programmed to select one of the first and second MRC event recommendations as the selected MRC event based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation, wherein the severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different.

[0057] According to one embodiment, the processor is programmed to select the first MRC event recommendation as the selected MRC event if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation, and wherein the processor is programmed to select the second MRC event recommendation as the selected MRC event if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation.

[0058] According to one embodiment, the processor is programmed to select a fourth MRC event recommendation based on an overall severity of the first MRC event recommendation and the second MRC event recommendation, wherein the fourth MRC event recommendation is different from the first MRC event recommendation and the second MRC event recommendation.

[0059] According to the present invention, a vehicle system is provided, comprising: a first platform controller programmed to output a first MRC event recommendation; a second platform controller programmed to output a second MRC event recommendation; and a minimum risk condition (MRC) controller programmed to receive the first and second MRC event recommendations, select one of the first and second MRC event recommendations as a selected MRC event, and control an autonomous host vehicle according to the selected MRC event.

[0060] According to one embodiment, the MRC controller is programmed to receive the first and second MRC event recommendations due to respective detections of system faults by the first and second platform controllers, wherein the system fault detected by the first platform controller is different from the system fault detected by the second platform controller.

[0061] According to one embodiment, the MRC controller is programmed to generate a third MRC event recommendation due to the MRC controller detecting a vehicle sensor failure, and wherein selecting the selected MRC event includes selecting from among the first, second, and third MRC event recommendations.

[0062] According to one embodiment, the MRC controller is programmed to control the autonomous host vehicle according to selected MRC events by outputting motion control signals to at least one of the first platform controller, the second platform controller, and a third platform controller.

[0063] According to one embodiment, the MRC controller is programmed to receive the motion control signal from an autonomous vehicle controller and output the motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller.

[0064] According to one embodiment, the MRC controller is programmed to select one of the first and second MRC event recommendations as the selected MRC event based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation, wherein the severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different.

[0065] According to one embodiment, the MRC controller is programmed to select the first MRC event recommendation as the selected MRC event if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation.

[0066] According to one embodiment, the MRC controller is programmed to select the second MRC event recommendation as the selected MRC event if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation.

[0067] According to the present invention, a method includes: receiving a first minimum risk condition (MRC) event recommendation from a first platform controller; receiving a second MRC event recommendation from a second platform controller; selecting one of the first and second MRC event recommendations as a selected MRC event; and controlling an autonomous host vehicle according to the selected MRC event.

[0068] According to one embodiment, the invention is further characterized by generating a third MRC event recommendation, and wherein selecting the selected MRC event includes selecting from among the first, second, and third MRC event recommendations.

[0069] According to one embodiment, selecting one of the first and second MRC event recommendations as the selected MRC event is based on a severity associated with the first MRC event recommendation and a severity associated with the second MRC event recommendation, wherein the severity of the first MRC event recommendation and the severity of the second MRC event recommendation are different, wherein if it is determined that the severity associated with the first MRC event recommendation is greater than the severity associated with the second MRC event recommendation, the first MRC event recommendation is selected as the selected MRC event, and wherein if it is determined that the severity associated with the second MRC event recommendation is greater than the severity associated with the first MRC event recommendation, the second MRC event recommendation is selected as the selected MRC event.

Claims

1. A vehicle computer comprising: Memory; and a processor programmed to execute instructions stored in the memory, the instructions comprising: receiving a first minimal risk condition event recommendation from a first platform controller and receiving a second minimal risk condition event recommendation from a second platform controller; generating a third minimum risk condition event recommendation; selecting one of the first minimum risk condition event recommendation and the second minimum risk condition event recommendation as a selected minimum risk condition event; and Control the autonomous host vehicle according to the selected minimum risk condition event, Wherein selecting the selected minimum risk condition event includes selecting from the first minimum risk condition event recommendation, the second minimum risk condition event recommendation, and the third minimum risk condition event recommendation.

2. The vehicle computer of claim 1 , wherein the processor is programmed to receive the first and second minimum risk condition event recommendations as a result of the first and second platform controllers each detecting a vehicle system fault, wherein the vehicle system fault detected by the first platform controller is different from the vehicle system fault detected by the second platform controller. 3 . The vehicle computer of claim 1 , wherein the processor is programmed to generate the third minimal risk conditional event recommendation as a result of the processor detecting a vehicle sensor failure.

4. The vehicle computer of claim 1 or 2, wherein the processor is programmed to control the autonomous host vehicle according to the selected minimum risk condition event by outputting motion control signals to at least one of the first platform controller, the second platform controller, and a third platform controller.

5. The vehicle computer of claim 4, wherein the processor is programmed to receive the motion control signal from an autonomous vehicle controller and output the motion control signal to at least one of the first platform controller, the second platform controller, and the third platform controller.

6. The vehicle computer of claim 1 or 2, wherein the processor is programmed to select one of the first minimal risk condition event recommendation and the second minimal risk condition event recommendation as the selected minimal risk condition event based on a severity associated with the first minimal risk condition event recommendation and a severity associated with the second minimal risk condition event recommendation, wherein the severity of the first minimal risk condition event recommendation and the severity of the second minimal risk condition event recommendation are different.

7. The vehicle computer of claim 6 , wherein the processor is programmed to select the first minimal risk condition event recommendation as the selected minimal risk condition event if the severity associated with the first minimal risk condition event recommendation is determined to be greater than the severity associated with the second minimal risk condition event recommendation, and wherein the processor is programmed to select the second minimal risk condition event recommendation as the selected minimal risk condition event if the severity associated with the second minimal risk condition event recommendation is determined to be greater than the severity associated with the first minimal risk condition event recommendation.

8. The vehicle computer of claim 1 or 2, wherein the processor is programmed to select a fourth minimal risk condition event recommendation based on an overall severity of the first minimal risk condition event recommendation and the second minimal risk condition event recommendation, wherein the fourth minimal risk condition event recommendation is different from the first minimal risk condition event recommendation and the second minimal risk condition event recommendation.

9. A method for a vehicle, comprising: receiving a first minimum risk condition event recommendation from a first platform controller; receiving a second minimum risk condition event recommendation from a second platform controller; generating a third minimum risk condition event recommendation; selecting one of the first minimum risk condition event recommendation and the second minimum risk condition event recommendation as a selected minimum risk condition event; as well as Control the autonomous host vehicle according to the selected minimum risk condition event, Wherein selecting the selected minimum risk condition event includes selecting from the first minimum risk condition event recommendation, the second minimum risk condition event recommendation, and the third minimum risk condition event recommendation.

10. The method for a vehicle of claim 9, wherein selecting one of the first minimal risk condition event recommendation and the second minimal risk condition event recommendation as the selected minimal risk condition event is based on a severity associated with the first minimal risk condition event recommendation and a severity associated with the second minimal risk condition event recommendation, wherein the severity of the first minimum risk condition event recommendation and the severity of the second minimum risk condition event recommendation are different, wherein if it is determined that the severity associated with the first minimum risk condition event recommendation is greater than the severity associated with the second minimum risk condition event recommendation, selecting the first minimum risk condition event recommendation as the selected minimum risk condition event, and If it is determined that the severity associated with the second minimum risk condition event recommendation is greater than the severity associated with the first minimum risk condition event recommendation, then the second minimum risk condition event recommendation is selected as the selected minimum risk condition event.

11. The method for a vehicle according to any one of claims 9 to 10, which is executed by a vehicle computer.

Images