ADAPTIVE AUTONOMOUS BRAKING ACTIONS FOR AUTONOMOUS VEHICLES

In one embodiment, a system determines selection parameters to apply an adaptive braking scheme for an autonomous driving vehicle (ADV). The system determines a brake mode based on the selection parameters using a driving scenario mapping table. In response to determining that a brake is to be applied, the system applies a brake for the ADV according to the brake mode. The brake can be applied in three stages, where the three stages include a brake pre-charge stage, an increasing rate of deceleration stage, and a constant rate of deceleration stage for the adaptive braking scheme.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to operating autonomous driving vehicles. More particularly, embodiments of the disclosure relate to adaptive autonomous braking actions for autonomous vehicles.

BACKGROUND

Brake control is a critical operation in autonomous driving. Deceleration/pressure requests from the autonomous driving system (ADS) should be delivered to a brake system without faults.

DETAILED DESCRIPTION

A controller area network (CAN) bus is a vehicle bus standard designed to allow microcontrollers and devices (e.g., electronic control units (ECUs)) communicate with one another without a host computer. CAN is based on a messaging protocol, designed to multiplex electrical wiring within an automobile. For each device, the data in a frame is transmitted serially and in a way that if more than one device transmits at the same time, the device with the highest priority can continue to transmit while the other devices fall back. The transmitted frames are received by all devices, including the transmitting device.

A vehicle can have one or more CAN buses. For example, CAN buses can be dedicated to certain vehicle domains, e.g., infotainment CANs, vehicle control CANs, chassis domain CANs. CAN buses can also be categorized for different speeds (e.g., high speed CAN, low speed CAN), etc. CAN buses can also be designed as redundant components for backup purposes.

With the development of drive-by-wire systems, CAN buses can be used for communications between the different drive-by-wire systems and an autonomous driving system of the vehicle. There is a need to perform failure fallback braking when the different drive-by-wire systems detect CAN buses malfunctions or a lost of communication of the CAN buses is detected.

Furthermore, when a brake is applied, a single deceleration request may not result in the best of neither brake performance robustness, driver comfortable, or braking speed. An adaptive braking scheme according to various driving scenario can balance the brake performance robustness, driver comfortable, and braking speed.

Moreover, when a redundant chassis domain controller (e.g., a redundant drive by wire system) is used for an ADS, the ADS will activate the redundant DBW system if the primary DBW system fails. However, since that the ADS defaults to use the primary DBW system, the life of the primary DBW system is shorten if the primary DBW is strenuously used. When the redundant DBW system is not activated for a prolong period of time, the redundant DBW may not function as intended. There is a need to alternate between the primary and the redundant DBW systems even when the primary DBW system is operational to ensure the redundant DBW operates as intended and to prolong the life of the primary DBW system.

According to some embodiments, a system performs a failure fallback brake mechanism when the system detects that the communication channels of a primary and a secondary controller area network (CAN) is malfunctioning.

According to a first aspect, a system determines a signal fault at a communication bus of an autonomous driving vehicle (ADV). In response to determining the signal fault, the system sends a brake pre-charge command to a brake system of the ADV to pre-charge a brake of the ADV. The system determines a preset tolerance time to validate the signal fault. In response to a time elapse of the preset tolerance time, the system validates the signal fault at the communication bus or determine a signal fault at another communication bus. In response to validating the signal fault at the communication bus or determining the signal fault at the another communication bus, the system sends a brake command to the brake system of the ADV to engage brakes for the ADV.

According to a second aspect, a system determines selection parameters to apply an adaptive braking scheme for an autonomous driving vehicle (ADV). The system determines a brake mode based on the selection parameters using a driving scenario mapping table. In response to determining that a brake is to be applied, the system applies a brake for the ADV according to the brake mode. The brake can be applied in three stages, where the three stages include a brake pre-charge stage, an increasing rate of deceleration stage, and a constant rate of deceleration stage.

According to a third aspect, a system determines activation parameters for an autonomous driving vehicle (ADV), where the activation parameters include historical usages of a primary brake system or a secondary brake system. In response to determining that a brake is to be applied, the system determines whether to activate a primary or a secondary brake system based on the activation parameters. The system sends an activation flag to activate the primary or the secondary brake system based on the determining whether to activate the primary or the secondary brake system. The system sends a brake command to the primary and the secondary brake system to activate either the primary or the secondary brake system according to the activation flag.

Referring now toFIG.2, in one embodiment, sensor system115includes, but it is not limited to, one or more cameras211, global positioning system (GPS) unit212, inertial measurement unit (IMU)213, radar unit214, and a light detection and range (LIDAR) unit215. GPS system212may include a transceiver operable to provide information regarding the position of the ADV. IMU unit213may sense position and orientation changes of the ADV based on inertial acceleration. Radar unit214may represent a system that utilizes radio signals to sense objects within the local environment of the ADV. In some embodiments, in addition to sensing objects, radar unit214may additionally sense the speed and/or heading of the objects. LIDAR unit215may sense objects in the environment in which the ADV is located using lasers. LIDAR unit215could include one or more laser sources, a laser scanner, and one or more detectors, among other system components. Cameras211may include one or more devices to capture images of the environment surrounding the ADV. Cameras211may be still cameras and/or video cameras. A camera may be mechanically movable, for example, by mounting the camera on a rotating and/or tilting a platform.

Some or all of the functions of ADV101may be controlled or managed by ADS110, especially when operating in an autonomous driving mode. ADS110includes the necessary hardware (e.g., processor(s), memory, storage) and software (e.g., operating system, planning and routing programs) to receive information from sensor system115, control system111, wireless communication system112, and/or user interface system113, process the received information, plan a route or path from a starting point to a destination point, and then drive vehicle101based on the planning and control information. Alternatively, ADS110may be integrated with vehicle control system111.

While ADV101is moving along the route, ADS110may also obtain real-time traffic information from a traffic information system or server (TIS). Note that servers103-104may be operated by a third party entity. Alternatively, the functionalities of servers103-104may be integrated with ADS110. Based on the real-time traffic information, MPOI information, and location information, as well as real-time local environment data detected or sensed by sensor system115(e.g., obstacles, objects, nearby vehicles), ADS110can plan an optimal route and drive vehicle101, for example, via control system111, according to the planned route to reach the specified destination safely and efficiently.

Server103may be a data analytics system to perform data analytics services for a variety of clients. In one embodiment, data analytics system103includes data collector121and machine learning engine122. Data collector121collects driving statistics123from a variety of vehicles, either ADVs or regular vehicles driven by human drivers. Driving statistics123include information indicating the driving commands (e.g., throttle, brake, steering commands) issued and responses of the vehicles (e.g., speeds, accelerations, decelerations, directions) captured by sensors of the vehicles at different points in time. Driving statistics123may further include information describing the driving environments at different points in time, such as, for example, routes (including starting and destination locations), MPOIs, road conditions, weather conditions, etc.

Data collector121can collect usage/failure statistics125for ADV101. Usage/failure statistics125may include usage information and/or failure information for the primary and/or secondary (redundant) systems of the ADV. For example, usage information can include how many times (and/or average of how many hours) either the primary or the second systems are used over a predetermined length of time. Failure information can include the warning indicators, which subsystems of the ADV indicates a failure/warning, corresponding levels of the failures, etc. The primary and/or secondary systems can be for the chassis domain controllers (drive-by-wire systems), computing systems (ADS) of the ADV, braking systems, steering systems, throttle systems, transmission systems, sensor systems, individually sensors, and/or power systems.

Based on driving statistics123and usage/failure statistics125, machine learning engine122generates or trains a set of rules, algorithms, and/or predictive models124for a variety of purposes. In one embodiment, algorithms124may include a selection algorithm to select a brake mode to apply to ADV and an activation algorithm used to activate either primary system(s) or secondary (redundant) system(s) of the ADV.

Algorithms124can then be uploaded on ADVs to be utilized during autonomous driving in real-time.

FIGS.3A and3Bare block diagrams illustrating an example of an autonomous driving system used with an ADV according to one embodiment. System300may be implemented as a part of ADV101ofFIG.1including, but is not limited to, ADS110, control system111, and sensor system115. Referring toFIGS.3A-3B, ADS110includes, but is not limited to, localization module301, perception module302, prediction module303, decision module304, planning module305, control module306, routing module307, brake mode selection module308, and secondary system activation module309.

Based on the sensor data provided by sensor system115and localization information obtained by localization module301, a perception of the surrounding environment is determined by perception module302. The perception information may represent what an ordinary driver would perceive surrounding a vehicle in which the driver is driving. The perception can include the lane configuration, traffic light signals, a relative position of another vehicle, a pedestrian, a building, crosswalk, or other traffic related signs (e.g., stop signs, yield signs), etc., for example, in a form of an object. The lane configuration includes information describing a lane or lanes, such as, for example, a shape of the lane (e.g., straight or curvature), a width of the lane, how many lanes in a road, one-way or two-way lane, merging or splitting lanes, exiting lane, etc.

For each of the objects, prediction module303predicts what the object will behave under the circumstances. The prediction is performed based on the perception data perceiving the driving environment at the point in time in view of a set of map/route information311and traffic rules312. For example, if the object is a vehicle at an opposing direction and the current driving environment includes an intersection, prediction module303will predict whether the vehicle will likely move straight forward or make a turn. If the perception data indicates that the intersection has no traffic light, prediction module303may predict that the vehicle may have to fully stop prior to enter the intersection. If the perception data indicates that the vehicle is currently at a left-turn only lane or a right-turn only lane, prediction module303may predict that the vehicle will more likely make a left turn or right turn respectively.

For each of the objects, decision module304makes a decision regarding how to handle the object. For example, for a particular object (e.g., another vehicle in a crossing route) as well as its metadata describing the object (e.g., a speed, direction, turning angle), decision module304decides how to encounter the object (e.g., overtake, yield, stop, pass). Decision module304may make such decisions according to a set of rules such as traffic rules or driving rules312, which may be stored in persistent storage device352.

Routing module307is configured to provide one or more routes or paths from a starting point to a destination point. For a given trip from a start location to a destination location, for example, received from a user, routing module307obtains route and map information311and determines all possible routes or paths from the starting location to reach the destination location. Routing module307may generate a reference line in a form of a topographic map for each of the routes it determines from the starting location to reach the destination location. A reference line refers to an ideal route or path without any interference from others such as other vehicles, obstacles, or traffic condition. That is, if there is no other vehicle, pedestrians, or obstacles on the road, an ADV should exactly or closely follows the reference line. The topographic maps are then provided to decision module304and/or planning module305. Decision module304and/or planning module305examine all of the possible routes to select and modify one of the most optimal routes in view of other data provided by other modules such as traffic conditions from localization module301, driving environment perceived by perception module302, and traffic condition predicted by prediction module303. The actual path or route for controlling the ADV may be close to or different from the reference line provided by routing module307dependent upon the specific driving environment at the point in time.

Based on the planning and control data, control module306controls and drives the ADV, by sending proper commands or signals to vehicle control system111, according to a route or path defined by the planning and control data. The planning and control data include sufficient information to drive the vehicle from a first point to a second point of a route or path using appropriate vehicle settings or driving parameters (e.g., throttle, braking, steering commands) at different points in time along the path or route.

Note that decision module304and planning module305may be integrated as an integrated module. Decision module304/planning module305may include a navigation system or functionalities of a navigation system to determine a driving path for the ADV. For example, the navigation system may determine a series of speeds and directional headings to affect movement of the ADV along a path that substantially avoids perceived obstacles while generally advancing the ADV along a roadway-based path leading to an ultimate destination. The destination may be set according to user inputs via user interface system113. The navigation system may update the driving path dynamically while the ADV is in operation. The navigation system can incorporate data from a GPS system and one or more maps so as to determine the driving path for the ADV.

Brake mode selection module308can determine statuses for the primary/secondary ADS, the primary/secondary chassis domain controllers, and driving statistics to select a brake mode from a mapping table. The brake mode selection of brake mode selection module308is further detailed inFIGS.9-14.

Secondary system activation module309can gather usage/failure statistics of different primary and secondary systems of the ADV101. Using the usage/failure statistics, and driving statistics, secondary system activation module309can activate either the different primary or the secondary systems of the ADV. By activating the secondary systems even when the primary systems are operational, the useful life of the primary systems can be extended and the likelihood of failure of the secondary systems can be mitigated. The activation by secondary system activation module309is further detailed inFIGS.15-20. Note that brake mode selection module308and secondary system activation module309may be integrated as an integrated module.

FIG.4is a block diagram400illustrating an example of redundant systems for an autonomous driving vehicle according to one embodiment. Typically, vehicle safety requires critical control systems to be designed with redundancy. For example, a vehicle autonomous driving system (ADS) can include primary and secondary ADS systems, where the secondary ADS operates in a redundancy mode.

Vehicle controls are divided into chassis, body, and powertrain domains. Powertrain domain relates to controls of engine and transmission of a vehicle. Body domain relates to controls of windows, doors, mirrors adjustment, seat adjustment, ventilation, heating etc. Chassis domain relates to controls of the brakes, throttle, and/or steering for vehicle stability and dynamics.

A chassis domain control system410, as part of vehicle control system111ofFIG.1, can represent the controls for the chassis domain. Although body and powertrain domains are not shown inFIG.4, the redundant systems can be extended to the body and powertrain domains.

Referring toFIG.4, ADS110can include a primary ADS401, and a secondary ADS403. In one embodiment, primary ADS401serves as the default ADS system for ADV101and secondary ADS403acts as a redundant system and is activated when primary ADS401fails. In one embodiment, ADS110includes one or more microcontrollers (MCUs)405. MCUs405can include a system on chip (SOC) with processor core(s), memory and input/output (I/O) in a one discrete package. MCU405can be used to communicate control signals for body control, driving control, infotainment and driving assistance control systems, etc. In one embodiment, MCU405can communicate with chassis domain control system410. For example, MCU405can communicate brake commands to chassis domain control system410to activate the brakes.

Referring toFIG.4, in one embodiment, chassis domain control system410includes primary and secondary chassis domain controllers411-413, primary and secondary brake units421-423, primary and secondary steering units431-433, and primary and secondary throttle units441-443. Chassis domain controllers411-413are coupled to ADS110via primary and secondary CAN buses461-463. Primary and secondary CAN buses461-463are coupled via gateway465so components on the primary CAN bus can communicate signals to components on the secondary CAN bus, and vice versa. In one embodiment, either of chassis domain controllers411-413can receive signals from ADS110and/or sensor system115, and issue commands/signals to any of electronic control units (ECUs) (not shown) corresponding to units421-443. The ECUs can then send the control commands to units421-443to control actuations of units421-443.

With the development of automobile intelligence, the chassis of traditional vehicles are modified by wire to be suitable for automatic driving, e.g., drive-by-wire systems. Some examples of drive-by-wire systems include steering by wire, braking by wire, shift (transmission) by wire, oil control valve and suspension by wire, etc. Steering by wire and braking by wire are critical vehicle controls and are typically designed with redundancy.

In some embodiments, chassis domain controllers411-413include respective drive-by-wire (DBW) units 1-2. In some embodiments, brake, steering, and throttle units421-443include corresponding brake-by-wire, steering-by-wire, and/or throttle-by-wire systems. In some embodiments, brake, steering, and throttle units421-443include the conventional hydraulic brake system, a steering column for steering, and a direct mechanical linkage for throttle.

Referring toFIG.4, when signal fault occurs at primary and/or secondary CAN buses461-463, chassis domain controllers411-413may not be able to receive command signals from MCU405. In one embodiment, primary chassis controller411and/or secondary chassis controller413includes signal fault brake module500. C signal fault brake module500can activate the brakes when module500detects signal faults at primary and/or secondary CAN buses461-463.

FIG.5is a block diagram illustrating an example of a signal fault brake module500according to one embodiment. Signal fault brake module500can detect a communication bus (e.g., CAN bus) failure and issue a brake command to the brake units. The signal faults can include communication faulty cable, noise, incorrect termination, bus disconnect events, bus failure events, etc. Some failure modes can include CAN high signal line (CAN_H) interrupted, CAN low signal line (CAN_L) interrupted, CAN_H shorted to ground, CAN_L shorted to ground, CAN_H shorted to battery voltage, CAN_L shorted to battery voltage, CAN_H shorted to CAN_L, etc.

In one embodiment, signal fault brake module500includes failure determiner submodule501, brake pre-charge submodule503, time tolerance determiner submodule505, time elapse determiner submodule507, brake release submodule509, and braking submodule511. Failure determiner submodule501can determine a failure has occurred on a communication bus. For example, submodule501can detect a failure mode, error code or a communication disconnect for a primary CAN bus or a secondary CAN bus, such as primary CAN bus461or secondary CAN bus463ofFIG.4. Brake pre-charge submodule503can issue a brake pre-charge command to the brake unit. The brake pre-charge command can cause a brake pad to move within a threshold distance to the brake rotor (e.g., no contact or slight contact) but not cause ADV101to stop. The brake pre-charge is further detailed inFIG.7.

Time tolerance determiner submodule505can determine a time tolerance to valid a failure. The tolerance time can be preset by the ADS and can represent a time threshold to ascertained that a failure is not intermittent. That is, the failure is validated when the failure still exists over a period of the tolerance time. An example of a tolerance time can be 300 milliseconds. For this example, if an error had occurred at reference time=Oms (milliseconds) and each cycle the error is detected thereafter, then the error is ascertained/validated at time=300 ms. The failure validation can cause the ADS to perform error mitigation tasks. In another example, if an error had occurred at time=Oms (milliseconds) and the error is mitigated at time=100 ms the failure is said to be invalidated at time=100 ms. If the failure reappeared at time=140 ms and lasts until time=440 ms, the failure is validated only at time=440 ms since a count of the tolerance time is restarted at time=140 ms and the failure lasted over the tolerance time of 300 ms.

Time elapse determiner submodule507can determine a time elapse since a failure has been detected for failure validation. Brake release submodule509can release the brakes if the failure is invalidated. Braking submodule511can apply the brakes if a failure is validated. Note that any of submodules501-511can be integrated as an integrated module and can be implemented in software or hardware.

Although a failure fallback brake mechanism can be used for a brake-by-wire system, the failure fallback brake mechanism can also be used for a hydraulic brake system.FIG.6is a block diagram illustrating an example of a hydraulic brake system600according to one embodiment. Hydraulic brake system600can represent primary and secondary brake unit421-423ofFIG.4. Referring toFIG.6, a hydraulic brake system is a type of braking system that uses brake hydraulic fluid to transmit brake pedal force from the brake pedal to the brake drum/disc caliper of the vehicles wheels to perform the braking. In one embodiment, hydraulic brake system600includes primary hydraulic brake system421and secondary hydraulic brake system423.

Primary hydraulic braking system421can include a front-axle brake line603and a rear-axle brake line605for supplying brake hydraulic fluid (or brake fluids) respectively to wheel brake apparatuses651and653at the front wheels and wheel brake apparatuses655and657at the rear wheels. The brake fluids can transfer the physical motion asserted by an operator on the brake pedals to the wheel brake apparatuses. Example wheel brake apparatuses include caliper/disc pads and rotors, and/or brake drums and rotors.

Two brake lines603,605can be connected to a shared brake master cylinder607that is supplying the brake fluids via a fluid reservoir609. Brake master cylinder607can include a piston615that can be actuated by an operator via brake pedal611to force brake fluids inside master cylinder607down lines603-605towards wheel brake apparatuses651-657. A pedal travel distance of brake pedal611can be measured by a pedal travel sensor613. In one embodiment, a brake booster612is coupled between master cylinder607and brake pedal611to assist the actuation force of the operator. For example, brake booster612can detect a pedal travel distance using pedal travel sensor613and drive a motor (not shown) to electronically actuate piston615. In one embodiment, brake booster612can be operated electronically by ADS110to apply the brakes via brake commands.

The flow of the brake fluids supplied by master cylinder607can be controlled to front or rear wheels by inlet valves617-619. The supplied brake fluids at the front or rear wheels can be further controlled to individual wheels by respective inlet valves621-627. The supplied hydraulic fluid can return to fluid reservoir609via respective outlet valves631-637.

In one embodiment, primary hydraulic braking system421includes slave cylinder641. Slave cylinder641can be electronically operated by motor643to actuate piston645in slave cylinder641to force brake hydraulic fluid to flow to fluid lines603-605and toward wheel brake apparatuses651-657. In one embodiment, slave cylinder641can be operated electronically by ADS110to apply the brakes via brake commands. In some embodiments, a chassis domain controller, such as chassis domain controllers (e.g., DBW 1 or DBW 2)411-413ofFIG.4, can electronically operate motor643to control the brake apparatuses651-657. In one embodiment, the flow of brake hydraulic fluid supplied by slave cylinder641can be controlled to the front or rear wheels via inlet valves647-649.

In one embodiment, primary hydraulic braking system421includes pressure sensors601-602at master cylinder lines and slave cylinder lines to sensor the pressures at the respective lines. The sensed pressure values can be used as feedback signals to control the brakes.

Referring toFIG.6, secondary hydraulic brake system423can be an electronic stability control (ESC) system or anti-lock braking system (ABS). ABS is a safety feature that prevents an operator from locking up the wheels under heavy braking (which completely disables the ability to steer) and allows the operator to maintain steering control. The ABS does so by clamping the brake pads on the discs (or drums) until wheel-speed sensors detect that a wheel is about to lock. The system then temporarily releases the brakes before squeezing them again rapidly—repeating this process up to 15 times per second in some instances—to prevent any wheel lock from occurring.

In one embodiment, secondary hydraulic brake system423includes motor661and pressure sensor663. Motor661can pulse pump brake fluids to the wheel apparatus. In one embodiment, motor661can accumulate brake fluids from tank reservoir609to an accumulator (not shown) to supply brake fluids to wheel brake apparatuses651-657. In one embodiment, motor661can be operated electronically by ADS110to apply the brakes via brake commands. In one embodiment, a chassis domain controller (CDC), such as CDCs (DBW 1 or DBW 2)411-413ofFIG.4, can electronically operate motor661to control the brake apparatuses651-657. In one embodiment, the flow of brake fluids supplied by secondary hydraulic brake system423can be controlled by inlet valves671-677to flow to respective wheel brake apparatuses651-657for stability control. In one embodiment, the brake fluid returns from secondary hydraulic brake system423, via outlet valves681-687and line689, to tank reservoir609.

As shown inFIG.6, when either master cylinder607, slave cylinder641, or motor661operates, valves616,646are electronically configured to close and brake fluids take a threshold amount of time to accumulate. In addition, any signals electronically propagated or hydraulically propagated to the brake apparatus has some reaction time. That is, operating the brakes are not instantaneous and has associated delays. Thus, when ADS issues a request to decelerate at time=0, the brakes would be applied sometime later as further illustrated inFIG.7.

FIG.7is a block diagram700illustrating an example of a deceleration request according to one embodiment. Diagram700depicts a deceleration request (A_req)701submitted at time=Os and an actual deceleration703of ADV101in response to the requested deceleration. The deceleration request701can represent a brake command requested by ADS110or by a chassis domain controller. An example brake request command can be A_req=−0.3*g, where A_req is a requested deceleration and g is the acceleration of gravity or 9.8 m/s{circumflex over ( )}2.

As shown inFIG.7, actual deceleration703can represent an undamped transient response with an initial delayed period705, followed by a tracking period707, a settling period709, and finally a steady-state period711. Furthermore, actual deceleration703can have an overshoot713, corresponding to a short period of deceleration that is greater than A_req701. In one embodiment, the brakes can be applied in three stages, instead of a single deceleration request A_req701, to reduce the reaction time of the brakes and to increase a comfort level for the operator.

For example, for the first stage, to minimize delay period705, a brake pre-charge command can be introduced at the primary/secondary ADS, MCU, and/or primary/secondary CDC. For example, the brake pre-charge command can pre-charge a piston at the master/slave cylinders for the primary brake system or accumulate hydraulic fluids for the secondary brake system. The pre-charge command actuates the disc/caliper pads to close a distance between the pads and the rotor at the wheel brake apparatus.

In one embodiment, the brake pre-charge command can cause a brake pad to move within a predetermined threshold distance to a corresponding rotor. In one embodiment, the brake pre-charge command includes a brake distance travel command, a brake hydraulic pressure command, or a deceleration command. For example, the brake pre-charge command includes a pressure request to apply 0.05 MPA of pressure at the hydraulic fluid over a predetermined period, e.g., 100 ms, or brake pre-charge command can include a pedal travel distance request to apply 0.5 mm of pedal travel distance over 100 ms, or brake pre-charge command can include a deceleration request to deceleration by 0.01*g m/s{circumflex over ( )}2 over 100 ms. Here, the applied brake pre-charge command would not noticeably slow down the vehicle. Rather, the applied brake pre-charge command pre-charges the brake systems to reduce a response time of the brakes if the brakes need to be applied.

In one embodiment, the brake pre-charge command can be a customized brake signal that includes a command flag, a command value, and a command duration. For example, the command flag can flag if the command is a pressure request, a pedal travel distance request, or a deceleration request. The command value can be the corresponding request value, and the command duration can be a time duration to apply the pre-charge command. An example brake pre-charge command can be {flag: pressure, value: 0.05, duration: 100 ms}.

For the second stage, to improve a comfort level for the operator, the tracking response of the A_req should be capped to a predetermined slope, e.g., dA_req/dt is less than a predetermined threshold. For example, dA_req/dt can be capped to −50 m/s{circumflex over ( )}3. Here, a tracking command can be introduced to the ADS, MCU, and/or CDC for a dA_req/dt command. In some embodiments, the dA_req/dt command can be converted to a dynamic deceleration request by the MCU and/or CDC.

For the third stage, the request command can correspond to a constant deceleration, such as −0.6 m/s{circumflex over ( )}2. In some embodiments, a three-stage brake command can include brake commands representative of the first, second, and third stages. In another embodiment, a two-stage brake command can be applied as two stages, a first stage for the brake pre-charge (e.g., first stage) and a second stage corresponding to the tracking and steady brake commands.

For CAN buses failures, a brake command can be automatically performed by processing logic which may include software, hardware, or a combination thereof. For example, a brake command can be issued by a CDC, e.g., CDC411or413ofFIG.4, as a two-stage command to improve a response time and operator comfort.

FIG.8is a flow diagram illustrating a method to perform failure fallback braking according to one embodiment. Process900may be performed by processing logic which may include software, hardware, or a combination thereof. For example, process900may be performed by primary or second CDC411-413ofFIG.4.

At block901, processing logic determines a signal fault at a communication bus (e.g., primary or secondary CAN buses) of an autonomous driving vehicle (ADV).

At block903, in response to determining the signal fault, processing logic sends a brake pre-charge command to a brake system of the ADV to pre-charge a brake of the ADV.

At block905, processing logic determine a preset tolerance time to validate the signal fault.

At block907, in response to a time elapse of the preset tolerance time, processing logic validates the signal fault at the communication bus (e.g., primary or secondary CAN buses) or determining a signal fault at another communication bus (e.g., secondary or primary CAN buses).

At block909, in response to validating the signal fault at the communication bus or determining the signal fault at the another communication bus, processing logic sends a brake command to the brake system of the ADV to engage brakes for the ADV.

The brake command can be a deceleration request or can correspond to a multi-stage command (e.g., tracking and steady brakes).

In one embodiment, processing logic determines that the signal fault at the communication bus is invalidated within the preset tolerance time. In response to determining that the signal fault at the communication bus is invalidated within the preset tolerance time, processing logic sends a brake recovery command to the brake system of the ADV to release the brakes.

In one embodiment, the brake system is a primary brake system or a secondary brake system of the ADV, where the secondary brake system includes an anti-lock brake system.

In one embodiment, the communication bus includes a primary controller area network (CAN) or a second CAN bus, where a communication channel of the primary or secondary CAN bus is used by an autonomous driving system (ADS) of the ADV to communication with a chassis domain controller of the ADV.

In one embodiment, the signal fault indicates a communication error or a lost of communication for one or more communication channels of the communication bus.

In one embodiment, the sent brake pre-charge command causes a brake pad to move within a threshold distance to a corresponding rotor.

In one embodiment, the brake pre-charge command comprises a brake distance travel command, a brake hydraulic pressure command, or a deceleration command.

In one embodiment, the brake pre-charge command includes a command flag indicating the type of command value, a command value indicating a value for a pressure or a value for a master cylinder travel distance or a deceleration value, or a command status duration indicating a duration of validity of the command.

In one embodiment, the brake command includes a first deceleration request value corresponding to a first predetermined time period and a second deceleration request value corresponding to a second predetermined time period to minimize overshoot of deceleration from applying the brakes, where the first deceleration request value is greater than the second deceleration request value.

In one embodiment, the brake system is controlled by a drive-by-wire system.

FIG.9is a block diagram illustrating an example of redundant systems for an autonomous driving vehicle according to one embodiment. System1000can represent system400ofFIG.4. In one embodiment, primary or secondary ADS401-403can include brake mode selection module308. In one embodiment, primary or secondary chassis domain controllers411-413can include brake mode selection module308. Description for various components of system1000can be referenced to system400ofFIG.4.

FIG.10is a block diagram illustrating an example of a brake mode selection module308according to one embodiment. Brake mode selection module308can select a brake mode (e.g., sharp brake, gradual brake, or any other modes) from selection parameters available to ADV101. In one embodiment, brake mode selection module308includes ADS status determiner submodule1101, chassis domain status determiner submodule1103, obstacle determiner submodule1105, brake mode determiner submodule1107, brake pre-charge submodule1109, and brake tracking submodule1111, steady brake submodule1113.

Referring toFIGS.9-10, ADS status determiner submodule1101can determine a status of primary or secondary ADS401-403. Chassis domain status determiner submodule1103can determine a status of primary or secondary domain controller411-413. The status can correspond to an associated failure level, such as F0-F4 shown inFIG.12F. Obstacle determiner submodule1105can detect obstacles surrounding ADV101. Obstacles surrounding ADV101can be detected using sensors (cameras, LIDAR, RADAR, time of flight (TOF) sensors) and the obstacles can be categorized to one of pedestrian, vehicles, etc., using an imaging recognition algorithm or a machine learning model. Brake mode determiner submodule1107can determine a brake mode using the ADS/chassis domain status, vehicle status (driving mode), and/or obstacle information. When ADV applies a brake, the brake can be a multi-stage brake as described in the above. Brake pre-charge submodule1109can apply a brake pre-charge command to reduce a pre-charge time for the brakes. Brake tracking submodule1111can apply a brake command to limit the dA_req/dt to be within a threshold, thus, improving operator comfort. Steady brake submodule1113can issue a A_req command.

FIG.11is a block diagram1200illustrating an example of a brake mode selection for an ADV according to one embodiment. As shown inFIG.11, brake mode selection system1100receives a plurality of selection parameters. Using the selection parameters, brake mode selection system1100performs a lookup operation using a mapping table, such as mapping table1300ofFIGS.12A-12E, to determine a brake mode (e.g., gradual or sharp) in real-time for the ADV. Here, the selection parameters can include 1. Driving Direction, 2. Primary ADS Status, 3. Secondary ADS Status, 4. Primary Chassis Controller Status, 5. Secondary Chassis Controller Status, 6. Vehicle at Front, 7. Vehicle Behind, and 8. Pedestrian at Front. Although eight parameters are shown, other parameters such as road condition, weather, vehicle status are possible. Furthermore, the brake modes can have associated brake settings. For example, a multi-stage brake control can be applied for either the gradual or sharp brake modes. For example, the gradual brake settings for the three stages (e.g., pre-charge time, tracking deceleration, and steady deceleration) can be: 100 ms, −25 m/s{circumflex over ( )}3, and 0.3 m/s{circumflex over ( )}2. The sharp brake settings for the three stages (e.g., pre-charge time, tracking deceleration, and steady deceleration) can be: 100 ms, −50 m/s{circumflex over ( )}3, and 0.6 m/s{circumflex over ( )}2. Although a three-stage brake control is shown, the brake control can be a single-stage, e.g., A_req=0.3 m/s{circumflex over ( )}2 for gradual braking and A_req=0.6 m/s{circumflex over ( )}2 for sharp braking. The mapping table1300is described as follows.

FIG.12Fillustrates a legend for the failure levels F0-F4 in mapping table1300ofFIGS.12A-12E. For example, the failure level F0 corresponds to no failure or failure free operation. F1 corresponds to a failure for the corresponding system but the failure level does not affect the ADS operations. F2 corresponds to a failure that affects the ADS and is severe enough to require the ADV to slow down. F3 corresponds to a failure that affects the ADS and is severe enough to require the ADS to eventually stop the ADV. F4 corresponds to a failure that affects the ADS and requires the ADS to stop the ADV immediately.

In one embodiment, as shown in mapping table1300ofFIGS.12A-12E, each of the ADS and the chassis domain controllers (CDC) of the ADV has a redundant counterpart. The primary ADS, secondary ADS, primary CDC, and secondary CDC can correspond to systems/components401,403,411, and413ofFIG.9respectively. In one embodiment, as shown in mapping table1300, an ADS can issue the brake commands for scenarios 1-48. An MCU or CDC can issue the brake commands for scenario 49-50, and a CDC (e.g., CDC 1 or 2) can issue the brake controls for scenario 51. Although the ADS and the chassis domain controller are shown with redundancy, An ADV can be configured without the redundancy, and processing logic can generate a corresponding mapping table with reduced scenarios corresponding to mapping table1300. In some embodiments, mapping table1300is configured by an operator and uploaded onto ADV101at persistent storage devices accessible by ADS401, ADS403, primary CDC411, secondary CDC413, and MCU405.

Referring to scenario 51 inFIG.12E, the primary or secondary CDC (e.g., DBWs 1, 2) exhibits failure levels F3/F4 (e.g., ADS function of the corresponding components is affected) and the primary/secondary ADS exhibit any of failure levels F0-F4. In this scenario, since the primary or secondary CDCs are at failure levels F3/F4 (e.g., ADS function of the corresponding components is affected), a CDC (any of primary or secondary CDC) is mapped in mapping table1300to issue a brake control corresponding to sharp braking. In this case, the failure is critical and sharp braking mode is selected and a CDC would issue the sharp braking commands, regardless of the other selection parameters.

Referring to scenario 50 inFIG.12E, primary ADS, secondary ADS, and primary CDC exhibit F3/F4 failure levels (e.g., ADS function of the corresponding components is affected), while secondary CDC only exhibits F0/F1/F2 failure levels (e.g., ADS function of the corresponding components is not affected). In this case, the failure at both the primary and secondary ADSs affects ADS functions and sharp braking mode is selected. Furthermore, at least the secondary CDC can receive a brake command and control the brakes using the received brake commands. Thus, regardless of any vehicle at front, pedestrian at front, or vehicle behind ADV, sharp braking can be issued by the MCU or the CDC.

Referring to scenario 49 inFIG.12E, primary ADS and secondary ADS exhibit F3/F4 failure levels (e.g., ADS function of the corresponding components is affected), primary CDC exhibits F0/F1/F2 (e.g., ADS function of the corresponding components is not affected), and secondary CDC exhibits F0/F1/F2/F3/F4 failure levels (e.g., can be any of F0 to F4). In this case, the failure is critical at the primary and secondary ADSs and sharp braking mode is selected. Furthermore, at least the secondary CDC is operational to receive a brake command and control the brakes from the received brake commands. Thus, the brake controls corresponding to sharp braking mode can be issued by the MCU or a CDC.

Referring to scenarios 1-48 inFIGS.12A-12D, at least one of primary or secondary ADS has ADS operations functioning (e.g., F0/F1/F2) and at least one of primary or secondary CDC has ADS operations functioning (e.g., F0/F1/F2), the brake mode selection would then correspond to: whether any vehicle at front (and a distance threshold from ADV), pedestrian at front (and a distance threshold from ADV), and/or vehicle following behind the ADV.

For example, in scenario 5, primary ADS has failure level F3-F4 indicating corresponding AD operations are affected; secondary ADS has failure level F0-F2 indicating corresponding AD operations are not affected; primary CDC has failure level F0-F2 indicating corresponding AD operations are not affected. Here, regardless of the status of secondary CDC, a brake signal can be propagated at least by secondary ADS to primary CDC. In this case, ADV can detect that a vehicle is ahead and is braking sharply, a pedestrian is close by (e.g., within a predetermined distance) and is in front of the ADV, and a vehicle is close by (e.g., within a predetermined distance) following the ADV. According to mapping table1300, in scenario 5, ADV selects the sharp braking mode (because there is a vehicle ahead and is braking sharply). E.g., primary ADS would issue the three-stage brake command for sharp braking.

FIGS.13A-13Bis a diagram illustrating the control flow for the illustrated brake mode selection scenarios according to one embodiment. Process1350may be performed by processing logic which may include software, hardware, or a combination thereof. For example, process1350may be performed by brake mode selection308ofFIG.10, implemented at any of primary ADS401, secondary ADS403, primary CDC411, and/or second CDC413ofFIG.9. In one embodiment, process1350is applied to select a brake mode when ADV101has a forward moving driving direction.

Regarding scenario 51, at block1351ofFIG.13A, processing logic determines the status of primary (P) CDC. If P CDC status is failure level F3 or F4, processing logic proceeds to block1353. At block1353, processing logic determines status of secondary (S) CDC. If S CDC status is failure level F3 or F4, processing logic proceeds to block1355and determines that a sharp brake command is to be issued by a CDC module to the primary and secondary brake units421-423of ADV101. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Regarding scenario 50, at block1353, if S CDC status is not failure level F3/F4, processing logic proceed to block1357. At block1357, processing logic determines status for P ADS. If P ADS status is failure level F3 or F4, processing logic proceed to block1359. At block1359, processing logic determines status for S ADS. If S ADS status is failure level F3 or F4, processing logic proceed to block1361and determines that a sharp brake command is to be issued by microcontroller MCU405, and/or any of CDC module411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Regarding scenario 49, at block1351, If P CDC status is not failure level F3 or F4 (e.g., F0 or F1 or F2), regardless of the status of S CDC (e.g., F0/F1/F2/F3/F4), processing logic proceeds to block1363. At block1363, processing logic determines status for P ADS. If P ADS status is failure level F3 or F4, processing logic proceeds to block1365. At block1365, processing logic determines status for S ADS. If S ADS status is failure level F3 or F4, processing logic proceeds to1367. At block1367, processing logic determines that a sharp brake command is to be issued by microcontroller MCU405, and/or any of CDC module411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Each of scenarios 1-48 proceeds to block K that continues toFIG.3B. For example, regarding scenarios 1-12, at block1365, if S ADS status is not failure level F3 or F4, processing logic proceeds to block K. Regarding scenarios 13-24, at block1359, if S ADS status is not failure level F3 or F4, processing logic proceed to block K. Regarding scenario 25-36, at block1351, if P CDC status is not failure level F3 or F4, processing logic proceeds to block1369. At block1369, processing logic determines status of S CDC. If S CDC status is failure level F3 or F4, processing logic proceeds to block1371. At block1371, processing logic determines status for P ADS. If P ADS status is not failure level F3 or F4, processing logic proceed to block K. Regarding scenarios 37-48, at block1357, if P ADS status is not failure level F3 or F4, processing logic proceed to block K.

Referring toFIG.13B, the scenarios 1-48 can be illustrated by the five control paths starting from block K which proceeds to block1373. Regarding scenarios 1-2; 13-14; 25-26; and 37-38, at block1373, processing logic determines if an obstacle vehicle is in front of ADV101. If the obstacle vehicle is detected to be in front and is close by (e.g., within a predetermined threshold distance to ADV101), processing logic proceeds to block1375.

At block1375, processing logic determines if an obstacle pedestrian is detected in front of ADV101. If the obstacle pedestrian is in front and close by (e.g., within a predetermined threshold distance to ADV101), processing logic proceeds to block1377, and determines that a sharp brake command is to be issued. The command can be issued from any of primary ADS401, secondary ADS403, microcontroller MCU405, and/or any of CDC modules411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Regarding scenarios 3-4; 15-16; 27-28; and 39-40, at block1375, if the obstacle pedestrian is detected in front and faraway (e.g., exceed a predetermined threshold distance to ADV101), processing logic proceeds to block1379, and determines that a gradual brake command is to be issued. The command can be issued from any of primary ADS401, secondary ADS403, microcontroller MCU405, and/or any of CDC modules411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Regarding scenarios 5-8; 17-20; 29-32; and 41-44, at block1373, if the obstacle vehicle is detected in front and is braking sharply (e.g., detected that the obstacle deceleration is within a predetermined threshold relative to ADV101), processing logic proceeds to block1381. At block1381, processing logic determines that a sharp brake command is to be issued. The command can be issued from any of primary ADS401, secondary ADS403, microcontroller MCU405, and/or any of CDC modules411or413.

Regarding scenarios 9-10; 21-22; 33-34; and 45-46, at block1373, if the obstacle vehicle is detected to be in front and is braking gradually (e.g., detected that the obstacle deceleration exceeds a predetermined threshold relative to ADV101), processing logic proceeds to block1383.

At block1383, processing logic determines if an obstacle pedestrian is detected in front of ADV101. If the obstacle pedestrian is in front and close by (e.g., within a predetermined threshold distance to ADV101), processing logic proceeds to block1387, and determines that a sharp brake command is to be issued. The command can be issued from any of primary ADS401, secondary ADS403, microcontroller MCU405, and/or any of CDC modules411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

Regarding scenarios 11-12; 23-24; 35-36; and 47-48, at block1383, if the obstacle pedestrian is detected in front and faraway (e.g., exceed a predetermined threshold distance), processing logic proceeds to block1389, and determines that a gradual brake command is to be issued to the primary and secondary brake units421-423of ADV101. The command can be issued from any of primary ADS401, secondary ADS403, microcontroller MCU405, and/or any of CDC modules411or413. In one embodiment, the sharp brake command is issued by a brake drive-by-wire (DBW) of a CDC module.

FIG.14is a flow diagram illustrating a method to select a brake mode according to one embodiment. Process1400may be performed by processing logic which may include software, hardware, or a combination thereof. For example, process1400may be performed by primary ADS401, secondary ADS403, primary CDC411, or second CDC413ofFIG.9.

At block1401, processing logic determines selection parameters to apply an adaptive braking scheme for an autonomous driving vehicle (ADV).

At block1403, processing logic determines a brake mode based on the selection parameters using a driving scenario mapping table.

At block1405, in response to determining that a brake is to be applied, processing logic applies a brake for the ADV according to the brake mode.

In one embodiment, the brake mode includes a gradual brake mode or a sharp brake mode.

In one embodiment, the selection parameters include a driving direction, presence of a vehicle at front of the ADV, distance to the vehicle at the front of the ADV, presence of a pedestrian at front of the ADV, distance to pedestrian, presence of a vehicle behind the ADV, or distance to the vehicle behind the ADV.

In one embodiment, the selection parameters include a status of an autonomous driving system (ADS) of the ADV.

In one embodiment, the selection parameters include a status of chassis domain controller of the ADV.

In one embodiment, the brake mode corresponds to brake commands applied in three stages, wherein the three stages include a brake pre-charge stage, an increasing rate of deceleration stage, and a constant rate of deceleration stage.

In one embodiment, the sharp brake mode corresponds to a pre-charge command corresponding to a first predetermined duration, an increasing rate of deceleration command corresponding to a first preset increasing rate of deceleration, or a constant rate of deceleration command corresponding to a first preset constant rate of deceleration.

In one embodiment, the gradual brake mode corresponds to a pre-charge command corresponding to the first predetermined duration, an increasing rate of deceleration command corresponding to a second preset increasing rate of deceleration, or a constant rate of deceleration command corresponding to the first preset constant rate of deceleration, wherein the first preset increasing rate of deceleration is great than the second preset increasing rate of deceleration.

In one embodiment, determining that a brake is to be applied includes determining the ADV has reached its destination, reached a traffic stop, or a vehicle in front of the ADV applied a brake.

In one embodiment, the autonomous driving system (ADS) of the ADV includes a primary ADS or a secondary ADS, wherein the secondary ADS is a redundant ADS.

FIG.15is a block diagram illustrating an example of redundant systems for an autonomous driving vehicle according to one embodiment. System1500can represent system400ofFIG.4. In one embodiment, primary ADS401or secondary ADS403can include secondary system activation module309. Description for various components of system1500can be referenced to system400ofFIG.4.

FIG.16is a block diagram illustrating a secondary system activation module309according to one embodiment. Secondary system activation module309can activate secondary system(s) (e.g., the primary systems/components can be activated by default) for various redundant systems/components of ADV101. In one embodiment, secondary system activation module309includes activation parameters determiner submodule1601, algorithms selection submodule1603, primary/secondary brake activation submodule1605, brake pre-charge submodule1607, and brake tracking submodule1609, steady brake submodule1611.

FIG.17is a block diagram illustrating an example of an evaluation process1700to activate primary or secondary system/components according to one embodiment. Evaluation process1700can be performed by secondary system activation module309ofFIG.16to select a primary system or a secondary system (e.g., secondary ADS, secondary CDC, secondary brake unit, etc.). As shown, ADV can obtain configuration requests1701as the activation parameters. Configuration requests1701can correspond to requests to activate the primary or the secondary systems/components. For example, an operator can input into a user interface of the ADV a request to activate either the primary or the secondary systems/components. The requests can be performed in real-time when the ADV is operating in a drive mode or when the ADV is idle in a parking/neutral transmission mode. In one embodiment, the requests can reflect a request for the next time the ADV is operated (e.g., after a system reboot).

In one embodiment, the ADV can obtain driver/passenger status1703as the activation parameters. Example of the driver/passenger status1703can be a number of passengers onboard the ADV and whether there is an operator. In one embodiment, the ADV can obtain vehicle status1705as the activation parameters. Vehicle status can include a current speed of the vehicle, vehicle mass, health indicators (e.g., whether there are dashboard warning lights), and/or traction of the vehicle tire. In one embodiment, the ADV can obtain environmental status1707as the activation parameters. Environmental status1707can include current road friction, current weather conditions (raining, sunny, or snowing conditions, etc.), current slope steepness of the road, how many and/or types of obstacles are detected by imaging sensors of the ADV.

In one embodiment, the ADV can obtain failure data1709as the activation parameters. Failure data1709can indicate which systems are failing or a duration and error level associated with a previous failure. For example, the failing data can include dashboard warning indicators, sensor errors, software errors with the control/planning systems of the ADS, CAN bus error codes, CDC error codes, and/or failure/safety level codes as shown in the example scenarios 1-51 ofFIGS.12A-12E, e.g., failure level F0/F1/F2/F3/F4. In one embodiment, ADV can obtain historical data1711as the activation parameters. Historical data1711can include historical usage statistics of the different primary and secondary systems/components. The historical usage statistics can be a collection of the operating durations (e.g., time with powered on) of the respective systems/components.

In one embodiment, ADV can select an activation algorithm from a plurality of algorithms to process the inputs1701-1711. In an embodiment, the activation algorithm can be a weighted sum, where each category of inputs is multiplied by a respective weighting factor, e.g., W1-W6 and the sum of the outputs are compared with a predetermined threshold. If the weighted sum is greater than the predetermined threshold, a secondary system is activated. Else, the primary system is activated. In one embodiment, each input in a category of inputs have a different weighting factor. In one embodiment, the activation can be performed by the primary or secondary ADS in real-time, e.g., the primary system is switched over to the secondary system, or vice versa, when ADV is in a driving mode. In another embodiment, the activation occurs when ADV evaluates that it is safe to do so, e.g., when ADV detects that the ADV in a parking/neural transmission mode.

In one embodiment, process1700can be applied for each pair of primary and secondary subsystems/components to determine which of the primary/secondary subsystems/components would be activated. Each evaluation can be configured with a particular subset of inputs1701-1711relevant to the subsystem/component. The relevant subset of inputs can be preconfigured for each set of primary/secondary system/component. For example, to evaluate which of the primary/secondary brake units to activate, the inputs1701-1711can include: configuration requests from operator regarding a selection for the primary or secondary CDC, failure data regarding the primary/second brake units, warning indicators regarding brake fluids and/or brake pad conditions, how many passengers are onboard the ADV (e.g., detected by seatbelt detectors), vehicle weight status, condition of the road (rural, city, or highway), weather (raining, snowing, or sunny), and/or obstacles (vehicle in front, vehicle following behind, pedestrian crossing), etc. These inputs can be processed by a selection algorithm to activate the primary or the secondary brake unit.

In some embodiments, the plurality of activation algorithms can include an alternating algorithm. The alternating algorithm can alternatingly operate the primary or the secondary system at the start of the ADS of ADV. E.g., when the ADV engine is started/ADS system boots up. In one embodiment, the plurality of activation algorithms can include an algorithm to activate the primary subsystem or the secondary subsystem so each of the systems are operating, on average, a same number of operating hours.

In one embodiment, the plurality of activation algorithms can include an algorithm to activate the secondary subsystems for a minimum number of counts within a predetermined time period (e.g., a year).

FIGS.18A-18Bare block diagrams illustrating examples of activation configurations1800-1810according to some embodiments. For configurations1800-1810, solid lines denote activated subsystems/components while dashed lines denote non-activated subsystems/components. In some embodiments, the non-activated systems are operational but their output signals are not routed to the next components for processing. In some embodiments, the non-activated systems are powered down. Referring toFIG.18A, configuration1800includes activated primary ADS401to send command/signals to activated secondary CDC413. The secondary CDC413processes commands/signals and submits signals to the activated secondary units, e.g., brake unit423, steer unit433, throttle unit443to control ADV101.

Referring toFIG.18B, in another embodiment, configuration1800includes activated secondary ADS401operating to send commands/signals to activated secondary CDC413. The secondary CDC413processes the commands/signals and submits signals to the activated primary units, e.g., brake unit421, steer unit431, throttle unit441to control ADV101. Although two configurations are shown inFIGS.18A-18Bfor illustration purposes, other combinations of primary/secondary activation configurations are possible.

FIG.19is a block diagram illustrating examples of different activation paths for various subsystems/components of the autonomous driving vehicle according to one embodiment. ReferringFIG.19, system1900can represent ADV101ofFIG.1. ADV101can include various sub-systems/components. For example, system1900can include primary/secondary ADS systems401-403, primary/secondary sensor systems1921/1923, primary/secondary control systems1931-1933, primary/secondary CDCs411-413, primary/secondary braking, steering, and throttle units1951-1953, primary/secondary sensors1961-1963, and primary/secondary power systems1971-1973. Note that primary/secondary sensor systems1921/1923can represent sensor system115ofFIG.3A, primary/secondary control systems1931-1933can represent control system111ofFIG.3A, primary/secondary sensors1961-1963can represent sensors211-215ofFIG.2, and primary/secondary power systems1971-1973can represent separate power supplies that powers the corresponding primary/secondary systems. Note that the braking, steering, and throttle systems1951-1953can represent units421-443ofFIG.15. In some embodiments, units421-443can include braking-by-wire, steering-by-wire, and/or throttle-by-wire systems.

As depicted inFIG.19, each of the primary/secondary systems/components can be evaluated for activation using an activation algorithm, such as by process1700ofFIG.17. Here, the arrows of the primary/secondary systems denote the different possible paths/combinations for different activation configurations. An example activated configuration (e.g., configuration path) can be primary ADS401, primary sensor system1921with primary sensors1961, primary control system1931, primary CDC411, and primary braking, steering, and throttle units1951, and primary power system1971. Another example activated configuration (e.g., configuration path) can be secondary ADS403, secondary sensor system1923with secondary sensors1963, secondary control system1933, secondary CDC413, and secondary braking, steering, and throttle units1953, and secondary power system1973. Another example activated configuration (e.g., configuration path) can be primary ADS401, secondary sensor system1923with secondary sensors1963, secondary control system1933, secondary CDC413, and secondary braking, steering, and throttle units1953, and secondary power system1973. From the five primary/secondary systems/components, the number of different configurations can be 2{circumflex over ( )}5=32. Although not shown, other subsystems and/or secondary domain controllers (e.g., powertrain domain, body domain, entertainment domain, etc.)/systems can be similarly processed for activation.

FIG.20is a flow diagram illustrating a method to activate a primary or a second system according to one embodiment. Process2000may be performed by processing logic which may include software, hardware, or a combination thereof. For example, process2000may be performed by primary ADS401or secondary ADS403ofFIG.15.

At block2001, processing logic determines activation parameters for an autonomous driving vehicle (ADV), wherein the activation parameters include historical usages of a primary brake system or a secondary brake system.

At block2003, in response to determining that a brake is to be applied, processing logic determines whether to activate a primary or a secondary brake system based on the activation parameters.

The determination can be performed in real-time when the ADV is in a driving mode or when the ADV is in a parking/neutral transmission mode. For example, the ADV can process the activation parameters with an activation algorithm to determine which system to activate.

At block2005, processing logic sends an activation flag to activate the primary or the secondary brake system based on the determining whether to activate the primary or the secondary brake system.

For example, the activation flag can be sent to the CAN bus as an instruction to activate either the primary or the secondary brake system. The activation flag can include one or more bits in a bit map, each bit mapping to a primary/secondary sub-system for the activation.

At block2007, processing logic sends a brake command to the primary and the secondary brake system to activate either the primary or the secondary brake system according to the activation flag. Here, at a command cycle, only one brake system (primary or secondary brake system) is active and can thus be triggered.

In one embodiment, the activation parameters include a plurality of safety factors including a count of passengers in the ADV, a safety status of an environment surrounding the ADV, or a vehicular status of the ADV.

In one embodiment, a safety status of the environment surrounding the ADV includes a traction of a road of the ADV, weather, or a slope of the road.

In one embodiment, the vehicle status of the ADV includes a current speed, a weight of the ADV, a health status of an autonomous driving system (ADS) of the ADV, or a health status of the primary or secondary brake system, or a tire traction of the ADV.

In one embodiment, the activation parameters further comprise a failure rate of an autonomous driving system (ADS) of the ADV.

In one embodiment, the activation parameters are inserted into a gain matrix to obtain a weighted sum value and whether to activate the primary or the secondary brake system is based on the weighted sum value.

In one embodiment, the secondary brake system is activated if the weighted sum value is greater than a predetermined threshold and the primary brake system is activated if the weighted sum value is less than or equal to the predetermined threshold.

In one embodiment, activating the primary or secondary brake systems includes activating the primary or secondary chassis domain controller to issue the commands to either the primary or secondary brake system.

In one embodiment, activating the primary or secondary brake system includes activating the primary or secondary by-wire systems.

In one embodiment, the primary or secondary by-wire systems include a primary or a secondary steer by-wire system, a primary or a secondary throttle by-wire system, or a primary or a secondary transmission-by-wire system.

In one embodiment, the primary or secondary brake system includes a primary or a secondary brake by-wire system.