CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is the national phase of International Application No. PCT/IB2016/001560, filed on Oct. 31, 2016, entitled “SOFTWARE UPDATE MECHANISM FOR SAFETY CRITICAL SYSTEMS”, the entire disclosure of which is expressly incorporated by reference in its entirety.

TECHNICAL FIELD

The present invention relates to a method and a system for updating software in units that are designed specifically under the context to fulfill critical safety requirements.

BACKGROUND

Systems that use software need updating of the software from time to time for reasons varying from adding new features to the existing system, improving on the existing software or fixing of bugs in the software, to name a few. The updating of software in systems or units that are designed specifically under the context to fulfill critical safety requirements is not as simple as an ordinary software update process for a non-safety critical unit or system. Safety critical systems are those systems whose failure or malfunction may result in very serious outcomes. For instance, it could lead to serious injury to human life or death, or severe damage to property or equipment or cause harm to the environment. Such safety critical systems can be found, for example, in the automotive and aviation industry. During a software update process in such safety critical systems, highly complex Electronic Control Units (ECUs) are updated. Therefore, a small pause, or break or fault during a software update in a system which is safety critical could lead to severely dangerous and highly undesirable outcome as compared to the outcome for a non-critical system. Therefore, the software update process has to be much more robust, safe and dependable when it comes to safety critical systems.

Current software update mechanisms are not designed specifically under the context to fulfill critical safety requirements, for example when used to update a compliant ISO26262 Electronic Control Unit (ECU) or a system in the automotive industry, like complex driving assistance ECUs. Modifying existing solutions, for example in the automotive industry targeting from Automotive Safety Integrity Level (ASIL) A up to ASIL D ISO26262 system requirements, would result in a highly costly, challenging and troublesome process.

Also, the software update process for systems that are highly critical must be secure, authentic and verified for correctness, failing which the system could function erroneously or could develop bugs and may crash in future.

There exists no such secure software update mechanism specifically designed for systems that are required to fulfil critical safety requirements, without actually having to alter or redevelop any existing software update mechanism, infrastructure, validation and logic related to non-safety or lower safety critical systems.

BRIEF SUMMARY OF THE EMBODIMENTS

According to one of many embodiments, there is provided a software update monitor configured to receive a software update from a software update component. The software update monitor determines a first verification code based on the received software update. The software update monitor then receives a second verification code associated with the software update from an update server. Next, the software update monitor determines if the first verification code matches with the second verification code. In case the first verification code matches with the second verification code, the software update monitor then effects or applies the software update.

According to an embodiment the software update is intended for a control unit. In another embodiment the control unit is a safety critical control unit.

Implementing a secure software update mechanism using a software update monitor in control units as described herein, for example, in control units that need to comply with safety standards, would give the benefit of avoiding insecure and unreliable software update processes in those control units and at the same time it gives the advantage of not having to alter or redevelop any existing infrastructure, logic or validation processes. The software update monitor can be easily integrated into the existing systems with no or minimum modifications and cost. Additionally it reduces complexity of the system as well as development and certification costs, thereby giving a feasible solution. The software update monitor ensures that the software update is from an authentic source and the data integrity of the software update is maintained. Only after the software update monitor is assured of the data and source verification results the software update is implemented. Thereby, software in safety critical compliant control units can be updated in a safe and hassle-free manner.

According to one embodiment, the software update monitor is configured to write the software update into a target memory location in a memory of the control unit. The software update monitor is further configured to enable switching from a previous memory location, where an older software version may be running, to the target memory location, where the new software update with the latest version of the software is written, only if the first verification code matches with the second verification code. The advantage of pushing the task of writing the software update onto the software update monitor instead of the software update component is that the software update monitor ensures integrity and authenticity of the software update.

According to one of many embodiments a system for implementing a software update in a control unit is provided which comprises of an update server for supplying a software update for the control unit. The system further comprises a software update component for receiving the software update from the update server and processing the software update. According to an embodiment the software update component may contain an update logic that is executed on receipt of the software update. In an exemplary embodiment the software update component processes the software update by way of compression or decompression of the software update as may be necessary depending on the nature of the software update received by the software update component. There may be other update logic executed by the software update component on the software update it receives from the update server to process the software update.

The system also comprises a software update monitor. The software update monitor is connected to the update server and the software update component independently. The software update monitor is arranged to receive a software update from the software update component. The software update sent by the software update component to the monitor may or may not be the same software update received by the update component from the update server. According to an embodiment the software update component processes the software update and sends this processed software update to the monitor. According to another embodiment the software update component sends the same software update that it had received from the update server. The software update monitor then determines a first verification code from the received software update.

In an alternative embodiment, the software update monitor receives the software update from the software update component and processes the software update according to an update logic present on the monitor.

The connection of the software update monitor with the update server is separate and independent from the connection of the software update monitor with the software update component. This ensures that the software update component does not tamper with, affect or influence the communication channel between the software update monitor and the update server. Therefore, when the second verification code is transmitted by the update server to the software update monitor, the software update component cannot snoop on or pick up the second verification code. This ensures complete separation of the transmission of the second verification code from the first verification code.

According to one of many embodiments, the software update monitor further comprises a trusted execution environment for source authentication and data validation of the software update from the software update component. An exemplary trusted execution environment may be a Trusted Platform Module (TPM). In an embodiment the trusted execution environment has a dedicated storage where the software update monitor may store one or more of the verification codes, signatures or any information pertaining to data integrity and authenticity of the software update for use in future. The trusted execution environment provides a platform to check the authenticity of the software update to make sure the software update is coming from a genuine source. It also checks the integrity of the data for consistency and correctness. It makes the overall mechanism secure and protected.

According to one of many embodiments the verification codes comprise a corresponding data verification factor and a corresponding source authentication factor. The software update contains information that is used by the software update monitor to verify if the data in the software update is correct and also to check if the software update is coming from an authentic source. The data verification factor and the source authentication factor are the important information elements in the verification codes that indicate towards data integrity and source authenticity. This helps the software update monitor to decide whether to go ahead with the intended software update or stall the software update, in case there is discrepancy in the data verification factor and/or the source authentication factor.

According to one of many embodiments, the software update is signed by a Root Certificate Authority at the update server. The advantage of signing by an RCA is that the software update may then be assessable for authenticity by the software update monitor using the RCA signature.

According to one of many embodiments, the software update monitor performs a data integrity check and a source integrity check on the software update received from the software update component to derive the data verification factor and the source authentication factor of the first verification code respectively. The data verification factor gives information as to the correctness and consistency of the software code in the software update. The source authentication factor indicates whether the software update is coming from a trusted or a genuine source. In case of discrepancy, the software update monitor can decide not to go ahead with effecting the software update onto the control unit and thereby avoid any mishaps in future due to an unreliable, spurious or an inaccurate software update.

According to one of many embodiments, the data integrity check carried out by the software update monitor comprises a Cyclic Redundancy Code (CRC) check. Using a CRC check the software update monitor can assess the integrity of the software. This error-detecting code can detect accidental changes to raw data in the software update.

According to one of a number of embodiments, the control unit complies with safety critical requirements of ISO26262 or IEC61508 standard. These standards are used for functional safety of electrical and/or electronic systems in production automobiles. ISO 26262 addresses the needs for an automotive-specific international standard that focuses on safety critical components. IEC61508 is a generic functional safety standard for electrical and electronic (E/E) systems. According to another embodiment, the control unit supports Automotive Safety Integrity Level (ASIL) A up to ASIL D. The software update monitor would update the software in such control units complying with such safety critical standards in a safe and secure manner so as not to interfere with the smooth functioning of the control unit and would keep the update process simple and hassle-free. The existing infrastructure and mechanism also need not be greatly modified to integrate the software update monitor.

According to an embodiment, the control unit is an automotive Electronic Control Unit (ECU). The software update monitor can be integrated into an existing system which is used for updating software of an automotive ECU, with the added advantage of providing a mechanism that helps the automotive ECU to continue being compliant with its safety critical standards.

Using a software update monitor as disclosed herein removes the need to invest in costly, challenging and troublesome modifications to systems targeting up to ASIL D ISO 26262 system requirements.

According to an embodiment a method for implementing a software update in a control unit is provided. The method comprises a first step of receiving the software update at a software update component from an update server and supplying the software update to a software update monitor. The next step constitutes writing the software update into a target memory location in a memory of the control unit by the software update monitor. The software update monitor has the permission and owns the necessary right to access the target memory location and write into it.

The next step constitutes calculating a first verification code for the software update by the software update monitor. Then a second verification code associated with the software update is received from an update server by the software update monitor. The software update monitor then determines if the first and second verification codes match. In case the first and second verification codes match, the software update monitor effects the software update at the control unit.

According to one of many embodiments, the step of effecting the software update further comprises enabling switching from a previous memory location to the target memory location if the first and second verification codes match. This ensures that the software update is already available at the target memory location and no time is lost in updating of the software into the control unit once it is determined that the software update is correct and genuine.

According to an alternative embodiment the monitor executes the write operation only after determining that both verification codes match. This would avoid unnecessary write operations into the memory thereby enhancing efficiency and security in case the software update received from the software update component is not authentic or genuine.

The order of the steps as per the various disclosed embodiments is not limiting and the steps may be carried out in a different order than the ones disclosed as long as the result to be achieved is the same.

According to one of many embodiments, switching from the previous memory location to the target memory location takes place at a next power on/off sequence or during a safe state. This ensures minimum interference to an already running control unit and makes sure that the new software update does not cause any adverse effects or hamper the functioning of the safety critical control unit.

According to an embodiment the method is executed on a Hardware Security Module, or similar trusted execution environment, present on a microcontroller. According to one embodiment, examples of a microcontroller that could fulfill this are Infineon Auryx family, Renesas RH850 P1X or ARM Trustzone. The Hardware Security Module on a microcontroller provides the necessary platform to execute the disclosed method in a secure and reliable manner.

According to an embodiment if the first verification code matches the second verification code the software update monitor generates a positive system notification else the software update monitor generates a negative system notification. The system notification helps the system as well as a user to track the progress of the software update process.

According to an embodiment the step of switching comprises sending a switch signal to the memory unit by the software update monitor for switching from the previous memory location to the target memory location. The switch signal ensures a timely swapping from the previously running software version stored in a previous memory location to the latest updated software version stored in the target memory location.

