CN118254813A

CN118254813A - Method and device for a vehicle

Info

Publication number: CN118254813A
Application number: CN202211690085.1A
Authority: CN
Inventors: 龚轶凡; 隋清宇
Original assignee: Beijing Tusimple Technology Co Ltd
Current assignee: Beijing Tusimple Technology Co Ltd
Priority date: 2022-12-27
Filing date: 2022-12-27
Publication date: 2024-06-28
Also published as: WO2024139836A1

Abstract

The present disclosure relates to a method and apparatus for a vehicle. The vehicle includes a plurality of processing nodes and is operable in response to a target system state entering a set of system states. The method comprises the following steps: acquiring at least one status report of each processing node of the plurality of processing nodes, each status report indicating whether a respective one of the processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic would result in one or more system states of the set of system states being unavailable according to the mapping relationship; generating an aggregate state based on the mapping relationship and a status report of a subset of processing logic of the plurality of processing nodes involved in the current task of the vehicle, wherein the aggregate state indicates a respective availability of each of a set of system states; and determining a target system state of a set of system states to be entered by the vehicle under the current task based on the aggregated state.

Description

Method and device for a vehicle

Technical Field

The present disclosure relates to the field of intelligent transportation, and in particular to automated driving technology, and in particular to a method, apparatus, electronic device, vehicle, computer readable storage medium and computer program product for a vehicle.

Background

At present, with the development of traffic intelligence, more and more traditional automobile manufacturers and high-tech companies are put into the study of vehicle automatic driving. An important part of autopilot research is autopilot human-machine interaction.

The basic requirements of automatic driving human-computer interaction include that when a user cannot respond to a take-over request sent by a driving automation system in time, the driving automation system should execute a minimum risk strategy (MINIMAL RISK Maneuver, MRM) so as to ensure safe operation of the vehicle. According to relevant criteria, an MRM is defined as a risk-reducing measure taken by a driving automation system when the driving automation system or a user cannot perform a dynamic driving task (DYNAMIC DRIVING TASK, DDT) or a dynamic driving task takeover (DDT fallback). According to the definition of MRM, the aim of executing MRM is to guarantee safe operation of the vehicle, which aims at bringing the vehicle into a minimum risk state (MINIMAL RISK Condition, MRC). In other words, in an autopilot human-machine interaction, when a user cannot take over a driving task in time, the system should be able to automatically execute the MRM in order to get the vehicle into the MRC. MRC may be defined as a state that is executed by a user or a driving automation system and ultimately brings the risk of a vehicle accident to an acceptable state when the vehicle fails to complete a predetermined trip.

It is an important task of autopilot research to how improved mechanisms can be designed to ensure that vehicles smoothly enter the MRC when performing the MRM.

Disclosure of Invention

In view of the foregoing technical problems, the present disclosure provides a method, an apparatus, an electronic device, a vehicle, a computer-readable storage medium, and a computer program product for a vehicle.

According to one aspect of the present disclosure, there is provided a method for a vehicle comprising a plurality of processing nodes, the vehicle being operable in response to a target system state entering a set of system states, the method comprising: acquiring at least one status report of each processing node of the plurality of processing nodes, each status report indicating that a respective one of the processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic would result in one or more system states of the set of system states being unavailable according to a mapping relationship; generating an aggregate state based on the mapping and a status report of a subset of processing logic of the plurality of processing nodes involved in the current task of the vehicle, wherein the aggregate state indicates a respective availability of each of the set of system states; and determining the target system state of the set of system states to which the vehicle is to enter under the current task based on the aggregated state.

According to another aspect of the present disclosure, there is provided an apparatus for a vehicle comprising a plurality of processing nodes, the vehicle being operable in response to a target system state entering a set of system states, the apparatus comprising: a first module for obtaining at least one status report for each of the plurality of processing nodes, each status report indicating that a respective one of the processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic would result in one or more of the set of system states being unavailable according to a mapping relationship; a second module for generating an aggregate state based on the mapping and a status report of a subset of processing logic of the plurality of processing nodes involved in a current task of the vehicle, wherein the aggregate state indicates a respective availability of each of the set of system states; and a third module for determining the target system state of the set of system states to be entered by the vehicle under the current task based on the aggregated state.

According to another aspect of the present disclosure, there is provided an electronic device including: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the methods described in the present disclosure.

According to another aspect of the present disclosure, there is provided a vehicle operable in response to a target system state entering a set of system states, the vehicle comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the methods described in the present disclosure.

According to another aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the present disclosure.

In accordance with one or more embodiments of the present disclosure, methods and apparatus for a vehicle provide a target system state of a set of system states that the vehicle is to enter at a current mission. By acquiring the status report of each processing node of the vehicle, an aggregate status indicating the availability of the system status can be generated based on the mapping relation and the current task information of the vehicle, so that the target system status is determined, the risk of the vehicle accident can reach an acceptable status under the condition that one or more of the processing nodes of the vehicle are abnormal, and the running safety of the vehicle is ensured.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The accompanying drawings illustrate exemplary embodiments and, together with the description, serve to explain exemplary implementations of the embodiments. The illustrated embodiments are for exemplary purposes only and do not limit the scope of the claims. Throughout the drawings, identical reference numerals designate similar, but not necessarily identical, elements.

FIG. 1 illustrates a schematic diagram of a vehicle in which various techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure;

FIG. 2 illustrates a flow chart of a method for a vehicle according to an embodiment of the present disclosure;

FIG. 3 illustrates a schematic structural diagram of an exemplary vehicle according to an embodiment of the present disclosure;

FIG. 4 shows a schematic diagram of an exemplary truth table according to an embodiment of the present disclosure;

FIG. 5 shows a block diagram of an apparatus for a vehicle according to an embodiment of the disclosure;

Fig. 6 illustrates a block diagram of an exemplary computing device, according to an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

In the present disclosure, unless otherwise indicated, the terms "first," "second," and the like are used to describe various elements and are not intended to limit the positional relationship, timing relationship, or importance of these elements, but are merely used to distinguish one element from another. In some examples, a first element and a second element may refer to the same instance of the element, and in some cases, they may also refer to different instances based on the description of the context.

The terminology used in the description of the various illustrated examples in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context clearly indicates otherwise, the elements may be one or more if the number of the elements is not specifically limited. Furthermore, the term "and/or" as used in this disclosure encompasses any and all possible combinations of the listed items.

In the description of the various examples in this disclosure, the term "vehicle" is to be construed broadly in this disclosure to include any moving object, including, for example, automobiles, trucks, vans, semitrailers, golf carts, off-road vehicles, warehouse transportation vehicles or agricultural vehicles, as well as vehicles traveling on rails, such as trains or buses, and other rail vehicles.

A vehicle in the related art may include a plurality of processing nodes, each of which may manage a respective logic functionality, e.g., sensing, positioning, decision making, control, etc. Some of these processing nodes may have fault tolerance capabilities. When such processing nodes experience anomalies (e.g., transient anomalies), the normal operation of the other processing nodes is not affected. However, other processing nodes do not have fault tolerance. Thus, once such processing nodes are abnormal, the safe operation of the entire vehicle is affected, and the vehicle needs to be urgently switched into an emergency state. In addition, the importance levels of the different processing nodes are also significantly different. For example, for a camera, although an abnormal condition may cause deviation of a sensing result, the deviation may be corrected by data of other cameras so as not to affect safe operation of the whole vehicle. For example, there may be a processing node (e.g., a camera processing node) with sensing functionality, an abnormal condition of which would cause the vehicle to fail to function properly but still be parked slowly. For example, there may be processing nodes with decision-making functionality (e.g., path planning processing nodes), abnormal conditions of which would cause the vehicle to fail to function properly and must immediately scram, etc.

In the related art, the different processing nodes each have a difference in fault tolerance capability, own functional logic, importance level with respect to safe operation of the vehicle, and the like, so that it is impossible to determine a target system state on the whole vehicle level when an abnormality occurs in a certain processing node(s) of the vehicle to bring the vehicle into MRC (for example, emergency stop should be immediately performed when a processing node suddenly abnormal or normal operation should be continued for a period of time to wait for the processing node to recover, stop should be immediately performed sideways when a certain processing node(s) is abnormal, and the like), thereby making it difficult to secure operation of the vehicle.

In this regard, the present disclosure provides methods and apparatus for a vehicle to provide the vehicle with a target system state from a set of system states to be entered at a current mission. By acquiring the status report of each processing node of the vehicle, an aggregate status indicating the availability of the system status can be generated based on the mapping relation and the current task information of the vehicle, so that the target system status is determined, the risk of the vehicle accident can reach an acceptable status under the condition that one or more of the processing nodes of the vehicle are abnormal, and the running safety of the vehicle is ensured.

Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

FIG. 1 is a schematic diagram of a vehicle 100 in which various techniques disclosed herein may be implemented. The vehicle 100 may be a car, truck, motorcycle, bus, watercraft, aircraft, helicopter, mower, excavator, snowmobile, aircraft, recreational vehicle, amusement park vehicle, farm device, construction device, tram, golf car, train, trolley car, or other vehicle. The vehicle 100 may operate in an autonomous mode, either entirely or partially. The vehicle 100 may control itself in the automatic driving mode, for example, the vehicle 100 may determine a current state of the vehicle and a current state of an environment in which the vehicle is located, determine a predicted behavior of at least one other vehicle in the environment, determine a trust level corresponding to a likelihood that the at least one other vehicle will perform the predicted behavior, and control the vehicle 100 itself based on the determined information. While in the autonomous mode, the vehicle 100 may operate without human interaction.

Vehicle 100 may include various vehicle systems such as a drive system 142, a sensor system 144, a control system 146, a user interface system 148, a computing system 150, and a communication system 152. Vehicle 100 may include more or fewer systems, each of which may include multiple units. Further, each system and unit of the vehicle 100 may be interconnected. For example, the computing system 150 can be in data communication with one or more of the drive system 142, the sensor system 144, the control system 146, the user interface system 148, and the communication system 152. Thus, one or more of the described functions of the vehicle 100 may be divided into additional functional or physical components or combined into a fewer number of functional or physical components. In a further example, additional functional or physical components may be added to the example shown in fig. 1.

The drive system 142 may include a plurality of operable components (or units) that provide kinetic energy to the vehicle 100. In one embodiment, the drive system 142 may include an engine or motor, wheels, a transmission, an electronic system, and a power source. The engine or motor may be any combination of the following: internal combustion engines, electric machines, steam engines, fuel cell engines, propane engines, or other forms of engines or electric motors. In some embodiments, the engine may convert a source of power into mechanical energy. In some embodiments, the drive system 142 may include a variety of motors or motors. For example, a hybrid electric vehicle may include a gasoline engine and an electric motor, as well as other situations.

The wheels of the vehicle 100 may be standard wheels. The wheels of the vehicle 100 may be in the form of wheels of a variety of types including single, double, three, or four wheels, such as on a car or truck. Other numbers of wheels are possible, such as six or more wheels. One or more wheels of the vehicle 100 may be operated in a different direction of rotation than the other wheels. The wheel may be at least one wheel fixedly connected to the transmission. The wheel may comprise a combination of metal and rubber, or other materials. The transmission may include a unit operable to transmit mechanical power of the engine to the wheels. For this purpose, the transmission may include a gearbox, clutches, differential gears, and drive shafts. The transmission may also include other units. The drive shaft may include one or more axles that mate with the wheels. The electronic system may include a unit for transmitting or controlling electronic signals of the vehicle 100. These electronic signals may be used to activate a plurality of lights, a plurality of servos, a plurality of motors, and other electronic driving or control devices in the vehicle 100. The power source may be an energy source that wholly or partially powers an engine or an electric motor. That is, the engine or motor is capable of converting a power source into mechanical energy. By way of example, the power source may include gasoline, petroleum-based fuels, propane, other compressed gas fuels, ethanol, fuel cells, solar panels, batteries, and other sources of electrical energy. The power source may additionally or alternatively include a fuel tank, a battery, a capacitor, or any combination of flywheels. The power source may also provide energy to other systems of the vehicle 100.

The sensor system 144 may include a plurality of sensors for sensing information of the environment and conditions of the vehicle 100. For example, the sensor system 144 may include an Inertial Measurement Unit (IMU), a GNSS (global navigation satellite system) transceiver (e.g., a Global Positioning System (GPS) transceiver), RADAR (RADAR), laser rangefinder/LIDAR (or other distance measurement device), an acoustic sensor, an ultrasonic sensor, and a camera or image capture device. The sensor system 144 may include a plurality of sensors (e.g., oxygen (O2) monitors, fuel gauge sensors, engine oil pressure sensors, and temperature, humidity, pressure sensors, etc.) for monitoring the vehicle 100. Other sensors may also be configured. One or more sensors included in sensor system 144 may be driven individually or collectively to update the position, orientation, or both of the one or more sensors.

The IMU may include a combination of sensors (e.g., an accelerator and a gyroscope) for sensing positional and directional changes of the vehicle 100 based on inertial acceleration. The GPS transceiver may be any sensor for estimating the geographic location of the vehicle 100. For this purpose, the GPS transceiver may include a receiver/transmitter to provide positional information of the vehicle 100 relative to the earth. It should be noted that GPS is an example of a global navigation satellite system, and thus, in some embodiments, the GPS transceiver may be replaced with a beidou satellite navigation system transceiver or a galileo satellite navigation system transceiver. The radar unit may use radio signals to sense objects in the environment of the vehicle 100. In some embodiments, the radar unit may be used to sense the speed and heading of an object approaching the vehicle 100 in addition to sensing the object. The laser rangefinder or LIDAR unit (or other distance measurement device) may be any sensor that uses a laser to sense objects in the environment of the vehicle 100. In one embodiment, the laser range finder/LIDAR unit may include a laser source, a laser scanner, and a detector. The laser rangefinder/LIDAR unit is configured to operate in either a continuous (e.g., using heterodyne detection) or discontinuous detection mode. The camera may include means for capturing a plurality of images of the environment in which the vehicle 100 is located. The camera may be a still image camera or a dynamic video camera.

The control system 146 is used to control operation of the vehicle 100 and its components (or units). Accordingly, the control system 146 may include various units such as a steering unit, a power control unit, a braking unit, and a navigation unit.

The steering unit may be a combination of machines that adjust the direction of travel of the vehicle 100. The power control unit (which may be, for example, an accelerator) may be used to control the operating speed of the engine, and thus the speed of the vehicle 100, for example. The braking unit may include a combination of machines for decelerating the vehicle 100. The brake unit may utilize friction to slow the vehicle in a standard manner. In other embodiments, the braking unit may convert the kinetic energy of the wheels into electric current. The brake unit may take other forms as well. The navigation unit may be any system that determines a driving path or route for the vehicle 100. The navigation unit may also dynamically update the driving path during travel of the vehicle 100. The control system 146 may additionally or alternatively include other components (or units) not shown or described.

The user interface system 148 may be used to allow interaction between the vehicle 100 and external sensors, other vehicles, other computing systems, and/or users of the vehicle 100. For example, the user interface system 148 may include a standard visual display device (e.g., a plasma display, liquid Crystal Display (LCD), touch screen display, head mounted display, or other similar display), a speaker or other audio output device, a microphone, or other audio input device. For example, the user interface system 148 may also include a navigation interface and an interface to control the internal environment (e.g., temperature, fans, etc.) of the vehicle 100.

The communication system 152 may provide a means for the vehicle 100 to communicate with one or more devices or other vehicles in the vicinity. In an exemplary embodiment, the communication system 152 may communicate with one or more devices directly or through a communication network. The communication system 152 may be, for example, a wireless communication system. For example, the communication system may use 3G cellular communication (e.g., CDMA, EVDO, GSM/GPRS) or 4G cellular communication (e.g., wiMAX or LTE), and may also use 5G cellular communication. Alternatively, the communication system may communicate with a Wireless Local Area Network (WLAN) (e.g., using). In some embodiments, the communication system 152 may communicate directly with one or more devices or other vehicles in the vicinity, for example, using infrared light,Or ZIGBEE. Other wireless protocols, such as various vehicle-mounted communication systems, are also within the scope of the present disclosure. For example, the communication system may include one or more Dedicated Short Range Communication (DSRC) devices, V2V devices, or V2X devices that may communicate public or private data with the vehicle and/or roadside station.

The computing system 150 can control some or all of the functions of the vehicle 100. An autopilot control unit in the computing system 150 may be used to identify, evaluate, and avoid or override potential obstacles in the environment in which the vehicle 100 is located. In general, an autopilot control unit may be used to control the vehicle 100 without a driver or to provide assistance to the driver in controlling the vehicle. In some embodiments, the autopilot control unit is used to combine data from the GPS transceiver, radar data, LIDAR data, camera data, and data from other vehicle systems to determine the path or trajectory of travel of the vehicle 100. The autopilot control unit may be activated to enable the vehicle 100 to be driven in an autopilot mode.

Computing system 150 may include at least one processor (which may include at least one microprocessor) that executes processing instructions (i.e., machine-executable instructions) stored in a non-volatile computer-readable medium (e.g., data storage or memory). The computing system 150 may also be a plurality of computing devices that control components or systems of the vehicle 100 in a distributed manner. In some embodiments, the memory may contain processing instructions (e.g., program logic) that are executed by the processor to implement various functions of the vehicle 100. In one embodiment, the computing system 150 is capable of data communication with the drive system 142, the sensor system 144, the control system 146, the user interface system 148, and/or the communication system 152. Interfaces in the computing system are used to facilitate data communications between the computing system 150 and the drive system 142, the sensor system 144, the control system 146, the user interface system 148, and the communication system 152.

The memory may also include other instructions, including instructions for data transmission, instructions for data reception, instructions for interaction, or instructions for controlling the drive system 142, the sensor system 144, or the control system 146 or the user interface system 148.

In addition to storing processing instructions, the memory may store a variety of information or data, such as image processing parameters, road maps, and path information. Such information may be used by the vehicle 100 and the computing system 150 during operation of the vehicle 100 in an automated, semi-automated, and/or manual mode.

Although the autopilot control unit is shown as separate from the processor and memory, it should be understood that in some embodiments, some or all of the functionality of the autopilot control unit may be implemented with program code instructions residing in and executed by one or more processors and that the autopilot control unit may in some cases be implemented using the same processor and/or memory (or data storage). In some embodiments, the autopilot control unit may be implemented at least in part using various dedicated circuit logic, various processors, various field programmable gate arrays ("FPGAs"), various application specific integrated circuits ("ASICs"), various real-time controllers, and hardware.

The computing system 150 may control functions of the vehicle 100 based on inputs received from various vehicle systems (e.g., the drive system 142, the sensor system 144, and the control system 146), or inputs received from the user interface system 148. For example, the computing system 150 may use input from the control system 146 to control the steering unit to avoid obstacles detected by the sensor system 144. In one embodiment, the computing system 150 may be used to control aspects of the vehicle 100 and its systems.

Although various components (or units) integrated into vehicle 100 are shown in fig. 1, one or more of these components (or units) may be onboard vehicle 100 or separately associated with vehicle 100. For example, the computing system may exist partially or wholly independent of the vehicle 100. Thus, the vehicle 100 may exist as a separate or integrated equipment unit. The device units constituting the vehicle 100 may communicate with each other in a wired communication or a wireless communication. In some embodiments, additional components or units may be added to or removed from the various systems (e.g., liDAR or radar as shown in FIG. 1).

The system 100 of fig. 1 may be configured and operated in various ways to enable application of the methods for a vehicle described in accordance with the present disclosure and systems for a vehicle described in accordance with the present disclosure.

In this document, when referring to the term vehicle, it may refer to any suitable type of vehicle, such as an autonomous vehicle, an unmanned vehicle, a assisted driving vehicle, and the like. That is, the inventive concepts of the present disclosure may be applied to any suitable type of vehicle including autonomous vehicles, unmanned vehicles, assisted driving vehicles, and the like, and the present disclosure is not intended to be limited in type of vehicle.

According to one aspect of the present disclosure, a method for a vehicle is first provided. Fig. 2 shows a flow chart of a method 200 for a vehicle according to an embodiment of the disclosure.

According to embodiments of the present disclosure, a vehicle may include one or more processing nodes.

As used herein, the term "processing node" may refer to a program module having corresponding functionality. Such program modules may be associated with hardware entities such that the term "processing node" may be regarded as a process, sub-process, controller, object, executable, routine, program, software, etc. running on the respective hardware entity or any combination thereof for carrying out or carrying the functions of the respective hardware entity. A hardware entity may refer to a component, circuit, interface, firmware (e.g., an erasable programmable read-only memory (EPROM) or an electrically erasable programmable read-only memory (EEPROM) with programs written thereon), device, module, subsystem, etc. related to computing and/or communication capabilities. Of course, the processing nodes may not be associated with any hardware entities, which the present disclosure does not impose as such.

According to embodiments of the present disclosure, a vehicle may operate in response to a target system state entering a set of system states.

In some embodiments, a set of system states of the vehicle may be predefined.

In some embodiments, a set of system states of the vehicle may be associated with a minimum risk policy (MRM), in the sense that the set of system states of the vehicle may refer to a set of selectable system states that the vehicle may take in order to be able to achieve a minimum risk state MRC when the vehicle is unable to perform a Dynamic Driving Task (DDT) or a user of the vehicle is unable to perform a dynamic driving task takeover (DDT fallback). By way of example and not limitation, when the target system state is normally operable, the vehicle may continue to complete a predetermined trip in response to entering the target system state, e.g., continue traveling along a navigation path to a destination, continue completing parking of the vehicle along a parking plan path, continue stationary traveling within a vehicle speed interval in cruise mode, and so forth.

As shown in fig. 2, the method 200 includes the steps of:

Step S210, obtaining at least one status report of each processing node in the plurality of processing nodes, wherein each status report indicates that the corresponding one of the processing logic of the processing node is in a normal state or an abnormal state, and the abnormal state of each processing logic causes one or more system states in a group of system states to be unavailable according to the mapping relation;

Step S220, generating an aggregation state based on the mapping relation and the state reports of the processing logic subsets of the plurality of processing nodes related to the current task of the vehicle, wherein the aggregation state indicates the availability of each system state in a group of system states; and

Step S230, determining a target system state of a set of system states to be entered by the vehicle under the current task based on the aggregated state.

The various steps of method 200 are described in detail below.

In step S210, it may be preferred to obtain at least one status report for each of the plurality of processing nodes.

In some embodiments, each processing node may include one or more status reports. For a status report of a processing node, the status report may correspond to a processing logic of the processing node. That is, one processing node may include more than one processing logic. By way of example and not limitation, for camera processing node camera0 having sensing functionality, it may include two processing logics, camera0_ healthy and camera0_node, where camera0_ healthy may be used to indicate whether the sensing functionality of the camera is normal, and camera0_node may be used to indicate whether the camera processing node is normal (e.g., whether the camera processing node is in communication with other processing nodes, etc.).

As used herein, the term "processing logic" may refer to a logical representation of a state that describes functionality implemented by a processing node and/or capabilities of the processing node itself (e.g., communication capabilities, computing capabilities, etc.). Along with the example of processing node camera0 with the above-described cameras, processing logic camera0_ healthy may describe the state of sensing functionality implemented by camera processing node camera0, while processing logic camera0_node may describe the state of the capabilities of camera processing node camera0 itself (e.g., in electrical communication with other processing nodes to, for example, draw power from a power supply node and/or transfer captured image frames to a downstream processing node, etc.).

In some embodiments, each status report may indicate whether a respective one of the processing logic of the processing node is normal (i.e., whether the processing logic is in a normal state or in an abnormal state).

In some embodiments, each status report may include one processing logic of the processing node and its corresponding status.

In some embodiments, the state of the processing logic may be represented by binary logic (e.g., boolean value true/false), ternary logic, n-value logic, etc., which is not subject to any limitation by the present disclosure.

In some embodiments, the state of the processing logic may include at least an exception state that indicates that the processing logic is experiencing an exception condition.

By way of example and not limitation, status report(s) for each processing node may be generated in real-time upon being acquired. Accordingly, the state of one processing logic of the processing node indicated by each acquired status report is a real-time state. As another example, the status report(s) for each processing node may be generated at predetermined time intervals (e.g., 20ms time intervals). Accordingly, the state of one processing logic of the processing node indicated by each acquired status report is a historical state. In the latter case, each status report may additionally include a time stamp of the generation of the status report for comparison with the current time to determine the validity of the historical status of the processing logic included in the status report, particularly if the historical status indicates that the processing logic is in a normal state.

In some embodiments, for more than one processing logic included with each processing node, the mapping may identify which system state(s) will be unavailable when an exception condition occurs with each processing logic.

According to embodiments of the present disclosure, the mapping relationship can reflect the reason that the corresponding system state is not available with fine granularity of processing logic.

According to embodiments of the present disclosure, the exception state of each processing logic may result in one or more system states in a set of system states being unavailable, depending on the mapping relationship.

In some embodiments, for a plurality of processing logic included in the same processing node, the exception state of each processing logic may result in a different system state in a set of system states being unavailable.

By way of example and not limitation, assume that there is a set of predefined system states [ a, b, c ] and a processing Node0, where Node0 includes two processing logics, denoted as Node0_Logic0 and Node0_Logic1, respectively. Thus, depending on mapping A, an abnormal state of Node0_Logic0 can result in system state a being unavailable, while an abnormal state of Node0_Logic1 can result in system state b being unavailable. Alternatively, depending on another mapping relationship B, an abnormal state of Node0_logic0 may result in system state a being unavailable, while an abnormal state of Node0_logic1 may result in system states a and B being unavailable. Alternatively, depending on another mapping relation C, an abnormal state of Node0_logic0 may result in system state a being unavailable, while an abnormal state of Node0_logic1 may result in system state C being unavailable.

In some embodiments, for a plurality of processing logic included in the same processing node, the exception state of each processing logic may cause the same system state(s) in a set of system states to be unavailable.

It should be noted that the examples described above are described for illustrative purposes only and are not intended to be limiting in any way.

According to an embodiment of the present disclosure, for a vehicle there is only a unique mapping relationship for establishing a mapping between the abnormal state of the processing logic of the processing node and the unavailability of the corresponding system state of the vehicle.

In step S220, an aggregate state may be generated based on the mapping relationship and the status reports of the subset of processing logic of the plurality of processing nodes involved in the current task of the vehicle.

By way of example and not limitation, vehicle tasks (e.g., current tasks) may include highway section travel tasks, non-highway section travel tasks, parking tasks, reversing tasks, loading and unloading tasks, and so forth.

It will be appreciated that the current task of the vehicle may be further subdivided according to the preferences of the vehicle user and/or vehicle performance (including, but not limited to, the vehicle's autopilot level, the vehicle's autopilot functionality), etc., which the present disclosure does not impose any limitation. For example, the high-speed road section travel task may be subdivided into a constant-speed-cruise travel task, an adaptive-cruise travel task, and the like. For example, the non-highway section travel task may be subdivided into an urban road travel task, a rural road travel task, a factory and mine road travel task, and the like. For example, parking tasks may be subdivided into in-parking-lot parking tasks, roadside parking tasks, emergency parking tasks, and the like.

In some embodiments, the subset of processing logic of the plurality of processing nodes to which the current task relates may include some or all of the processing logic of each of the one or more processing nodes of the plurality of processing nodes of the vehicle associated with the current task.

According to embodiments of the present disclosure, the aggregate state may indicate the availability of each of a set of system states.

In some embodiments, the available system states indicated by the aggregate state may serve as candidate system states for the target system state.

In step S230, a target system state of a set of system states to be entered by the vehicle under the current task may be determined based on the aggregated state.

In some examples, the target system state to be entered by the vehicle at the current mission may be determined by a lower computer of the vehicle (e.g., vehicle control unit VCU) based on the aggregate state along with a state (e.g., historical state, real-time state, etc.) of a transmission of the vehicle (e.g., brake, drive, steering, etc.). For example, when the aggregate status indicates that system status 1 "normal running" and system status 2 "slow-to-park" are available, the lower computer of the vehicle may take the aggregate status into account with the status of the vehicle transmission (e.g., the brake warning light is illuminated) to determine that the vehicle will enter system status 2 (i.e., slow-to-park) under the current mission in order to perform a safety check on the vehicle's brakes to prevent a more dangerous condition from occurring. For another example, when the aggregate status indicates that system status 2 "reliable side slow park" and system status 3 "emergency brake" are available, the lower computer of the vehicle may take the aggregate status into account with the status of the vehicle drive (e.g., the steering wheel warning lights are illuminated) to determine that the vehicle will enter system status 3 (i.e., emergency brake) under the current mission in order to immediately call for vehicle emergency services, preventing vehicle rollover due to a malfunction of the steering device that may occur at any time.

According to an embodiment of the present disclosure, the target system state refers to the system state that the vehicle is to take in order to be able to achieve the minimum risk state MRC taking into account the state of all processing logic involved in the current task.

In accordance with embodiments of the present disclosure, the above-described method 200 provides a new method for a vehicle to provide the vehicle with a target system state from a set of system states to be entered at the current mission, in view of the defect in the related art that the target system state cannot be determined at the level of the entire vehicle to cause the vehicle to enter the MRC when an abnormality occurs in a certain processing node(s) of the vehicle.

By means of the method 200, by acquiring a status report of each processing node of the vehicle, an aggregate status indicating the availability of the system status can be generated based on the mapping relationship and the current task information of the vehicle, so as to determine the target system status, enable the risk of vehicle accidents to reach an acceptable status in case of abnormality of one or more of the processing nodes of the vehicle, and ensure the safety of vehicle operation.

The inventors have appreciated that when a vehicle is serviced or an onboard system is upgraded, a subset of the processing logic associated with a particular vehicle task may change, for example, due to the addition, deletion, replacement, modification, upgrade, etc. of components, circuits, interfaces, firmware, devices, modules, subsystems, etc. of the vehicle. By way of example and not limitation, where a lidar component is newly added to a vehicle, vehicle tasks (e.g., highway section travel tasks, non-highway section travel tasks, parking tasks, etc.) that do not otherwise involve processing logic(s) of the lidar processing node corresponding thereto may now involve such processing logic of the lidar processing node. In other words, an abnormal condition of some or all of the processing logic of the lidar processing node will now also affect the normal performance of such vehicle tasks. Thus, such changes will affect the accuracy of the generated aggregate state by not making a corresponding adjustment to the vehicle maintenance or on-board system upgrade (e.g., not informing the functional module responsible for generating the aggregate state of the changes to the subset of processing logic associated with a particular vehicle task due to the changes to the components, circuits, interfaces, firmware, devices, modules, subsystems, etc. of the vehicle described above). In view of this, the present disclosure provides a plurality of inserts for a vehicle.

As used herein, the term "plug-in" may refer to a program written for extended purposes, following a specification of an application program interface, or may refer to a pluggable component or the like to install electronic components thereon or store executable instructions and enable external electrical communication through a connector, to which the present disclosure is not limited in any way.

According to embodiments of the present disclosure, a vehicle may additionally be configured with a plurality of inserts. In some examples, an autopilot system of a vehicle may include a plug-in having a pluggable form, i.e., the plug-in may appear as a component of an entity. In other examples, the plug-in may be written in executable instructions or code form in a programmable logic device of an autopilot system of the vehicle. Thus, each time a vehicle is serviced or an onboard system is upgraded, the plug-in may be updated (e.g., a physical plug-in the form of a pluggable or an over-written plug-in the form of software code) to enable tracking of additions, deletions, replacements, modifications, or upgrades made to components, circuits, interfaces, firmware, devices, modules, subsystems, etc. of the vehicle to ensure the accuracy of the resulting aggregate state as adjustments to the subset of processing logic associated with a particular vehicle task are made with the maintenance of the vehicle or the upgrade of the onboard system.

An autopilot system generally refers to an intelligent automobile system that implements unmanned through an on-board computer system that relies on the synergistic interaction of artificial intelligence, visual computing, radar, monitoring devices, and global positioning systems to enable the computer to automatically and safely operate the automobile without any human active operation.

According to an embodiment of the present disclosure, generating the aggregation state may include: selecting a set of plugins associated with the current task from a plurality of plugins, wherein each plugin of the plurality of plugins can correspond to a unique system state of the set of system states, and each plugin can collect status reports of a respective different number of processing logics of the plurality of processing nodes in real time; for each plug-in a set of plug-ins, determining whether a unique system state corresponding to the plug-in is available based on status reports of a respective number of processing logic collected by the plug-in; an aggregate state may be generated based on the availability of a unique system state corresponding to each of a set of plug-ins.

By way of example and not limitation, assume that there is a set of predefined system states [ a, b, c ] and processing nodes Node0 and Node1, where Node0 includes two processing logics, denoted as Node0_logic0 and Node0_logic1, respectively, and Node1 includes two processing logics, denoted as Node1_logic0 and Node1_logic1, respectively. Depending on, for example, the unique mapping relationship B, an abnormal state of Node0_logic0 may cause system state a to be unavailable, an abnormal state of Node0_logic1 may cause system states a and B to be unavailable, an abnormal state of Node1_logic0 may cause system state c to be unavailable, and an abnormal state of Node1_logic1 may cause system states a and c to be unavailable. Thus, the following plug-ins can be obtained accordingly: p0 (a), p1 (a), p2 (a), p0 (b), p0 (c) and p1 (c), wherein p0 (a) collects status reports of Node0_logic0, p1 (a) collects status reports of Node0_logic0 and Node0_logic1, p2 (a) collects status reports of Node1_logic1, p0 (b) collects status reports of Node0_logic1, p0 (c) collects status reports of Node1_logic0, and p1 (c) collects status reports of Node1_logic1.

In some embodiments, a set of plug-ins may be determined based on the current mission of the vehicle.

By way of example and not limitation, assume that there is a set of vehicle tasks task (X, Y, Z, …), where the set of plug-ins associated with task X is p0 (a), p0 (b), p0 (c), which may be noted as task [ X ] = [ p0 (a), p0 (b), p0 (c) ]; the set of plug-ins associated with task Y is p1 (a), p1 (c), which can be denoted task [ Y ] = [ p1 (a), p1 (c) ]; and the plug-in associated with task Z is p2 (a), which can be noted as task [ Z ] = [ p2 (a) ]. X, Y, Z may be, for example, a highway section travel task, a non-highway section travel task, and a parking task, respectively, as described above.

It can be seen that each plug-in p0 (a), p1 (a), p2 (a), p0 (b), p0 (c) and p1 (c) corresponds to a unique system state in a set of system states [ a, b, c ]. For example, the plug-ins p0 (a), p1 (a), p2 (a) each correspond to the system state a. Taking plug-in p1 (a) as an example, it gathers the corresponding status reports from processing logic Node0_logic0 and Node0_logic1, respectively, and the abnormal status of either processing logic Node0_logic0 or Node0_logic1 will cause the system status a to be unavailable. In this regard, a unique system state in a set of system states for each plug-in means that the abnormal state of the processing logic from which the plug-in collects state reports is the unique system state to which the plug-in corresponds.

It can also be seen that plug-in p1 (a) gathers status reports from two processing logics, while the remaining plug-ins p0 (a), p2 (a), p0 (b), p0 (c) and p1 (c) each gather status reports from only one processing logic. In other words, each plug-in collects status reports for a respective different number of processing logic in the plurality of processing nodes.

As described above, the status report(s) for each processing node may be generated in real-time upon being collected or may be generated at predetermined time intervals (e.g., 20ms time intervals). As a result, status reports for a respective different number of processing logic collected in real-time by each plug-in may indicate a real-time status or historical status of the corresponding processing logic.

According to an embodiment of the present disclosure, determining whether a unique system state corresponding to a plug-in is available based on status reports of a respective number of processing logic collected by the plug-in may include: in response to determining that the status report of any one of the processing logic collected by the plugin indicates that the processing logic is in an abnormal state, it may be determined that the unique system state corresponding to the plugin is not available.

In some embodiments, it may be determined that the unique system state to which the plug-in corresponds is not available, so long as the status report of any one of the processing logic collected by the plug-in indicates that the processing logic is in an abnormal state, regardless of whether the abnormal state is a real-time state or a historical state (e.g., the generation timestamp of the status report indicates that the state is still valid).

As a non-limiting example, plug-in p1 (a) gathers corresponding status reports from processing logic Node0_logic0 and Node0_logic1, respectively, wherein the Node0_logic0 status report shows its status abnormal and valid history state, and the Node0_logic1 status report shows its status normal and real-time state. Then, the unique system state a corresponding to the plug-in p1 (a) is determined to be unavailable.

As another non-limiting example, plug-in p1 (c) gathers status reports from processing logic Node1_logic0, where Node1_logic0 status reports show that its status is abnormal and is a real-time status. Then, the unique system state c corresponding to the plug-in p1 (c) is determined to be unavailable.

According to an embodiment of the present disclosure, determining whether a unique system state corresponding to a plug-in is available based on status reports of a respective number of processing logic collected by the plug-in may include: in response to determining that the difference between the time of generation of the most recently collected status report by the plugin from any one of the processing logic and the current time is greater than a threshold, it may be determined that the unique system state corresponding to the plugin is not available.

In some embodiments, a difference between the time of generation of the most recently collected status report by the plug-in from any one of the processing logic and the current time being greater than a threshold may mean that the status of the corresponding processing logic indicated by the status report is an invalid historical status. In this case, even though the status report shows that the status of the processing logic is normal, the processing logic is regarded as a status exception because the generation time stamp of the status report expires so that it cannot be ensured whether the processing logic is still normal at present. As a result, the unique system state corresponding to the plug-in collecting status reports from the processing logic may be determined to be unavailable.

As a non-limiting example, plug-in p1 (a) gathers corresponding status reports from processing logic Node0_logic0 and Node0_logic1, respectively, wherein the Node0_logic0 status report shows its status as normal but invalid history state and the Node0_logic1 status report also shows its status as normal but invalid history state. Thus, the unique system state a corresponding to the plug-in p1 (a) is still determined to be unusable.

According to an embodiment of the present disclosure, determining whether a unique system state corresponding to a plug-in is available based on status reports of a respective number of processing logic collected by the plug-in may include: in response to determining that the status reports of all processing logic collected by the plugin indicate that the processing logic is in a normal state, and that the difference between the time of generation of the status report most recently collected by the plugin from any one of the processing logic and the current time is not greater than a threshold, it may be determined that a unique system state corresponding to the plugin is available.

As a non-limiting example, plug-in p1 (a) gathers the corresponding status reports from processing logic Node0_logic0 and Node0_logic1, respectively, wherein the Node0_logic0 status report shows that its status is normal and is a valid history state, and the Node0_logic1 status report also shows that its status is normal and is a real-time state (i.e., the difference between the time of generation of the status report and the current time is zero). Then, the unique system state a corresponding to the plug-in p1 (a) is determined to be available.

Additionally, generating the aggregate state may further include: for a plug-in a group of plug-ins, determining whether any processing logic exists in a corresponding number of processing logic collected by the plug-in, wherein any processing logic in an abnormal state will cause unavailability of a unique system state according to a mapping relation; in response to determining that no such processing logic exists in the respective number of processing logic, it is determined that a unique system state corresponding to the plug-in is available. That is, in response to determining that there are no processing logic of the respective number of processing logic that, in an abnormal state, would result in the unique predefined system state being unavailable according to the predefined mapping relationship, then it is determined that the unique predefined system state corresponding to the plug-in is available.

As a non-limiting example, as a complement to the plug-ins p0 (a), p1 (a), p2 (a), p0 (b), p0 (c) and p1 (c), it is assumed that plug-ins p3 (a), p1 (b) and p2 (c) are also present, wherein each of p3 (a), p1 (b) and p2 (c) does not collect status reports from any processing logic. Thus, any information about the availability of the unique system state cannot be read from the status reports collected by the plug-in (in fact, the plug-in does not collect any status reports). Thus, for each of the plugins p3 (a), p1 (b) and p2 (c), the corresponding unique system state may be available by default.

As another non-limiting example, assume that plug-in p3 (a) gathers status reports only from processing Node1_logic0, while the abnormal state of Node1_logic0 only results in system state c being unavailable and does not affect the availability of system state a. Thus, any information about the availability of system state a cannot be read from the status report collected by p3 (a) about Node1_logic0, in other words, the state of Node1_logic0 does not affect system state a. Thus, for plug-in p3 (a), it can be determined that the corresponding unique system state a is available. Of course, this may result in redundancy in the number of cards, which is described herein for the purpose of logic completeness only.

Fig. 3 shows a schematic structural diagram of an exemplary vehicle according to an embodiment of the present disclosure.

As shown in fig. 3, the vehicle 300 includes an autopilot system 300a and a vehicle control unit 330.

In some embodiments, the autopilot system 300a and the vehicle control unit 330 may be part of an onboard system as described above.

The autopilot system 300a may include a node 301, and the node 301 may be a processing node of a vehicle as described above. In an example, node 301 may include multiple nodes. As shown, node 301 may include node 301_1, node 301_2, node 301_3 … …, and node 301_n. In an example, node 301_1 may be a camera processing node with sensing functionality, node 301_2 may be a lidar processing node with sensing functionality, node 301_3 may be a path planning processing node with decision functionality, etc., without any limitation to the present disclosure.

The autopilot system 300a may also include a node status cache 302 for caching status reports for several processing logics of the respective processing nodes. In an example, node state cache 302 may include a number of node state caches equal to the number of nodes in node 301. It will be appreciated that the specific structure of the node state cache may be different from that shown, for example, the node state cache 302 may not be subdivided into a number of node state caches 302_1 … … 302_n, or the node state cache 302 may be subdivided into a different number of node state caches depending on actual needs, which is not subject to any limitation by the present disclosure.

As shown, the node state cache 302 may include a node state cache 302_1, a node state cache 302_2, a node state cache 302_3 … …, and a node state cache 302_n. As shown, node state cache 302_1 may include at least cache entries 304_1a and 304_1b, which indicates that node state cache 302_1 may store a status report for at least two processing logics of respective processing node 301_1. It should be noted that the blocks and ellipses in the drawings are merely schematic representations, which are not intended to limit the structures, numbers, etc. in any way.

In some embodiments, node 301 and node state cache 302 communicate with each other via a bus, as indicated by the thin, open arrow.

The autopilot system 300a may also include a plug-in 310 for collecting status reports of the processing logic from the node cache 302. As shown, the plug-ins 310 may include sub-plug-ins 310_1,310_2,310_3 … … 310_M.

In some embodiments, each of the plugins 310 (e.g., 310_1,310_2,310_3 … … 310 _310_m) has its unique system state, and therefore, among the processing logic from which it gathers status reports, there is at least one processing logic that will cause the unique system state to be unavailable when its condition is abnormal, or the plugin does not gather status reports from any processing logic (i.e., the plugin is an empty plugin, such as plugin p3 (a), p1 (b), or p2 (c) described above).

The autopilot system 300a may further include an aggregate status generating means 312 for generating an aggregate status based on the mapping and a status report of a subset of the processing logic of the plurality of processing nodes involved in the current task of the vehicle. In an example, the aggregate state generation device 312 may be implemented in the form of a hardware or software module in the autopilot system 300 a. In the case of a hardware module implementation, the aggregate state generation device 312 may be a discrete module or an integrated module (e.g., integrated with other suitable modules) in the autopilot system 300 a. In the case of a software module implementation, the aggregate state generation device 312 may be solidified in the form of executable instructions or code in a programmable logic device of an autopilot system of the vehicle.

In some embodiments, the aggregate state generation device 312 may determine (e.g., select) from the plug-ins 310 a number of plug-ins to which the current task relates based on the current task of the vehicle. For example, the set of plug-ins associated with the current task X is p0 (a), p0 (b), p0 (c), so the sub-plug-ins corresponding to p0 (a), p0 (b), p0 (c) can be located from plug-ins 310 and collected therefrom. The operations related to the aggregation state generation apparatus 312 may refer to the aspects described above with respect to step S220 of the method 200, and will not be described herein.

With continued reference to FIG. 3, as illustrated, the vehicle 300 further includes a target system state determination device 332 for determining a target system state of a set of system states that the vehicle is to enter at a current mission based on the aggregate state. The operations related to the target system state determining device 332 may refer to the aspects described above with respect to step S230 of the method 200, and will not be described again here.

In some embodiments, the aggregate state generation device 312 may communicate the generated aggregate state to the target system state determination device 332 via the controller area network 320.

In some embodiments, the target system state determination device 332 may feed back the determined target system state to the respective processing node to enable the processing node to adjust its own processing logic and thereby cause the vehicle to enter the target system state, thereby achieving the minimum risk state MRC of the vehicle taking into account the states of all processing logic involved in the current task.

In some embodiments, the target system state determination device 332 may broadcast the determined target system state to all processing nodes included in the vehicle.

In an example, the target system state determination device 332 may be implemented in the vehicle control unit 330 in the form of hardware or software modules. In the case of a hardware module implementation, the target system state determination device 332 may be a discrete module or an integrated module (e.g., integrated with other suitable modules) in the vehicle control unit 330. In the case of a software module implementation, the target system state determination device 332 may be solidified in the form of executable instructions or code in a programmable logic device of the vehicle control unit.

According to embodiments of the present disclosure, the vehicle may further include a vehicle control unit and an autopilot system, which may include a respective plurality of instances of the plurality of processing nodes. The aforementioned obtaining at least one status report for each of the plurality of processing nodes may comprise: at least one status report for each of a respective plurality of instances of a plurality of processing nodes is obtained by an autopilot system. Further, the foregoing generating the aggregation state may include: an aggregate state is generated by the autopilot system based on the mapping and a status report of a corresponding plurality of instances of the plurality of processing nodes involved in the current task of the vehicle. Further, the determining the target system state of the set of system states to be entered by the vehicle under the current task may include: the target system state is determined by the vehicle control unit based on the aggregate state. In an example, the aggregate state may be sent (e.g., from the autopilot system) to the vehicle control unit for the vehicle control unit to determine a target system state for the vehicle to enter at the current mission based on the aggregate state.

As used herein, the term "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. In this regard, the nodes 301_1, 301_2, 301_3 … …, 301_n shown in fig. 3 may refer to a respective plurality of instances of a plurality of processing nodes included in the vehicle.

For safety reasons, the vehicle may be equipped with redundant autopilot systems, such as slave autopilot systems in addition to master autopilot systems, backup autopilot systems, etc.

By way of example and not limitation, the master, slave, and standby autopilot systems may have the same computational resources or have different computational resources, e.g., the slave autopilot system may have fewer computational resources than the master autopilot system and the standby autopilot system may have fewer computational resources than the slave autopilot system. By way of example and not limitation, if the master autopilot system fails and the slave autopilot system is operating properly, then the commands of the master autopilot system are no longer forwarded to the vehicle control unit, but the commands of the slave autopilot system are forwarded to the vehicle control unit, where the vehicle is controlled by the slave autopilot system. By way of example and not limitation, the master autopilot system may include the largest number of sensor nodes, and the slave autopilot system may include the smallest number of sensor nodes. Also, if both the master and slave autopilot systems fail and the slave autopilot system is functioning properly, then the commands of the master and/or slave autopilot systems are no longer forwarded to the vehicle control unit, but the commands of the slave autopilot system are forwarded to the vehicle control unit, and the vehicle is controlled by the slave autopilot system.

In some embodiments, multiple autopilot subsystems may be used for redundancy, and other autopilot subsystems may be used in place of the control vehicle when one autopilot subsystem of the control vehicle fails or malfunctions. As an example, the autopilot subsystem may include a master autopilot system, a slave autopilot system, a backup autopilot system, and the like.

In some embodiments, the master autopilot system, the slave autopilot system, and the slave autopilot system are each coupled to a vehicle control unit, e.g., via a controller area network.

According to an embodiment of the present disclosure, the vehicle further comprises a vehicle control unit and a plurality of autonomous systems, each of the plurality of autonomous systems comprising a respective plurality of instances of the plurality of processing nodes. The aforementioned obtaining at least one status report for each of the plurality of processing nodes may comprise: at least one status report is obtained for each of a respective plurality of instances of a plurality of processing nodes by each autopilot system. Further, generating the aggregate state may include: by each autopilot system, a respective aggregate state is generated based on the mapping and a status report of a respective plurality of instances of the processing logic subset of the plurality of processing nodes involved in the current task of the vehicle. Further, the determining the target system state of the set of system states to be entered by the vehicle under the current task may include: the target system state is determined by the vehicle control unit based on respective aggregate states of the plurality of autonomous systems.

In some embodiments, the target system state may include an indication of the current task of the vehicle, the current time, and an indication of the availability (i.e., whether normal) of each system state. The availability indication of the system state may take the form of a boolean variable. However, it will be appreciated that other suitable forms may be employed to indicate availability of the system state, which the present disclosure does not limit in any way.

In some embodiments, where the vehicle includes multiple autonomous systems, the target system state determined by the vehicle control unit may be fed back to a respective plurality of instances of the plurality of processing nodes included by each autonomous system.

According to embodiments of the present disclosure, the mapping relationship may take the form of a truth table. Each entry of the truth table may include a key and a key value, where the key may represent corresponding processing logic and the key value may represent one or more system states that would not be available due to the processing logic being in an abnormal state.

Fig. 4 shows a schematic diagram of an exemplary truth table according to an embodiment of the present disclosure. In some embodiments, the truth table may be written into the firmware or ASIC device of the in-vehicle system such that whenever the vehicle is serviced and/or upgraded, the truth table may be updated as the vehicle is serviced and/or upgraded, e.g., entries therein added, deleted, or modified, etc.

As shown in fig. 4, truth table 400 may include keys 401 and key values 402. By way of example and not limitation, key 401 includes the four processing logic described above with respect to exemplary mapping relationship B, and key value 402 indicates a system state that would render unusable if the condition of the corresponding processing logic were abnormal.

It is to be understood that the exemplary truth table 400 of fig. 4 is depicted for illustrative purposes only and is not intended to be limiting in any way.

It may also be appreciated that the number of entries of the truth table increases as the number of processing nodes included by the vehicle and/or the number of processing logic per processing node increases.

According to embodiments of the present disclosure, the current tasks of the vehicle may include: closed road travel, non-closed road travel, parking tasks, reversing tasks, loading and unloading tasks, and the like, to which the present disclosure is not limited in any way.

According to an embodiment of the present disclosure, the system state may include: can operate normally, can be stopped slowly alongside, can brake emergently, etc., and this disclosure does not impose any limitation.

According to another aspect of the present disclosure, there is also provided an apparatus for a vehicle. Fig. 5 shows a block diagram of an apparatus 500 for a vehicle according to an embodiment of the disclosure.

Referring to fig. 5, an apparatus 500 includes: a first module 501 configured to obtain at least one status report of each of a plurality of processing nodes, each status report indicating that a corresponding one of processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic will result in one or more system states of a set of system states being unavailable according to a mapping relationship; a second module 502 for generating an aggregate state based on the mapping relationship and a status report of a subset of processing logic of the plurality of processing nodes involved in the current task of the vehicle, wherein the aggregate state indicates a respective availability of each of a set of system states; and a third module 503 for determining a target system state of a set of system states to be entered by the vehicle under the current task based on the aggregated state.

According to the embodiments of the present disclosure, the above-described apparatus 500 provides a new apparatus for a vehicle to provide the vehicle with a target system state from a set of system states to be entered under a current task, in view of the defect in the related art that the importance level of the processing node(s) is not effectively divided and managed such that the target system state cannot be determined on the whole vehicle level to cause the vehicle to enter the MRC when an abnormality occurs in a certain processing node(s) of the vehicle.

By means of the apparatus 500, by acquiring a status report of each processing node of the vehicle, an aggregate status indicating availability of system status can be generated based on the mapping relationship and the current task information of the vehicle, so as to determine a target system status, so that the risk of vehicle accident can reach an acceptable status in case of abnormality of one or more of the processing nodes of the vehicle, and the safety of vehicle operation is ensured.

There is also provided, in accordance with an embodiment of the present disclosure, an electronic device including: at least one processor; and a memory communicatively coupled to the at least one processor, wherein the memory stores instructions that, when executed by the at least one processor, cause the at least one processor to perform the methods described in the present disclosure.

There is also provided, in accordance with an embodiment of the present disclosure, a vehicle operable in response to a target system state entering a set of system states, the vehicle comprising: a plurality of processing nodes; at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the methods described in the present disclosure.

There is also provided, in accordance with an embodiment of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of the present disclosure.

According to an embodiment of the present disclosure, there is also provided a computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the method described in the present disclosure.

Fig. 6 illustrates a block diagram of an exemplary computing device 600, according to an embodiment of the disclosure. In some embodiments, computing device 600 may also be used to implement aspects of an exemplary system as shown in FIG. 1.

Computing device 600 may be any machine configured to perform processes and/or calculations and may be, but is not limited to, a workstation, a server, a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a smart phone, an in-vehicle computer, or any combination thereof.

Computing device 600 may include elements that are connected to bus 602 or communicate with bus 602 (possibly via one or more interfaces). For example, computing apparatus 600 may include a bus 602, one or more processors 604, one or more input devices 606, and one or more output devices 608. The one or more processors 604 may be any type of processor and may include, but is not limited to, one or more general purpose processors and/or one or more special purpose processors (e.g., special processing chips). Input device 606 may be any type of device capable of inputting information to computing apparatus 600 and may include, but is not limited to, a mouse, a keyboard, a touch screen, a microphone, and/or a remote control. Output device 608 may be any type of device capable of presenting information and may include, but is not limited to, a display, speakers, video/audio output terminals, vibrators, and/or printers. The computing apparatus 600 may also include a non-transitory storage device 610 or any storage device connected to the non-transitory storage device 610 that may be non-transitory and that may enable data storage, and may include, but is not limited to, a magnetic disk drive, an optical storage device, a solid state memory, a floppy disk, a flexible disk, a hard disk, a magnetic tape, or any other magnetic medium, an optical disk or any other optical medium, a ROM (read only memory), a RAM (random access memory), a cache memory, and/or any other memory chip or cartridge, and/or any other medium from which a computer may read data, instructions, and/or code. The non-transitory storage device 610 may be detachable from the interface. The non-transitory storage device 610 may have data/program (including instructions)/code for implementing the methods and steps described above. Computing device 600 may also include a communication interface 612. The communication interface 612 may be any type of device or system that enables the computing apparatus 600 to communicate with other apparatuses and/or with a network, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication devices, and/or chipsets, such as bluetooth ^TM devices, 802.11 devices, wiFi devices, wiMax devices, cellular communication devices, and/or the like.

Computing device 600 may also include memory 614, which is any type of memory that may store programs (including instructions) and/or data useful for the operation of processor 604, and may include, but is not limited to, random access memory and/or read-only memory devices.

Software (programs) may reside in the memory 614 including, but not limited to, an operating system 616, one or more application programs 618, drivers, and/or other data and code. Instructions for performing some of the methods and steps of the present disclosure may be included in one or more application programs 618. Executable code or source code of instructions of software (programs) may be stored in a non-transitory computer readable storage medium (such as the storage device 610 described above) and, when executed, may be stored in the memory 614 (possibly compiled and/or installed). Executable code or source code for instructions of software (programs) may also be downloaded from a remote location.

It should also be understood that various modifications may be made according to specific requirements. For example, custom hardware may also be used, and/or particular elements may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. For example, some or all of the disclosed methods and apparatus may be implemented by programming hardware (e.g., programmable logic circuits including Field Programmable Gate Arrays (FPGAs) and/or Programmable Logic Arrays (PLAs)) in an assembly language or hardware programming language such as VERILOG, VHDL, c++ using logic and algorithms according to the present disclosure.

Although embodiments or examples of the present disclosure have been described with reference to the accompanying drawings, it is to be understood that the foregoing methods, systems, and apparatus are merely exemplary embodiments or examples, and that the scope of the present invention is not limited by these embodiments or examples but only by the claims following the grant and their equivalents. Various elements of the embodiments or examples may be omitted or replaced with equivalent elements thereof. Furthermore, the steps may be performed in a different order than described in the present disclosure. Further, various elements of the embodiments or examples may be combined in various ways. It is important that as technology evolves, many of the elements described herein may be replaced by equivalent elements that appear after the disclosure.

Claims

1. A method for a vehicle including a plurality of processing nodes, the vehicle operable in response to a target system state entering a set of system states, the method comprising:

Acquiring at least one status report of each processing node of the plurality of processing nodes, each status report indicating that a respective one of the processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic would result in one or more system states of the set of system states being unavailable according to a mapping relationship;

Generating an aggregate state based on the mapping and a status report of a subset of processing logic of the plurality of processing nodes involved in the current task of the vehicle, wherein the aggregate state indicates a respective availability of each of the set of system states; and

Based on the aggregate state, the target system state of the set of system states to which the vehicle is to enter at the current task is determined.

2. The method of claim 1, wherein generating an aggregate state comprises:

selecting a set of plugins associated with the current task from a plurality of plugins, wherein each plugin of the plurality of plugins corresponds to a unique system state of the set of system states, and each plugin collects status reports of a respective different number of processing logics of the plurality of processing nodes in real time;

for each plug-in the set of plug-ins, determining whether a unique system state corresponding to the plug-in is available based on status reports of a corresponding number of processing logic collected by the plug-in;

the aggregate state is generated based on availability of a unique system state corresponding to each of the set of plug-ins.

3. The method of claim 2, wherein determining whether a unique system state corresponding to the plug-in is available based on status reports of a respective number of processing logic collected by the plug-in comprises:

In response to determining that the status report of any one of the processing logic collected by the plug-in indicates that the processing logic is in an abnormal state, it is determined that the unique system state corresponding to the plug-in is not available.

4. The method of claim 2, wherein determining whether a unique system state corresponding to the plug-in is available based on status reports of a respective number of processing logic collected by the plug-in comprises:

In response to determining that the difference between the time of generation of the most recently collected status report by the plug-in from any one of the processing logic and the current time is greater than a threshold, determining that the unique system state corresponding to the plug-in is not available.

5. The method of claim 2, wherein determining whether a unique system state corresponding to the plug-in is available based on status reports of a respective number of processing logic collected by the plug-in comprises:

And in response to determining that the status reports of all the processing logics collected by the plug-in indicate that the processing logics are in a normal state, and that the difference between the generation time and the current time of the status report recently collected by any one of the processing logics by the plug-in is not greater than a threshold value, determining that the unique system state corresponding to the plug-in is available.

6. The method of claim 2, further comprising:

for a plug-in the set of plug-ins, determining whether any processing logic exists in the corresponding number of processing logic collected by the plug-in, which in an abnormal state would result in the unique system state being unavailable according to the mapping relationship;

In response to determining that no such processing logic exists in the respective number of processing logic, it is determined that a unique system state corresponding to the plug-in is available.

7. The method of claim 1, wherein the vehicle further comprises a vehicle control unit and an autopilot system comprising a respective plurality of instances of the plurality of processing nodes,

Wherein obtaining at least one status report for each of the plurality of processing nodes comprises: obtaining, by the autopilot system, at least one status report for each instance of the respective plurality of instances of the plurality of processing nodes,

Wherein generating the aggregate state comprises: generating, by the autopilot system, the aggregate state based on the mapping relationship and a status report of a subset of processing logic of the respective plurality of instances of the plurality of processing nodes involved in the current task of the vehicle, and

Wherein determining the target system state of the set of system states to be entered by the vehicle at the current task comprises: the target system state is determined by the vehicle control unit based on the aggregate state.

8. The method of claim 1, wherein the vehicle further comprises a vehicle control unit and a plurality of autopilot systems, each autopilot system of the plurality of autopilot systems comprising a respective plurality of instances of the plurality of processing nodes,

Wherein obtaining at least one status report for each of the plurality of processing nodes comprises: obtaining, by each autopilot system, at least one status report for each instance of the respective plurality of instances of the plurality of processing nodes,

Wherein generating the aggregate state comprises: generating, by each autopilot system, a respective aggregate state based on the mapping and a status report of a subset of processing logic of the respective plurality of instances of the plurality of processing nodes involved in the current task of the vehicle, and

Wherein determining the target system state of the set of system states to be entered by the vehicle at the current task comprises: the target system state is determined by the vehicle control unit based on respective aggregate states of the plurality of autonomous systems.

9. A method according to any one of claims 1 to 8, wherein the mapping relationship takes the form of a truth table, each entry of the truth table comprising a key representing corresponding processing logic and a key value representing one or more system states that would not be available due to the processing logic being in an abnormal state.

10. The method of any of claims 1-8, wherein the current task comprises at least one of: and (5) driving on a closed road, driving on an unclosed road and stopping.

11. The method of any of claims 1-8, wherein the set of system states includes at least one of: can normally run, can stop slowly by leaning on, and can brake urgently.

12. An apparatus for a vehicle including a plurality of processing nodes, the vehicle operable in response to a target system state entering a set of system states, the apparatus comprising:

A first module for obtaining at least one status report for each of the plurality of processing nodes, each status report indicating that a respective one of the processing logic of the processing node is in a normal state or an abnormal state, wherein the abnormal state of each processing logic would result in one or more of the set of system states being unavailable according to a mapping relationship;

A second module for generating an aggregate state based on the mapping and a status report of a subset of processing logic of the plurality of processing nodes involved in a current task of the vehicle, wherein the aggregate state indicates a respective availability of each of the set of system states; and

A third module for determining the target system state of the set of system states to be entered by the vehicle under the current task based on the aggregated state.

13. An electronic device, comprising:

At least one processor; and

At least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1-11.

14. A vehicle operable in response to a target system state entering a set of system states, the vehicle comprising:

At least one processor; and

15. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1-11.

16. A computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the method of any of claims 1-11.