Patent Description:
Motor vehicles increasingly are being equipped with multiple sensor systems capable of feeding live data which can be used to assist a driver of a vehicle while driving or parking. For example, use cases include cameras, LiDAR, RADAR, ultrasound and infrared systems for road sign and/or obstacle detection, road lane detection, parking lane markers, pedestrian detection and the like. LiDAR systems may use the Mobile Industry Processor Interface Camera Serial Interface (MIPI-CSI), for example, MIPI-CSI2, as high speed protocol to send acquisition data to the controller connected. High speed transmissions, such as those in LiDAR applications can have errors showing in the data transmitted. Protocols such as a cyclic redundancy check <NUM> (CRC16) may be implemented, but the transmission is still prone to errors.

The implementation of Comité Consultatif International Téléphonique et Télégraphique (CCITT) CRC16 makes the error detection coverage of the transmitted data packet more robust with respect to the probability of undetected failures. However, a more robust system does not imply error free, and data containing errors can still be received by a receiver and processed further.

<CIT> describes a method and system for securing CSI and DSI links using enhanced authentication and cloud tracking. According to one embodiment, a method comprises receiving at the receiving device an encrypted information signal from the transmitting device. The encrypted information signal includes a unique identifier of the transmitting device. The method further comprises testing whether a whitelist at the receiving device includes the unique identifier of the transmitting device. The encrypted information signal is decrypted producing a retrieved information signal only if the whitelist includes the unique identifier of the transmitting device; and otherwise terminating communication with the transmitting device.

<CIT> describes an example apparatus comprising a memory resource configured to store a private key associated with a vehicle and store a data matrix comprising data corresponding to operation of the vehicle. The apparatus may further include a processing resource configured to generate a first secure message comprising data corresponding to the vehicle, transmit the first secure message, receive a second secure message comprising an updated data matrix, and update the data matrix based, at least in part, on the updated data matrix.

According to a first aspect of the present invention there is provided a data transmitter. The data transmitter comprises a digest generator configured in response to receiving a set of sensor data from a sensor, to generate a digest from the set of sensor data using a cryptographic primitive. The data transmitter further comprises a packet generator configured to generate a series of one or more packets carrying the set of sensor data for transmission, wherein each packet in the series includes a header, the set of data, a footer and the digest. The packet generator is configured to generate an error-detecting code for the set of sensor data of each respective packet and to include the error-detecting code in the packet. The packet generator is further configured to provide the error-detecting code to the digest generator. The digest generator is configured to generate the digest from the set of sensor data and the error-detecting code(s) for each respective packet.

The sensor may be a sensor for capturing image and/or range data, for example, a lidar sensor.

The data transmitter may further comprise an acquisition and quantization module configured to acquire and quantize data from the sensor.

The cryptographic primitive may be a hash function.

The packet generator may be configured to position the digest between footer and the set of sensor data.

The packet generator may conform to a Mobile Industry Processor Interface Camera Serial Interface specification.

The digest generator and packet generator may be implemented in hardware.

The transmitter may be comprised within an integrated circuit.

According to a second aspect of the invention, there is provided a data receiver. The data receiver comprises a digest generator, a digest comparator and a data processor. The data receiver further comprises a packet receiver configured in response to receiving a series of one or more packets carrying a set of sensor data, error detecting code, and a remotely-generated digest of the set of data generated using a cryptographic primitive, to extract the set of sensor data and the error-detecting code and to forward the set of data to the digest generator and to the data processor, and to extract the remotely-generated digest and to forward the remotely-generated digest to the digest comparator. The digest generator is configured in response to receiving the set of data from the packet receiver to generate a locally-generated digest from the set of sensor data and the error-detecting code using the same cryptographic primitive used to generate the remotely-generated digest and to forward the locally-generated digest to the digest comparator. The digest comparator is configured to compare the remotely-generated digest and the locally-generated digest and to signal to the data processor whether the remotely-generated digest and the locally-generated digest are the same or different so as to indicate an absence or presence respectively of a transmission error.

The data receiver may be a microcontroller or system-on-a chip.

According to a third aspect of the invention, there is provided a system comprising a data bus, the transmitter and the receiver. The data transmitter is operatively connected to the data bus. The data receiver is operatively connected to the data bus.

According to a fourth aspect of the invention there is provided a vehicle comprising the system. The vehicle may be a motor vehicle.

According to a fifth aspect of the invention there is provided a method for generating a digest and a packet comprising the digest. The method comprises generating a digest from a set of sensor data and an error-detecting code using a cryptographic primitive, wherein ther error-detecting code is generated for the set of sensor data of each respective packet.

The method further comprises generating a series of one or more packets carrying the set of sensor data and the error-detecting code for transmission, wherein each packet in the series includes a header, the set of data, a footer and the digest.

According to a sixth aspect of the invention there is provided a method for validating data. The method comprises extracting a set of data from a series of one or data packets. The method comprises extracting a remotely-generated digest generated using a cryptographic primitive from the one or more data packets. The method comprises generating a locally-generated digest from the set of sensor data and an error-detecting code using the same cryptographic primitive. The method further comprises comparing the remotely-generated digest and the locally-generated digest. The method further comprises signalling whether the remotely-generated digest and the locally-generated digest are the same or different so as to indicate an absence or presence of a transmission error.

According to a seventh aspect of the invention, there is provided a computer program comprising instructions which, when executed by at least one processor, causes the at least one processor to perform the method for generating a digest and a packet comprising the digest and/or validating data.

According to a eighth aspect of the present invention is provided a computer program product comprising a computer readable medium (which may be non-transitory) storing the computer program.

Referring to <FIG>, a motor vehicle <NUM> is shown.

The motor vehicle <NUM> includes an advanced driver assistance system <NUM>. Advanced driver assistance systems are systems which help a driver during driving or parking, for example, by warning the driver when they are close to objects, or when they are straying from a lane on a road.

The system <NUM> includes one or more sensor modules <NUM>, a sensor fusion unit <NUM>, and a vehicle control unit <NUM>. Sensor modules <NUM> may be, for example, LiDAR, Radar, camera, ultrasound or infrared systems and the like. The system <NUM> may include multiple sensor modules <NUM> of different types, for example, the system <NUM> may include multiple camera sensor modules and also multiple LiDAR sensor modules. The system <NUM> further includes a head unit <NUM> and, optionally, a display <NUM>. The head unit <NUM> is an information and/or entertainment component providing a unified hardware interface for the system <NUM>. The head unit <NUM> further includes a microcontroller <NUM>. The vehicle control unit <NUM> and head unit <NUM> are connected to an in-vehicle communications bus <NUM>. The in-vehicle communications bus <NUM> may be, for example, a communication bus, a Controller Area Network (CAN) interface, FlexRay, Media Oriented System Transport (MOST) interface, Auto-Ethernet, or PCI-Express. The bus <NUM> receives data <NUM> from the vehicle control unit <NUM> and sends data <NUM> to the microcontroller <NUM>. The sensor fusion unit <NUM> receives validated data from one or more sensor modules <NUM> and merges the data. This merged data is then transferred to the vehicle control unit <NUM> which can make decisions on vehicle control in response to data received from the sensor fusion unit <NUM>.

Referring to <FIG>, the sensor module <NUM> includes a sensor <NUM>, and may optionally include an emitter <NUM>. The sensor module <NUM> further includes an integrated circuit <NUM> and a microcontroller <NUM>. The sensor <NUM> included in the sensor module <NUM> will depend on the type of sensor module <NUM>, for example if the sensor module <NUM> was a LiDAR sensor module the sensor <NUM> would be one or more photo-receivers (e.g. photodiodes) and the emitter <NUM> would be one or more lasers. The sensor <NUM> may be, for example, one of a camera, a thermometer, an altimeter, a hygrometer, a microphone, Radar, ultrasound or infrared and the like. The sensor <NUM> receives inputs from the environment, for example through ambient light reflected off an object (not shown) onto a camera sensor, or from a laser emitted from the emitter <NUM> reflected off an object (not shown) and onto the photodiode. The sensor <NUM> transmits data <NUM> from this input to the integrated circuit <NUM> which may be an Application Specific Integrated Circuit (ASIC), for example, a LiDAR ASIC. The integrated circuit <NUM> includes an acquisition and quantization module <NUM>, a cryptographic primitive module <NUM> and an interface <NUM>. The interface <NUM> may be, for example, a Mobile Industry Processor Interface (MIPI). As will be explained in more detail later, the acquisition and quantization module <NUM> of the integrated circuit <NUM> acquires and quantizes data <NUM> from the sensor <NUM>, passes the data <NUM> to the cryptographic primitive module <NUM> and passes the quantized and processed data to a microcontroller <NUM> via the interface <NUM>. The microcontroller <NUM> includes an error detection module <NUM>, system memory <NUM>, a CPU subsystem <NUM> which includes a CPU (not shown) and a bus system <NUM>. As will be explained in more detail later, the microcontroller <NUM> analyses and verifies the data <NUM> using the error detection module <NUM> and forwards the verified data <NUM> for further processing and/or transmission to a sensor fusion unit <NUM>. Optionally, the sensor module <NUM> may include a bus system <NUM> to connect the integrated circuit <NUM> to the microcontroller <NUM>. In some embodiments, the interface <NUM> of the integrated circuit <NUM> is connected to the microcontroller <NUM>.

Referring to <FIG>, the sensor <NUM> senses the environment (for example, by receiving reflected laser emissions from an emitter <NUM>, or by receiving an image on a camera sensor), and generates a set of data <NUM> from the information received. Each set of data <NUM> received is a sampling event. The set of data <NUM> is transmitted from the sensor <NUM> to the integrated circuit <NUM>. When the data <NUM> is received by the integrated circuit <NUM> it enters the acquisition and quantization module <NUM> where the data <NUM> is sampled and quantized. The acquisition and quantization module <NUM> generates a stream of data <NUM> (herein also referred to as a "payload") which is sent to both the message digest generating module <NUM> and the interface <NUM>.

Referring also to <FIG>, the payload <NUM> may also include error detecting code <NUM> such as a cyclic redundancy check (CRC), for example, the output from a CRC32 algorithm. If the payload <NUM> does not include error detecting code <NUM>, the quantized data stream forms the payload <NUM>. The payload (herein also referred to as a "message") is then sent to the cryptographic primitive module <NUM> which generates a message digest <NUM> (herein also referred to as a "digest", or "DIGEST_stream") using a cryptographic primitive, for example, a cryptographic hash function. A cryptographic hash function is a mathematical algorithm that generates a bit string of a fixed size from data (i.e. a "message") of an arbitrary size. It is a one-way function, that is, it a function that is difficult to invert, meaning that the message cannot be generated form the message digest. Preferably, the cryptographic primitive is deterministic, that is, that the same digest is generated for a given message each time. Preferably, it is infeasible to find two different messages with the same hash value. The message digest can therefore act in a similar way to a human fingerprint, allowing the identification of the message from the message digest.

The algorithm used in the cryptographic primitive module <NUM> may be, for example, a Secure Hash Algorithm (e.g. SHA-<NUM>, SHA256 etc.), an Advanced Encryption Standard (AES), a Data Encryption Standard (DES) and the like. The message digest <NUM> may be, for example, a one-way hash, but other suitable message digests <NUM> may be used. Message digests <NUM> may also be combined. The size of the message digest <NUM> depends on the cryptographic primitive used, for example, the SHA-<NUM> has a message digest result of <NUM> bits.

The message digest <NUM> is appended to the payload <NUM> and then both are sent to the interface <NUM>. The interface <NUM> generates a packet <NUM> which includes a header <NUM>, a payload <NUM>, the DIGEST_stream <NUM> generated from the payload <NUM> and a footer <NUM>. The interface <NUM> then sends the packet <NUM> to the sensor module microcontroller <NUM>. The payload <NUM> may have any suitable minimum length, and a maximum length of (<NUM><NUM> - <NUM>)/<NUM> bytes.

The DIGEST_stream <NUM> may be positioned after the payload <NUM> in the packet <NUM>, that is, between the payload <NUM> and the footer <NUM>. As will be explained in more detail later, positioning the DIGEST_stream <NUM> after the payload <NUM> may help to optimize the performance of the sensor module <NUM>. The payload <NUM> in the packet <NUM> can be closed-ended or open-ended if the interface <NUM> is an MIPI. Alternatively, if the interface <NUM> is a serial flash, the read can be open-ended. During an open-ended transmission, the size of the data being received is not known before the act of receiving it starts and the data stops being received when the microcontroller <NUM> closes the communication. For example, a continuous burst mode of data, e.g. software for configuring a Field-programmable gate array (FPGA), the final byte of the configuration data is not known. In a closed-ended close-ended transmission, the size of the packet is defined before being received. For example, for MIPI-CSI2 8KB packets, it is known in advance when the last byte will arrive. Other commands have lengths depending on the command purpose, for example, a configuration command, e.g. writing a register with a content, can have a reduced length in the address size and in the data size. Another example would be a reset command which may be without arguments. Such a command may happen in the Serial Peripheral Interface (SPI) protocol where the transmission is closed when the chip select signal changes polarity; this is the edge where the bits are converted in instruction and the argument, if present, is taken in consideration.

Referring to <FIG>, error detection module the sensor module <NUM> of the microcontroller <NUM> includes a packet receiving and packet distribution module <NUM> for distributing packets <NUM> and a message digest generating module <NUM>. The microcontroller <NUM> further includes a data validation module <NUM> (herein also referred to as a 'digest comparator'), and a data processing and/or elaboration module <NUM>.

The packet receiving and packet distribution module <NUM> receives a packet from the sensor module interface <NUM> included in the integrated circuit <NUM>. The sensor module microcontroller <NUM> extracts the payload <NUM> and DIGEST_stream <NUM> from the packet <NUM>. The packet receiving and packet distribution module <NUM> sends the payload <NUM> to the data processing and/or elaboration module <NUM> and to the microcontroller message digest generating module <NUM>. As will be explained in more detail later, the payload <NUM> may not be processed further until the payload <NUM> is validated. The DIGEST_stream <NUM> is sent to the validation module <NUM>.

The microcontroller message digest generating module <NUM> generates a message digest <NUM> (herein also referred to as a "digest", or "DIGEST_calculated") from the payload <NUM> using the same algorithm as the integrated circuit cryptographic primitive module <NUM>. The DIGEST_calculated <NUM> is then sent to the validation module <NUM>.

DIGEST_calculated <NUM> is calculated by the microcontroller message digest generating module <NUM> as it receives and extracts the payload <NUM> from the interface <NUM>, in other words, the DIGEST_calculated <NUM> is calculated "on the fly" as the microcontroller <NUM> received the packet <NUM>. This means that the DIGEST_calculated <NUM> is generated as the DIGEST_stream <NUM> is received by the validation module <NUM>. This allows for the DIGEST_calculated <NUM> and DIGEST_stream <NUM> to be compared as soon as the DIGEST_calculated <NUM> is generated, reducing the overheads required for transmitting and/or storing the DIGEST_calculated <NUM> and/or the DIGEST_stream <NUM>.

The validation module <NUM> then compares the DIGEST_stream <NUM> with the DIGEST_calculated <NUM>. If DIGEST_stream <NUM> and DIGEST_calculated <NUM> do not match, the payload <NUM> sent to the data processing and/or elaboration module <NUM> is discarded and/or retransmitted and/or other counter measures will be undertaken by the microcontroller <NUM> and/or by the sensor fusion unit <NUM>, providing the vehicle <NUM> driver with the correct data <NUM> and/or communication. If DIGEST_stream and DIGEST_calculated match, this indicates that the payload <NUM> received by the sensor module integrated circuit <NUM> from the sensor <NUM> and the payload <NUM> received by the sensor module microprocessor <NUM> are the same and free from errors, the payload <NUM> is therefore validated. A validated payload <NUM> can then be used for further data processing and/or data elaboration and/or transmitted to the sensor fusion unit <NUM>. Examples of further data processing or data elaboration are communication to the vehicle control unit <NUM> and/or sensor fusion unit <NUM> of processed data to recognize, for example, obstacles, road lines, vertical and horizontal road indications, etc..

Referring to also to <FIG>, the payload <NUM>, DIGEST_stream <NUM>, DIGEST_calculated <NUM> and/or digest generating code may be stored in the system memory <NUM>. In some embodiments, the computation of the digest may be performed by the CPU <NUM> of the CPU subsystem <NUM>. The packet acquisition and distribution module <NUM>, cryptographic primitive module <NUM>, validation module <NUM> and data processing and/or elaboration module <NUM> may be peripheral modules.

The microcontroller <NUM> may include other peripheral modules (not shown), such as other communications network controllers (for other different types of communications network), timers and the like.

Errors may be injected into data <NUM> in high-speed transmission mode. The probability of errors occurring (Perr) is symmetric (i.e. Perr (<NUM> →<NUM>) = Perr(<NUM>→<NUM>) = <NUM>). The Bit Error Rate (BER) is the likelihood of a bit misinterpretation due to electrical noise and is independent on high-speed data communications physical layer standard (MIPI-PHY) configuration. BER is caused by system level induced (Gaussian) noise and, in the case of a LiDAR sensor module, is typically lower than <NUM>-<NUM>. The BER varies depending on the sensor module type and configuration. The CCITT 16bit-CRC (0x8810) is used for "failsafe" error detection, according to MIPI-CSI2 standard. Assuming N = number of bits for a given data payload <NUM>, and BER = Bit Error Rate, the Payload Error Probability (PEP) can be expressed by: <MAT>.

The LiDAR operating modes and related data bandwidths may be, for example, as follows:.

The bandwidths may be higher or lower depending on the architecture of the LiDAR.

In the case where there are no error correction codes, every (detected) bit error in the data payload implies the re-transmission of the entire data payload <NUM>. Therefore, the PEP may result in a loss of data bandwidth performance. In other words the theoretical data bandwidth in absence of noise (BWNOM; i.e. where BER = <NUM>), the effective data bandwidth (BWEFF) as resulting in case of BER ≠ <NUM>, is expressed by: <MAT>.

Notably, the effective data bandwidth is independent on the error detection strategy.

The error-correcting code (ECC) allows <NUM>-bit error correction and <NUM>-bit detection. Therefore, the estimation of undetected errors in the short packets can be performed by considering the safe communication cases, as follows:.

These probabilities can be expressed as follows: <MAT> <MAT> <MAT>.

Therefore, the upper bound (i.e. worst case) of the probability of undetected errors Pud can be expressed by: <MAT>.

The probability of having three or more bit errors in a one short packet is given by:.

Notably, not all bit error combinations higher than two are undetected by ECC. Therefore, this justifies the definition of Pud as the upper bound probability of undetected errors. As such, it can be considered a conservative estimation of safety critical failures. The related conversion in failure rate (FIT) depends on the number of short packets transmitted per hour.

A long packet data stream consists of three elements: a <NUM>-bit packet header (PH), an application specific data payload with a variable number of <NUM>-bit data words, and a <NUM>-bit packet footer (PF). Both the header and the footer are short packets. The <NUM>-bit payload of the header <NUM> is typically the words counter of the central bulk data payload. The <NUM>-bit payload of the footer is typically the CRC of the central bulk data payload. Thus the <NUM>-bit CRC of the bulk data, as limited to <NUM> KB according to CRC, is protected by a dedicated <NUM>-bit ECC.

The standard CRC used for the bulk data is CRC16-CCITT (0x8810). The CRC16-CCITT can detect all single and double bit errors (Hamming distance (HD) = <NUM>), all three errors up to <NUM>,<NUM> data bit (HD = <NUM>), all errors with an odd number of bits, all burst errors of length <NUM> or less, <NUM>% of <NUM>-bit error bursts and/or <NUM>% of <NUM>-bit and longer bursts.

Table <NUM> shows the BER for different sizes of payload.

There is therefore a high probability of errors occurring in the high-speed communication using the MIPI interface. The CRC-<NUM> can reduce the probability of errors being undetected. However, the CRC-<NUM>, and other error detection methods use the Hamming distance to measure the power of error detection and eventual error correction.

The present application uses the probability that two different digests are equal, when an error occurs in the same stream generating the digest. Message digests, for example, SHA256, are very robust against errors. For example, the probability that DIGEST_stream <NUM> and DIGEST_calculated <NUM> will be the same in the presence of one or more bit errors is <NUM> ×<NUM>-<NUM>. Such a method may reduce the probability of collisions, that is, in this case, where the microcontroller <NUM> verifies the payload <NUM> received from the sensor module <NUM> which contain errors. In other words, generating the DIGEST_stream <NUM> and the DIGEST_calculated <NUM> and comparing the two to determine whether they match or not reduces the probability of not detecting errors in the transmission of data.

Referring to <FIG>, the sensor module integrated circuit <NUM> receives a data <NUM> from sensor <NUM> and generates a payload <NUM> containing the data <NUM> (step S1). The payload <NUM> is then transmitted to the cryptographic primitive module <NUM> where a message digest (DIGEST_stream) <NUM> is generated (step S2). The interface <NUM> then receives the payload <NUM> and the DIGEST_stream <NUM> (step S3). The interface <NUM> then generates a packet <NUM> which includes a header <NUM>, the payload <NUM> which includes the data <NUM>, the DIGEST_stream <NUM> and a footer <NUM> (step S4).

Referring to <FIG>, the payload <NUM> is validated before being processed further by the driver assist system <NUM> to ensure the data <NUM> in the payload <NUM> received by the sensor module microcontroller <NUM> is the same data <NUM> as the sent to the sensor module integrated circuit <NUM> by the sensor <NUM>. To validate the payload <NUM>, the microcontroller <NUM> receives a packet <NUM> from the interface <NUM> (step S11). Next, the cryptographic primitive module <NUM> of the microcontroller <NUM> generates a message digest (DIGEST_calculated) <NUM> form the payload <NUM> (step S12). The generation of the DIGEST_calculated <NUM> may be performed on the fly as the packet <NUM> is received. The message digest generator <NUM> uses the same algorithm to generate the DIGEST_calculated <NUM> as is used to generate the DIGEST_stream <NUM> in the sensor module integrated circuit cryptographic primitive module <NUM>. Alternatively, the payload <NUM> and/or the DIGEST_stream <NUM> may be stored in system memory <NUM> to be analysed at a later point. The microcontroller data validation module <NUM> then compares the DIGEST_stream <NUM> with the DIGEST_calculated <NUM> (step S13). If the DIGEST_stream <NUM> and DIGEST_calculated <NUM> do not match, the payload <NUM> is discarded (step S14). If the DIGEST_stream <NUM> and DIGEST_calculated <NUM> do match, the payload <NUM> is validated (step S15). Once the payload <NUM> is validated, further processing and/or data elaboration can take place (step S16).

An example of a message digest function is a hash function. A hash function is used to construct a short digest of a set of data. The digest is smaller in size than the original data, but is capable of identifying a data set without providing details of the contents of the data. It is unlikely that two different sets of data have the same digest.

The hash function is able to map a message of arbitrary finite length L to another message of fixed length Ld where Ld<L. For example, the domain of a function may be the content of a memory block (or of the whole array) and the image can be a string of Ld = <NUM> bit.

The hash function may be preimage resistant and/or second preimage resistant and/or collision resistant. Typically, a function that satisfies all of these properties is suitable for use as a hash function for a data integrity check, although different scenarios may have different requirements and priorities. The choice of hash function is based on the degree of resistance for each of preimage attacks, second preimage attacks and its collision resistance. Further, the resources needed for the function may also be used when deciding on the function to use.

The hash function may be the SHA-<NUM> algorithm as defined by the United States of America Department of Commerce Federal Information Processing Standards Secure Hash Standard (SHS) publication FIPS PUB <NUM>-<NUM>. A message, M, may have an arbitrary length, and may have a maximum length of (<NUM><NUM> - <NUM>)/<NUM> bytes. The message, M, may be padded to have a length, L, which is a multiple of <NUM> bits (i.e., the length L may have a multiple of <NUM>N<NUM>, so that, L = N · <NUM>N<NUM>). The message M may be split into multiple blocks, with fixed length M<NUM> = M<NUM> | M<NUM> |. Each block may be <NUM> bytes.

Claim 1:
A data transmitter (<NUM>) comprising:
a digest generator (<NUM>) configured in response to receiving a set of sensor data (<NUM>) from a sensor (<NUM>) to generate a digest (<NUM>) from the set of sensor data using a cryptographic primitive; and
a packet generator (<NUM>) configured to generate a series of one or more packets (<NUM>) carrying the set of sensor data for transmission, wherein each packet in the series includes a header (<NUM>), the set of data, a footer (<NUM>) and the digest,
characterized in that :
the packet generator is configured to generate an error-detecting code (<NUM>) for the set of sensor data of each respective packet and to include the error-detecting code in the packet,
the packet generator is further configured to provide the error-detecting code to the digest generator, and
the digest generator is configured to generate the digest from the set of sensor data and the error-detecting code(s) for each respective packet.