Patent Description:
In conventional motor vehicles (e.g., automobiles, cars, trucks, buses, etc.), the driver is critical to operating the vehicle's control system. For example, the driver of a conventional motor vehicle makes decisions regarding the safe operation of the vehicle. Such decisions may include decisions related to the speed of the vehicle, steering of the vehicle, obstacle and/or hazard recognition, and obstacle and/or hazard avoidance. However, a driver's ability to make these decisions and operate the vehicle's control system may be limited in some situations. For example, driver impairment, fatigue, attentiveness, and/or other factors such as visibility (e.g., due to weather or changes in terrain) may limit a driver's ability to safely operate a conventional motor vehicle and/or its control system.

In order to alleviate the deficiencies resulting from driver operation of a conventional motor vehicle, various manufacturers have experimented with autonomous vehicles. While autonomous vehicles may allow for a reduction in issues that may arise as a result of the driver's ability to operate the conventional motor vehicle becoming lessened, autonomous vehicles have their own shortcomings.

For example, autonomous vehicles may rely on various sensors and/or cameras to determine a speed at which to operate the vehicle, steering of the vehicle, obstacle and/or hazard recognition, and obstacle and/or hazard avoidance. Data from these sensors and/or devices may be corrupted while being stored on memory or transmitted on a memory bus, for example. Data may be corrupted by errors induced by noise, cross talk, and/or other sources of errors. A host may receive commands to safely operate the autonomous vehicle and provide updates to the autonomous vehicle based on data. If the data the commands are based on is corrupted the autonomous vehicle may cease to operate or, in worse case scenarios, fail to provide adequate obstacle and/or hazard recognition, and obstacle and/or hazard avoidance, which may result in injury or death to passengers in the autonomous vehicle.

<CIT> relates to a memory device that includes: a plurality of memory cells; at least one address storage unit; a fail detection unit suitable for comparing first and second read data that are read from at least one memory cell selected among the plurality of memory cells to detect a fail, and storing an address of the selected memory cell in the address storage unit when the fail is detected; and a refresh control unit suitable for refreshing the memory cell corresponding to the address stored in the address storage unit at a higher frequency than the other memory cells.

"<NPL>, relates to a self-correcting triple voting flip-flop circuit that is not only able to detect and correct Single Event Upset (SEU) faults, but also provides corrective actions for manufacturing device defects.

<NPL> relates to a discussion of single upset events (SEU) and single event transients (SET) mitigation schemes.

The present disclosure includes apparatuses and methods related to a safety controller. In a first aspect, an apparatus is provided as recited in claim <NUM>. In a second aspect, a method is provided as recited in claim <NUM>.

In some approaches, autonomous vehicles may include a memory device to provide data to a controller. The data can include vehicle sensor data, for example obstacle and/or hazard information. The memory can store critical code including firmware, software, and/or temporary calculations derived from the data.

To reduce the probability of the autonomous vehicle executing the wrong code, multiple entities (e.g., a memory device and/or controller) can execute and identify a correct output, which can be referred to as redundancy. Embodiments can be implemented to provide safety measures in applications (e.g., autonomous driving applications in vehicles). As an example, triple redundancy can include two entities transmitting the same code. A third entity can receive the codes and identify whether one or more of the codes are corrupted.

In some embodiments, redundancy can allow a system to avoid failure and/or an accident in the field. For example, redundancy can ensure the correctness of a data transmission between a memory device and a controller. Redundancy can also ensure the correctness of the execution by the controller of the proper code.

For example, because operation of the control system in an autonomous vehicle may be wholly or partly handled by control circuitry, autonomous vehicles may be susceptible to data corruption. Data can be corrupted by noise, cross talk, and/or other sources of error. Redundancy prevents a command, for example, "activate brakes" from being sent when the command is based on corrupt data.

As will be appreciated, elements shown in the various embodiments herein can be added, exchanged, and/or eliminated so as to provide a number of additional embodiments of the present disclosure. In addition, as will be appreciated, the proportion and the relative scale of the elements provided in the figures are intended to illustrate certain embodiments of the present invention, and should not be taken in a limiting sense.

<FIG> is a block diagram of a system <NUM> in the form of a host <NUM> and a control unit <NUM> in accordance with a number of embodiments of the present disclosure. As used herein, a memory device <NUM>, a controller <NUM>, an application controller <NUM>, and/or a safety controller <NUM> might also be separately considered an "apparatus.

As shown in <FIG>, apparatus <NUM> includes a host <NUM> and a control unit <NUM>. The control unit <NUM> includes a memory resource (e.g., memory device <NUM>) and a controller <NUM>. The controller <NUM> includes an application controller <NUM> and a safety controller <NUM>.

The memory device <NUM> may include volatile and/or non-volatile memory configured to store instructions executable by the controller <NUM>. For example, the memory device <NUM> may include flash memory, for example NOR, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), dynamic random-access memory (DRAM), static random-access memory (SRAM), and/or other suitable storage media. In some embodiments, the memory device <NUM> can be a double edge device.

The apparatus <NUM> may be used in autonomous driving applications. For example, the control unit <NUM> can be located on a vehicle. The memory device <NUM> of the control unit <NUM> may store autonomous vehicle data. For example, critical code (e.g., firmware, specific parameters, and data) for an autonomous driving application. The data can include data collected from vehicle sensors, photographic data collected from vehicle cameras, and/or a combination thereof. According to the invention, the memory device <NUM> stores data and transmits data. The data can be transmitted to the controller <NUM> including the application controller <NUM> and the safety controller <NUM>.

The application controller <NUM> can receive data from the memory device <NUM>. The received data can be used by the application controller <NUM> to generate commands. For example, the data can include information regarding a vehicle approaching a stop sign. The application controller <NUM> can generate a command to stop the car. The application can then send the generated command and/or commands to be executed by the vehicle.

According to the invention, data is transmitted to the safety controller <NUM>. The safety controller <NUM> receives data from the memory device <NUM> and the application controller <NUM>. The safety controller <NUM> can prevent a command and/or commands from being executed by the vehicle in response to comparing the data from the memory device <NUM> and the data from the application controller <NUM>.

<FIG> is a flow diagram <NUM> associated with triple redundancy in an autonomous driving application in accordance with a number of embodiments of the present disclosure. As shown in <FIG>, the memory device <NUM>, application controller <NUM>, and the safety controller <NUM> may be configured to exchange data and/or communications. The memory device <NUM> may transmit data to the safety controller <NUM> via data paths <NUM> and <NUM>. The memory device <NUM> may transmit data to the application controller <NUM> via data path <NUM>. The application controller <NUM> may transmit data to the safety controller <NUM> via data path <NUM>. The application controller <NUM> can communicate with safety controller <NUM> via communication path <NUM>. The safety controller <NUM> communicates with the application controller <NUM> and the multiplexer <NUM> (e.g., MUX) via communication path <NUM>.

According to the invention, the memory device <NUM> stores and transmits data. The safety controller <NUM> can be coupled to the memory device <NUM> via the data paths <NUM> and <NUM>. The safety controller <NUM> is configured to receive the data from the memory device <NUM>. The data from the memory device <NUM> can be received by the safety controller <NUM> as a reverse output via data path <NUM> and as a direct output via data path <NUM>. The reverse output of the data can be transmitted by the memory device <NUM> on a falling edge of a clock and the direct output of the data can be transmitted by the memory device <NUM> on a rising edge of the clock, as further discussed in <FIG>.

The memory device <NUM> may transmit data to the application controller <NUM>. The application controller <NUM> can be coupled to the memory device <NUM> via the data path <NUM>. The application controller <NUM> can be configured to receive the data from the memory device <NUM>. The data from the memory device <NUM> can be received as a direct output by the application controller <NUM> via data path <NUM>. The direct output of the data can be transmitted by the memory device <NUM> on a rising edge of a clock, as further discussed in <FIG>.

In some embodiments, the application controller <NUM> may latch the data in response to receiving the data from the memory device <NUM>. The application controller <NUM> transmits the latched data to the safety controller <NUM>. The application controller <NUM> can latch the data on a rising edge of the clock. The safety controller <NUM> is configured to receive latched data from the application controller <NUM>. The latched data from the application controller <NUM> can be received by the safety controller <NUM> as an output via data path <NUM>. The output of the latched data can be transmitted by the application controller <NUM> on a falling edge of a clock, as further discussed in <FIG>.

According to the invention, the safety controller <NUM> generates a response and/or determine whether to allow an output of commands via data path <NUM> from the application controller <NUM> in response to a comparison of the data from the memory device <NUM> and the latched data from the application controller <NUM>. The data received by the application controller <NUM> from the memory device <NUM> is used to generate commands. The commands can be associated with the data from the memory device <NUM> and can be output from the application controller <NUM> in response to the application controller <NUM> receiving the data from the memory device <NUM>. For example, the data can include information regarding a higher speed limit. The application controller <NUM> can generate a command and/or commands to accelerate the speed of the vehicle to reach the higher speed limit. However, the data received by the application controller <NUM> and used to generate the command to accelerate the vehicle could be corrupted, which could mean the vehicle when executing the command is accelerating even though the speed limit did not change and/or the speed limit is different than what is indicated to the application controller <NUM> by the corrupted data.

In embodiments, the safety controller <NUM> prevents a command from being executed via data path <NUM> by the vehicle. According to the invention, the safety controller <NUM> prevents a command from being executed by generating a response and/or transmitting a flag to the MUX <NUM> and the application controller <NUM> via communication path <NUM>. The safety controller <NUM> transmits a flag in response to identifying a difference between the data from the memory device <NUM> and the latched data from the application controller <NUM>. In some embodiments, the safety controller <NUM> can compare the reverse output and direct output from the memory device <NUM> and the output from the application controller <NUM>. If one and/or more of the data outputs are different, the safety controller <NUM> can transmit a flag. The data outputs being different (e.g., different than the direct output from the memory device <NUM> and the latched data from the application controller <NUM> matching and being the opposite of the reverse output from the memory device <NUM>) can indicate that at least one of the data outputs have been corrupted while stored and/or transmitted.

The memory device <NUM> and/or the application controller <NUM> can transmit another portion of data in response to the application controller <NUM> receiving the flag via communication path <NUM> from the safety controller <NUM>. The flag can indicate that the data outputs from the memory device <NUM> and/or the application controller <NUM> are corrupt and that the data needs to be resent.

In some embodiments, the application controller <NUM> can output a safety acknowledgment signal via communication path <NUM> to the safety controller <NUM>. The safety acknowledgment signal can be sent in response to receiving the flag from the safety controller <NUM>. The acknowledgment signal can notify the safety controller <NUM> that the application controller <NUM> received the flag and/or the application controller <NUM> and/or the memory device <NUM> are resending the data.

In response to receiving the safety acknowledgment signal from the application controller <NUM>, the safety controller <NUM> can remove the flag. In the absence of a flag and/or if a response is not generated, the MUX <NUM> will allow the application controller <NUM> commands to be executed by the vehicle via data path <NUM>.

The safety controller <NUM> can allow commands from the application controller <NUM> to be executed in response to identifying a match between the data from the memory resource <NUM> and the latched data from the application controller <NUM>. For example, commands can be executed if the direct output data from the memory device <NUM> and the output data from the application controller <NUM> match and are the opposite of the reverse output data from the memory device <NUM>. Also, the reverse output data can be put in a direct output data state once received by the safety controller <NUM>, and compared against the other output data. Commands can be executed if the direct output data from the memory device <NUM> and the output data from the application controller <NUM> match and are the opposite of the reverse output data from the memory device <NUM>.

<FIG> is a diagram of a memory output of a double edge device in accordance with a number of embodiments of the present disclosure. A double edge device is a memory device (e.g., memory device <NUM> in <FIG>). As shown in <FIG>, data can be transmitted on rising edges <NUM> and <NUM> and falling edges <NUM> and <NUM> of a double edge device. For example, Data <NUM> at <NUM> can be transmitted on rising edge <NUM>. Data <NUM> can be a direct output from memory because it is transmitted on a rising edge <NUM>. Data <NUM>' at <NUM> can be a reverse output because it is transmitted on a falling edge <NUM>. Reverse output meaning that Data <NUM>' is identical but reverse (e.g., opposite) of Data <NUM>. Data <NUM> at <NUM> can be transmitted as a direct output on rising edge <NUM> and Data <NUM>' at <NUM> can be transmitted as a reverse output of Data <NUM> on the falling edge <NUM>.

The direct output from the memory device (e.g., memory device <NUM> in <FIG>) can be represented by Data <NUM> at <NUM> being transmitted on the rising edge <NUM>. The reverse output from the memory device can be represented by Data <NUM>' at <NUM> being transmitted on the falling edge <NUM>. The application controller (e.g., application controller <NUM> in <FIG>) latching data from the memory device can be represented by Data <NUM> at <NUM> being latched on the rising edge <NUM>. The reverse output from the application controller can be represented by Data <NUM>' at <NUM> being transmitted on the falling edge <NUM>.

The direct output from memory device (e.g., memory device <NUM> in <FIG>) transmitted on the rising edge <NUM>, the reverse output from the memory device transmitted on the falling edge <NUM>, and the output from the application controller (e.g., application controller <NUM> in <FIG>) transmitted on the falling edge <NUM> can be received by a safety controller (e.g., safety controller <NUM> in <FIG>). The safety controller may allow commands to be outputted from the application controller in response to identifying a match between the data from the memory device and the latched data from the application controller.

The memory device (e.g., memory device <NUM> in <FIG>) can be programmed as a double edge device such that the direct data is programmed on every other row of the memory device and the reverse data is programmed adjacent to the corresponding direct data. For example, the direct data can be programmed on even addresses and the reverse data can be programmed on odd addresses so that the direct data is transmitted on the rising edge <NUM> and the reverse data is transmitted on the falling edge <NUM>.

<FIG> is a flow diagram including reverse circuitry outputting data in accordance with a number of embodiments of the present disclosure. The reverse circuitry as shown in <FIG> can be used to reverse the pattern of the data from the memory device <NUM>. The data can be autonomous vehicle data. For example, the data can include photographic data collected from vehicle cameras, and/or data collected from vehicle sensors, but the data is not limited to photographic data or vehicle sensor data.

The memory device <NUM> can store and transmit data. The memory device <NUM> can be coupled to reverse circuitry <NUM>. The memory device <NUM> can transmit data <NUM> to the reverse circuitry. The data transmitted by the memory device <NUM> can be transmitted on a rising edge of a clock and can be a direct output.

The reverse circuitry <NUM> can receive the data as a direct output from the memory device <NUM>. The reverse circuitry <NUM> can copy the direct output and reverse the direct output pattern to create a reverse output. The reverse circuitry <NUM> can transmit the direct output <NUM> from the memory device <NUM> and the reverse output <NUM> to a multiplexer <NUM> (e.g., MUX).

The MUX <NUM> can combine signals. The MUX <NUM> can combine the direct output <NUM> and the reverse output <NUM> into one signal. The MUX <NUM> can include a clock <NUM>. The clock <NUM> can be used to initiate the sending of the second signal to ensure both signals are sent in one signal. For example, the direct output <NUM> can be transmitted on a rising edge (e.g., rising edge <NUM> in <FIG>) to the application controller <NUM> and the safety controller <NUM> until the clock initiates the sending of the reverse output on a falling edge (e.g., falling edge <NUM> in <FIG>) to the application controller <NUM> and the safety controller <NUM>.

The combined signal <NUM> can be received by the application controller <NUM>. The application controller <NUM> can latch the data of the combined signal <NUM>. The data can be latched on a rising edge (e.g., rising edge <NUM> in <FIG>). The latched data can be transmitted to the safety controller. The latched data can be transmitted as an output sent on a falling edge (e.g., falling edge <NUM> in <FIG>) of a signal.

Claim 1:
An apparatus, comprising:
an application controller (<NUM>, <NUM>, <NUM>);
a memory resource (<NUM>, <NUM>, <NUM>) configured to:
store data; and
transmit the data;
a safety controller (<NUM>, <NUM>, <NUM>) coupled to the memory resource,
wherein the safety controller is configured to implement safety measures in applications and is configured to:
receive the data from the memory resource (<NUM>, <NUM>, <NUM>);
receive latched data from the application controller (<NUM>, <NUM>, <NUM>);
compare the data from the memory resource (<NUM>, <NUM>, <NUM>) to the latched data from the application controller (<NUM>, <NUM>, <NUM>); and
transmit a flag in response to identifying a difference between the data from the memory resource (<NUM>, <NUM>, <NUM>) and the latched data from the application controller (<NUM>, <NUM>, <NUM>); and
a multiplexer "MUX" (<NUM>, <NUM>) coupled to the application controller (<NUM>, <NUM>, <NUM>) and the safety controller (<NUM>, <NUM>, <NUM>), wherein the MUX (<NUM>, <NUM>) is configured to allow the output of the commands from the application controller (<NUM>, <NUM>, <NUM>) in response to an absence of the flag and prevent the output of the commands in response to receiving the flag from the application controller (<NUM>, <NUM>, <NUM>).