CN115834617A

CN115834617A - Monitoring system for autonomous vehicle operation

Info

Publication number: CN115834617A
Application number: CN202211267324.2A
Authority: CN
Inventors: 孙琳栋; 刘浏; 韩晓凌; 王一; 张锐亮
Original assignee: Tucson Ltd
Current assignee: Tucson Ltd
Priority date: 2018-01-11
Filing date: 2019-01-11
Publication date: 2023-03-21
Also published as: CN111989716A; CN111989716B; WO2019140277A8; US20220242425A1; US11305782B2; WO2019140277A2; EP3738106A2; WO2019140277A3; EP3738106A4; US20190210613A1

Abstract

Devices, systems, and methods for an autonomous vehicle operation monitoring system are disclosed. In some embodiments, the vehicle may perform a self-test, generate a report based on the results, and transmit it to a remote monitoring center over one or both of a high-speed channel for regular data transmission or a reliable channel for emergency situations. In other embodiments, the remote monitoring center may determine that immediate intervention is required, and may send control commands with a high priority that are implemented when received by the vehicle and take precedence over any local commands being processed. In other embodiments, the control command having a high priority is selected from a small set of predetermined control commands that the remote monitoring center may issue.

Description

Monitoring system for autonomous vehicle operation

The application is a divisional application of China application CN201980008172.4, the application date is 1 month and 11 days in 2019, and the name of the invention is 'monitoring system for autonomous vehicle operation'.

Cross Reference to Related Applications

This patent document claims priority from U.S. patent application No.16/245,621, filed on 11/1/2019, which claims priority from U.S. provisional patent application No.62/616,363, filed on 11/1/2018, which is incorporated herein by reference in its entirety.

Technical Field

This document relates to vehicle monitoring and control.

Background

Autonomous vehicle navigation is a technique for sensing the position and motion of a vehicle and autonomously controlling the vehicle navigation to a destination based on the sensing. Autonomous vehicle navigation may have important applications in the transportation of people, goods and services.

Disclosure of Invention

Devices, systems, and methods are disclosed for an autonomously operating monitoring system for a vehicle (e.g., a passenger car or truck). The monitoring system may be configured to send control commands that may override the local commands of the vehicle to ensure occupant and vehicle safety. This may be accomplished by combining information from multiple resources on or near the vehicle and periodically reporting the information to a monitoring system over a reliable communication network.

In one aspect, the disclosed technology may be used to provide a method for monitoring and controlling a vehicle. The method may be implemented at the vehicle, the method comprising: periodically generating reports at a first periodicity; periodically transmitting the report to a remote monitoring center at a second periodicity; receiving a control command from a remote monitoring center, wherein the control command is received in response to the remote monitoring center receiving a periodically transmitted report; and implementing the control command from the remote monitoring center when the control command has a high priority, wherein the implementation of the control command from the remote monitoring center is prioritized over the implementation of the local control command, and wherein the control command is selected from a predetermined set of control commands.

In another aspect, the disclosed technology may be used to provide a method for monitoring and controlling a vehicle. The method may be implemented at a remote monitoring center, the method comprising: periodically receiving reports from the vehicle; determining whether the report includes any immediately actionable status indicators; selecting a control command from a predetermined set of control commands; and when the report includes at least one immediately actionable status indicator, sending the control command with a high priority to the vehicle, and wherein implementation of the control command with the high priority is prioritized over implementation of a local control command at the vehicle.

In another aspect, the disclosed technology may be used to provide a method for monitoring and controlling a vehicle. The method may be implemented at the vehicle, the method comprising: collecting status information from one or more systems implemented in the vehicle; classifying status information by a plurality of status indicators, the plurality of status indicators including one or more critical status indicators and one or more non-critical status indicators; upon receiving status information associated with the one or more critical status indicators, generating a critical status report based immediately on the status information; and generating a non-critical status report based on status information associated with the one or more non-critical status indicators at a period that varies with the one or more non-critical status indicators.

In another aspect, the disclosed technology may be used to provide a method for monitoring and controlling a vehicle. The method may be implemented at the vehicle, the method comprising: collecting status information from one or more systems implemented in the vehicle; classifying status information by a plurality of status indicators including a warning status indicator, an error status indicator, and a fatal status indicator; periodically generating a status report based on status information associated with the alert status indicator; upon receiving the status information associated with the fatal status indicator, immediately generating a status report based on the status information associated with the fatal status indicator; upon receiving status information associated with the error status indicator, performing a recovery procedure on the corresponding system, and if the recovery procedure is unsuccessful, generating a status report based on the status information associated with the error status indicator; and transmitting the generated status report to an external monitoring system.

In another aspect, the disclosed technology may be used to provide a computer apparatus including a processor configured to implement the methods disclosed in this patent document.

In another aspect, the disclosed technology may be used to provide a computer readable program medium having code stored thereon, which when executed by a processor, causes the processor to implement the method disclosed in this patent document.

The above and other aspects and features of the disclosed technology are described in more detail in the accompanying drawings, the description and the claims.

Drawings

FIG. 1 shows a block diagram of an example of a system architecture for vehicle wireless communication that includes monitoring and controlling autonomous vehicle operation;

FIG. 2 shows a block diagram of an example of vehicle components that may support a monitoring system for autonomous vehicle operation;

FIG. 3 shows a flow diagram of an example method for a monitoring system for autonomous vehicle operation;

FIGS. 4A and 4B illustrate two example timelines of operation of a monitoring system for autonomous vehicle operation;

FIG. 5 shows a flowchart of an example method that may be implemented in a vehicle for monitoring autonomous vehicle operation;

FIG. 6 illustrates a flow chart of another example method that may be implemented in a remote monitoring center for monitoring autonomous vehicle operation; and

fig. 7 illustrates an example of a hardware platform in which some of the techniques described herein may be implemented.

FIG. 8 shows a flowchart of another example method for monitoring autonomous vehicle operation that may be implemented in a vehicle.

FIG. 9 illustrates a flow diagram of another example method for monitoring autonomous vehicle operation that may be implemented in a vehicle.

Detailed Description

Devices, systems, and methods are disclosed that may be used for embodiments of a monitoring system for autonomous vehicle operation.

The operation of an autonomous vehicle may involve minimal driver interaction, or no driver at all, but the safety of the passengers is critical. To ensure the safety of the vehicle and passengers, the vehicle state as well as the driving and environmental conditions may be continuously monitored. The monitoring can be done either locally or at a remote monitoring center. This may provide the following advantages: error handling may be immediately enabled under different scenarios.

The technology disclosed in this patent document provides a solution that can be used to solve the above and other technical problems in remotely monitoring and controlling the operation of a vehicle.

FIG. 1 shows a block diagram of an example of a system architecture for vehicle wireless communication and monitoring of autonomous vehicle operation. In an example, the vehicle system 102 includes a vehicle 102-1 and a black box 102-2. The black box 102-2 may be, for example, a storage unit that stores vehicle-generated data and reports. The black box 102-2 may also store local and remote control commands for operating the vehicle. In some embodiments, the contents of the black box 102-2 may be periodically used to improve the autonomous and monitoring operation of the system.

In addition to the vehicle system 102, the system architecture may also include a remote monitoring center 108 and at least two communication channels that the vehicle 102-1 may use to send messages, various reports, or data to the remote monitoring center 108. The first channel may be a bidirectional (bi-directional) high speed channel 106 for regular (e.g., periodic) data transfer. The second channel may be a one-way (one-way, vehicle-to-remote monitoring center) or two-way reliable channel 108. The second channel is only available for emergency situations. One of the advantages of the embodiment shown in fig. 1 is the presence of redundant channels, which increases the likelihood that the remote monitoring center will receive reports and status indicators sent from the vehicle.

In various embodiments, the high speed channel 106 may employ other transmission protocols such as Long Term Evolution (LTE), wi-Fi, IEEE 802.11, bluetooth, dedicated Short Range Communications (DSRC), communications air interface long and medium range (CALM), and possibly designed for Intelligent Transportation Systems (ITS).

In some embodiments, reliable channel 108 may employ low-rate Forward Error Correction (FEC) codes or retransmissions to ensure robust communication even when adverse conditions exist on the wireless channel. In some embodiments, the reliable channel 108 may employ a protocol or physical layer (PHY) waveform that utilizes one or more of frequency, time, space, or code division sets.

FIG. 2 shows a block diagram of an example of vehicle components that may support a monitoring system for autonomous vehicle operation. In some embodiments, the vehicle hardware system may include a plurality of Electronic Control Units (ECUs), represented in FIG. 2 as 204-1, 204-2, and 204-3, each of which may control a plurality of sensors, devices, and interfaces. For example, the ECU 204-1 may control at least a first sensor 206-1 and a second sensor 206-2, while another ECU 204-2 may control an external device 206-3, and yet another ECU 204-3 may control a vehicle Controller Area Network (CAN) 206-4 and an alternate vehicle interface 206-5. The combination depicted in FIG. 2 includes is not intended to be limiting and it should be understood that the ECU may control any number of sensors, devices, or interfaces.

In some embodiments, the sensors controlled by the ECU may include Global Positioning System (GPS) sensors, radar sensors, LIDAR (light detection and ranging) sensors, ultrasonic sensors, and cameras (or CMOS image sensors). The ECU and its corresponding sensors, devices or interfaces are in two-way communication, which enables the ECU to receive data from the sensors and send commands to the sensors.

Some of the ECUs (204-1, 204-2, and 204-3) may include at least one hardware system (or subsystem) and at least one software system. Some ECUs may support self-testing of these systems and subsystems. Furthermore, if the ECU is controlling any external sensors, devices or interfaces, it may typically include self-tests for those external sensors, devices or interfaces, respectively. In an example, an ECU connected to the vehicle collects information about the vehicle itself.

Analysis of these self-tests results in the generation of reports. In some embodiments, the ECU may analyze data generated from the self-test and generate a report based on the analysis. Reports from the ECU are collected by monitoring ECU 202. In some embodiments, each ECU (204-1, 204-2, and 204-3) may analyze the results of its own self-test and send a report to the monitoring ECU 202. In other embodiments, each ECU may send raw data to the monitoring ECU, which then analyzes the raw data to generate results and reports. In the latter embodiment, the raw data from sensors controlled by different ECUs may be combined prior to analysis to provide higher system level reports that cannot be generated by individual ECUs.

FIG. 3 shows a flowchart of an example method 300 of monitoring operation for autonomous vehicle operation. At step 302, the vehicle may perform one or more self tests for each ECU in the vehicle. As described herein, a self-test is performed by each ECU on its hardware and software systems and all sensors, devices and interfaces under its control. In some embodiments, sensor self-testing may include collecting data and comparing it to a baseline to ensure that the sensor is operating as intended. Self-testing may include measuring the state of the vehicle, e.g., position, speed, acceleration, and checking the measurements against predetermined thresholds to verify normal operating conditions. The threshold may be updated based on current driving and environmental conditions.

At step 304, data from the self-test may be analyzed at the respective ECU or at the monitoring ECU, as described in the context of fig. 2. In some embodiments, analysis of the data may result in a determination of a status or status indicator. Based on the status, a report may be generated that includes a particular information element. The information or data included in the report may be based on the status indicator. The status indicator may have a level or rank, as shown by example in the following table:

as shown in the example table above, the size of the generated report may depend on the state. The report sent when the status is "normal" may include basic information of vehicle operation (dynamic or current status), typically much smaller than the report sent when the status is "fatal", in which case the report may include raw data from sensors that identify fatal conditions.

Further, in some embodiments, a message with a particular status may send a report with the data indicated in the table above and the data from the row above it. For example, if the status is "error," the report may include an error log as well as warning messages and logs and basic information about vehicle operation related to the "normal" status. This may enable the remote monitoring center to better analyze potential problems as more data may be facilitated.

At step 306, the generated report is sent to a remote monitoring center. As previously described, the report may be sent on at least one of a high speed channel and a reliable channel. In some embodiments, the report may also be stored on a local storage device.

In some embodiments, the report may be divided using a partitioning scheme, and different portions may be sent over different channels. For example, if the status is "warning" and the vehicle has chosen to send basic information of vehicle operation in addition to warning messages and logs, the vehicle may send the latter over a high speed channel ("normal" status information) and the former over a reliable channel ("warning" status information).

At step 308, the vehicle determines whether error handling is required based on the status determined at step 304. In some embodiments, when the status indicator is "normal" or "warning," no error handling is required (no path in fig. 3) and operation of the monitoring system returns to step 302. In contrast, if the status indicator is "error" or "fatal", it is determined that error processing is required (yes path in fig. 3).

In step 310, the vehicle may take action to recover from the cause of the "wrong" or "fatal" status indicator. In an example, if the error message indicates that certain sensors required for autonomous operation of the vehicle are not functioning properly, a restart command may be sent to those sensors. In the event that the sensor does not return to normal operation or the cause of a "fatal" status indicator, a series of commands can be issued to stop the vehicle at a safe location.

At step 312 (which may occur at any point on the timeline after step 306, before step 310 is complete), a remote command is received from the remote monitoring center. The remote command may be received based on the remote monitoring center analyzing the report sent by the vehicle and determining that certain actions must be taken to secure the passengers and the vehicle. In some embodiments, the remote command has a higher priority than the local command being issued by the vehicle. In some embodiments, a higher priority may guarantee that the remote command is executed and will result in the implementation of the remote command being prioritized over the implementation of any local commands.

As with any other computer-implemented technology, the remote monitoring center may be vulnerable to hacking, and thus the number and content of remote commands that can be issued is limited. For example, the remote monitoring center may only issue commands to slow down the vehicle and safely stop it. This may ensure, for example, that hacking the remote monitoring center does not cause the vehicle to be placed in an unfavourable high speed situation. The predetermined set of control commands issued by the remote monitoring center may be updated for different environmental and driving conditions.

Fig. 4A and 4B illustrate two example timelines of operation of a monitoring system for autonomous vehicle operation. The figures include common steps, elements, or features not explicitly described in the context of each figure.

As shown in FIG. 4A, the vehicle is in a period T ₁ Reports (402-1, 402-2, 402-3, …) are generated. In one example, when the status of the reports in reports 402-1 through 402-9 is "normal," the vehicle is operating for a second period T ₂ The reports (404-1, 404-2, 404-3) are transmitted to a remote monitoring center.

Assume that the generated report 402-10 has a "fatal" status indicator and that the corresponding report is immediately sent 404-4 to the remote monitoring center. In response to the "fatal" status indicator, the vehicle issues a local control command in an attempt to mitigate the situation. The local command is executed (406) starting with the generation of the "fatal" status indicator. Further assume that the local control command has an execution time T _local As shown in fig. 4A.

Subsequent reports generated at the vehicle continue to have a "fatal" status indicator and continue to be sent (404-5 and 404-6) to the remote monitoring center. At a later time (408), a control command is received from the remote monitoring center. The remote control command has a higher priority than the local command issued by the vehicle. As a result, execution of the remote control command will take precedence over execution of the local control command. As shown in FIG. 4A, T is not performed _local The remaining time (409) but the execution of the remote control command is started (410).

In the example timeline shown in FIG. 4B, assume that report 402-10 has an "error" status indicator that results in the report being immediately sent (404-4) to the remote monitoring center. Starting with the generation of the report 402-10, local commands issued by the vehicle are executed (406) to mitigate the situation. In this example, the local command resolves the situation before the next report 402-11 is generated, the next report 402-11 being generated with a "normal" status indicator.

Control commands from a remote monitoring center are then received (408). In an example, the remote control command is the same as the local control command and is not executed since the remote control command is not currently necessary. In another example, the remote control commands are different from the previously issued local control commands, and the vehicle executes them (410). However, since the execution of the native command is completed, there is no priority processing with respect to the native command.

FIG. 5 illustrates a flow chart of an exemplary method 500 for monitoring autonomous vehicle operation that may be implemented in a vehicle. The method 500 includes: at step 502, reports are generated periodically at a first periodicity. In some embodiments, the first period is very short and reports are generated at the vehicle at a high frequency to ensure a quick response to any adverse conditions that may occur. Examples of adverse conditions may include detection of an unknown environment (e.g., construction area, accident site), hazardous weather conditions, or loss of communication with a remote monitoring center.

The method 500 includes: at step 504, reports are periodically sent to the remote monitoring center at a second periodicity. The second period is typically longer than or equal to the first period. In some embodiments, the second period of time may be based on a status indicator. For example, reports corresponding to the "normal" state will be sent less frequently than reports associated with the "alert" state. Similarly, for "error" and "fatal" status indicators, the report may be sent immediately after generation, in which case the second period is equal to the first period.

The method 500 includes: at step 506, a control command is received from a remote monitoring center. The control command is received in response to the remote monitoring center receiving a periodically transmitted report. In some embodiments, the remote monitoring center issues commands to the vehicle based on the reports (which may include data from one or more sensors) as well as reports from other vehicles.

The method 500 includes: in step 508, the control command from the remote monitoring center is implemented when the control command has a high priority. In some embodiments, when the most recently sent report includes an "error" or "fatal" status indicator, the received control command may have a high priority. The received control commands may instruct the vehicle to take precautionary measures to ensure passenger and vehicle safety and can override local commands that the vehicle is currently executing.

In some embodiments, a control command with a high priority received from a remote monitoring center may initiate an emergency stop module, which may include instructions to determine the best way to reduce the vehicle speed until it comes to a complete stop. In other embodiments, the vehicle may also continue to frequently transmit its status to the remote monitoring center over a reliable channel during the process. If communication with the remote monitoring center has been disrupted, the vehicle may choose to send its status to another vehicle to which the remote monitoring center has indeed a connection.

In an example, if a tire sensor senses a leak in one of the tires, a "fatal" status indicator may be generated in the report. The report will be immediately sent to the remote monitoring center. Since passenger safety is of paramount importance, the vehicle issues local control commands to slow down and drive to the nearest service station. The planned route may be based on an archived map stored on the vehicle's local storage.

The remote monitoring center receives the report with the "fatal" status indicator along with the data from the tire sensors. Based on the report and data, it also determines that deceleration and immediate maintenance are required.

However, since the remote monitoring center may be communicating with other vehicles, it notices a serious traffic jam due to an accident on the route to the nearest service station. Thus, the remote monitoring center issues a command with a high priority to slow down and go to a maintenance station further away than the nearest maintenance station. When the vehicle receives the command, the command may override the local control command, and the vehicle will now proceed to the service station indicated by the remote monitoring center.

FIG. 6 illustrates a flow diagram of another example method 600 for monitoring autonomous vehicle operation that may be implemented in a remote monitoring center. The method 600 comprises: at step 602, reports are periodically received from a vehicle being monitored by a remote monitoring center. In some embodiments, the frequency of receiving reports may depend on the status indicators contained within the reports.

In other embodiments, the remote monitoring center may request that the vehicle send reports at a different frequency than is typically associated with existing status indicators. Since the remote monitoring center may be monitoring and controlling multiple vehicles in the area, it has a higher system level perspective that a single vehicle may not have, and therefore may request a higher frequency of reports if the likelihood of an adverse condition is greater than normal.

In other embodiments, the remote monitoring center may determine the reporting frequency based on a status indicator of the vehicle and a history of reports. In an example, the history considered may span hours, days, or weeks, and may be implemented using a sliding window function to give greater weight to the updated status indicators.

The method 600 comprises: at step 604, it is determined whether the report includes any immediately actionable status information. In some embodiments, "error" and "fatal" status indicators may be marked as immediately actionable. In other embodiments, and in the presence of other possible environmental factors, the "alert" state may be marked as immediately actionable. The control command sent at step 508 may be completed with a high priority if it is determined that the report includes at least one immediately actionable status information.

The method 600 comprises: at step 606, a control command is selected from a predetermined set of control commands. Since the remote monitoring center may be vulnerable to hacking, the number and type of commands for the remote monitoring center are limited to ensure that a compromised remote monitoring center does not adversely affect the vehicle or vehicles under its control. In an example, the predetermined set of control commands may include a process for defensive driving and stopping the vehicle. This will ensure that adverse high speed conditions involving the vehicle are avoided.

The method 600 comprises: at step 608, a control command with a high priority is sent when the report includes at least one instance of immediately actionable status information. In some embodiments, a control command with a high priority flag may override any local control command that the vehicle has issued or is executing in response to an "error" or "fatal" status indicator sent to the remote monitoring center in the report. .

Fig. 7 illustrates an example of a hardware platform 700 that may be used to implement some of the techniques described herein. For example, hardware platform 700 may implement

methods

500 or 600, or may implement various modules described herein. Hardware platform 700 may include a processor 702 that may execute code to implement methods. Hardware platform 700 may include memory 704, and memory 704 may be used to store processor executable code and/or store data. Hardware platform 700 may also include a communication interface 706. For example, the communication interface 706 may implement a communication protocol for one or both of a high-speed channel for regular data transfers or a reliable channel for emergency situations.

FIG. 8 shows a flow diagram of another exemplary method 800 that may be implemented in a vehicle for monitoring autonomous vehicle operation. The method 800 comprises: at step 802, status information is collected from one or more systems implemented in a vehicle, and at step 804, the status information is classified by a plurality of status indicators, including one or more critical status indicators and one or more non-critical status indicators. Here, the one or more systems may include at least one sensor, at least one hardware system, and at least one software system. For example, the plurality of sensors includes at least one of a Global Positioning System (GPS) sensor, a radar sensor, a LIDAR sensor, and a camera. In some embodiments of the disclosed technology, the one or more non-critical status indicators comprise status indicators related to vehicle basic dynamic information and warning messages from one or more systems implemented in the vehicle. Here, the basic dynamic information includes the position of the vehicle, the fuel level of the vehicle, and the engine temperature of the vehicle. In some embodiments of the disclosed technology, the one or more key status indicators include status indicators related to one or more of hazardous weather conditions, unknown environmental conditions, and a loss of communication with the monitoring center. For example, the one or more key status indicators include status indicators related to a condition that makes operation of the vehicle unsafe. In this case, the method 800 further includes: initiating an emergency stop function implemented in the vehicle; and sending a report indicating that the emergency stop function has been activated.

The method 800 comprises: at step 806, upon receiving status information associated with the one or more critical status indicators, a critical status report is generated based immediately on the status information. The method 800 comprises: at step 808, a non-critical status report is generated based on the status information associated with the one or more non-critical status indicators at a period that varies with the one or more non-critical status indicators. The method 800 may further include: non-critical status reports are sent over a high-speed channel for regular data transfer and critical status reports are sent over a reliable channel for emergency situations.

FIG. 9 illustrates a flow diagram of another exemplary method 900 that may be implemented in a vehicle for monitoring autonomous vehicle operation. The method 900 includes: at step 902, status information is collected from one or more systems implemented in a vehicle. Here, the one or more systems include at least one sensor, at least one hardware system, and at least one software system. For example, the plurality of sensors includes at least one of a Global Positioning System (GPS) sensor, a radar sensor, a LIDAR sensor, and a camera. The method 900 includes: at step 904, the status information is classified by a plurality of status indicators including a warning status indicator, an error status indicator, and a fatal status indicator. In some embodiments of the disclosed technology, the vital status indicators include status indicators related to one or more of hazardous weather conditions, unknown environmental conditions, and a loss of communication with the monitoring center. For example, the fatal status indicators include status indicators related to a condition that makes operation of the vehicle unsafe. In this case, the method 900 further includes: activating an emergency stop function implemented in the vehicle; and sending a report indicating that the emergency stop function has been activated.

The method 900 includes: at step 906, a status report is periodically generated based on the status information associated with the alert status indicator. The method 900 further comprises: at step 908, upon receiving the status information associated with the fatal status indicator, a status report is generated immediately based on the status information associated with the fatal status indicator. The method 900 further comprises: at step 910, upon receiving the status information associated with the error status indicator, a recovery procedure is performed on the corresponding system, and if the recovery procedure is unsuccessful, a status report is generated based on the status information associated with the error status indicator. Associated with an error status indicator. The method 900 further comprises: at step 912, the generated status report is sent to an external monitoring system. In some embodiments of the disclosed technology, the status report associated with the warning status indicator is sent over a high speed channel for regular data transfer, while the status report associated with the fatal status indicator is sent over a reliable channel for emergency situations.

Implementations of the subject matter and the functional operations described in this document can be implemented in various systems, digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions, encoded on a tangible, non-transitory computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing unit" or "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of the above.

A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including: a compiled or interpreted language, and the computer program can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. The computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, the computer need not have these devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

The specification, together with the drawings, are intended to be exemplary only, with the illustration being meant to be exemplary. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. In addition, use of "or" is intended to include "and/or" unless the context clearly indicates otherwise.

While this patent document contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

Only a few embodiments and examples are described and other embodiments, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to:

receiving a test result from an electronic control unit of a vehicle, the test result including a result of a self-test performed by the electronic control unit;

analyzing the received test results to determine a vehicle status, the vehicle status including a status indicator and status information to be included in a report;

periodically transmitting a report containing the vehicle state to a remote system according to a first time period, the duration of the first time period being dependent on the vehicle state;

receiving a control command from the remote system; and

in response to receiving the control command, implementing the control command.

2. The apparatus of claim 1, wherein to analyze the received test results, the at least one memory and the computer program code are configured to, with the at least one processor, further cause the apparatus to select the vehicle state based on the received test results, the vehicle state being from one of a plurality of predetermined state values, each of the plurality of predetermined state values being associated with a corresponding state indicator and corresponding information to be included in the report.

3. The apparatus of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, further cause the apparatus to generate the report periodically according to a second time period.

4. The apparatus of claim 1, wherein the control command is received from the remote system in response to the report being sent.

5. The apparatus of claim 1, wherein the size of the report is dependent on the vehicle status contained in the report.

6. The apparatus of claim 1, wherein to implement the received control command, the at least one memory and the computer program code are configured to, with the at least one processor, further cause the apparatus to override implementation of a local control command.

7. The apparatus of claim 1, wherein the received control command comprises one of a plurality of predetermined control commands.

8. The apparatus of claim 1, wherein the test results comprise results of performing a self-test in the sensor.

9. The apparatus of claim 8, wherein the sensor comprises at least one of a global positioning system receiver, a radar, a light detection and ranging sensor, a camera, and an ultrasonic sensor.

10. The apparatus of claim 9, wherein the report is sent periodically via a first channel for regular data transfer, and wherein the report is sent periodically via a second channel in response to an emergency.

11. The apparatus of claim 1, wherein to implement the received control command, the at least one memory and the computer program code are configured to, with the at least one processor, further cause the apparatus to slow the vehicle, bring the vehicle to a safe stop, or modify a destination of the vehicle.

12. The apparatus of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, further cause the apparatus to:

detecting that communication with the remote system is disrupted; and

periodically sending the report to another vehicle having a connection with the remote system in response to the detection that the communication is disrupted.

13. A method, comprising:

periodically transmitting a report containing the vehicle state to a remote system according to a first time period, the duration of the time period depending on the vehicle state;

receiving a control command from the remote system; and

in response to receiving the control command, implementing the control command.

14. The method of claim 13, further comprising selecting the vehicle state based on the received test results, the vehicle state being from one of a plurality of predetermined state values, each of the plurality of predetermined state values being associated with a corresponding state indicator and corresponding information to be included in the report, wherein the corresponding state indicator comprises one of a normal state, a warning state, an error state, or a fatal state.

15. The method of claim 14, wherein the size of the report depends on the vehicle status included in the report, wherein the size of a first report including a normal status is smaller than the size of a second report including a fatal status.

16. The method of claim 13, further comprising periodically generating the report according to a second time period, wherein the second time period is less than the first time period.

17. The method of claim 13, wherein the control command is received from the remote system in response to the report being sent, wherein the control command is received via a communication channel comprising at least one of a cellular data channel, a dedicated short range communication channel, or a communication air interface long range and medium range channels.

18. The method of claim 13, wherein implementing the received control command comprises prioritizing a local control command, wherein prioritizing the local control command comprises at least one of decelerating the vehicle or moving the vehicle to a nearest service station.

19. The method of claim 13, wherein implementing the received control command comprises at least one of implementing the vehicle with a defensive driving process or safely stopping the vehicle.

20. A non-transitory computer-readable medium having instructions stored thereon, which when executed by at least one processor cause operations comprising:

periodically transmitting a report containing the vehicle state to a remote system according to a time period, the duration of the time period depending on the vehicle state;

receiving a control command from the remote system; and

in response to receiving the control command, implementing the control command.