The present invention relates to a driver assistance apparatus and method, and more particularly a driver assistance apparatus and method for securing operating instructions of a driver assistance apparatus. In order that accidents are avoided and driving laws are complied with, driving a vehicle requires concentration from the driver, often for prolonged periods. Lapses in concentration from the driver lead to increased risk of accidents and/or non-compliance with the law.

Increasingly, driver assistance systems that are capable of performing an assistance function are fitted to the driver's vehicle (hereinafter referred to as the "ego vehicle"). For example, the assistance function may comprise relieving the driver of some of his/her driving duties, or may comprise monitoring the driver's performance in order that errors may be anticipated and/or avoided.

Alternatively, the assistance function may introduce some additional functionality not ordinarily available to a driver. Such additional functionality may allow the driver to have more information than they ordinarily would do, in order that they can perform a driving task more easily or safely. A rear-facing camera for example, which can provide a video feed to a driver when reversing, constitutes an example of such an additional functionality. In this example, the video feed allows the driver to reverse-park more easily and safely but is not actually necessarily monitoring the driver's performance or directly performing a task for them.

Driver assistance systems therefore mitigate risk for the driver of the ego vehicle, his/her passengers, and other road users. Ultimately, driver assistance functions will be developed to such an extent that they can control most or all aspects of driving an ego vehicle. In this case, the driver assistance system will be an autonomous driving system. Driver assistance systems may include active devices, which are capable of actively intervening in the operation of the ego vehicle, for example by changing the speed of the ego vehicle. Driver assistance systems may alternatively, or additionally, include passive devices, which, for example, notify the driver of a particular driving situation so that the user can react to the notification. For example, the driver assistance system may make an audible signal when the ego vehicle deviates across a road marking unexpectedly. A given ego vehicle may include both passive and active systems.

In general, a driver assistance system may include at least one sensor. A particular sensor measures parameters that describe the ego vehicle and/or its surroundings. The data from sensor may be combined. The data from such a sensor is processed in order to draw conclusions based on the sensor measurements. The driver assistance system may trigger an interaction with the ego vehicle, or with the driver, based on the result of the conclusions. In the case of an autonomous driving system, substantially all driving functions are controlled by the system. Examples of potential sensors used in driver assistance systems and autonomous driving systems include RADAR systems, LIDAR systems, cameras, inter-vehicle communications (or vehicle-to-vehicle communications), and vehicle-to-infrastructure communications.

A driver assistance system may be used to control a variety of different aspects of driving safety or driver monitoring. For example, ACC ("Adaptive Cruise Control") may use a RADAR or LIDAR system to monitor the distance between the ego vehicle and the vehicle immediately ahead on the road. Such a sensor is able to determine the distance to the vehicle ahead. The driver assistance system also knows, and can control, the velocity of the ego vehicle. The driver assistance system may control the speed of the ego vehicle in order to maintain a predefined safety condition relative to the vehicle ahead. For example, the driver assistance system may control speed to maintain a certain distance between the ego vehicle and the vehicle ahead. Alternatively, the driver assistance system may control speed to maintain a predetermined time-period between the vehicle ahead passing a point, and the ego vehicle passing the same point.

There are existing driving assistance systems that monitor the surroundings of the ego vehicle to identify the position of other vehicles and entities on or around the road on which the ego vehicle is travelling. By monitoring the surroundings, such a driver assistance system can maintain a situational awareness for the ego vehicle. This situational awareness can be used to notify the driver of potential hazards. For example, the ego vehicle changing lanes when a second vehicle is in a blind spot, or detecting a second vehicle cutting-in to the path of the ego vehicle, may be notified to a driver. The situational awareness may also be used as an input to an ACC system, for example. It will be appreciated that an autonomous driving system may correspond generally to a more comprehensive driver assistance system. Thus, whilst the following discussion focusses on driver assistance systems, the intention is that the present invention is also readily applicable to an autonomous driving system.

5 Because a driver assistance system may perform a variety of safety-critical functionalities (safety of both the driver of the vehicle and others), it is important that any unauthorised interference with the driver assistance system and its operation is detected, and if necessary, acted upon.

In general, a driver assistance system includes an electronic control unit (ECU). The ECU is i o effectively a computing device that can perform tasks according to operating instructions - it can be thought of as the "brain of the driver assistance system". The operating instructions are generally stored on the ECU, and may comprise both software. The software may be compiled machine code, may be source code, or may be code that is compiled Just In Time (JIT). The key feature is that the operating instructions dictate the operation of the ECU and 15 therefore at least part of the driver assistance system. A single ego vehicle may have

multiple ECUs installed therein.

The operating instructions may be updated, for example to increase or change the functionality of the ECU. Updates may take place "over the air", for example via a wireless connection to a communications network, and ultimately from a source of the update. The 20 update may be sent wirelessly to the driver assistance system, whereupon the operating instructions of the ECU are updated. The updates may alternatively be performed across a physical connection to the driver assistance system. Physical-connection updates may be performed when the vehicle is serviced, for example.

In any case, it is important that the updates to the operating instructions are verified as 25 coming from a trusted source, and that the operating instructions have not been tampered with. If they are not verified, then there is potential for malicious alteration of the operating instructions. It is also important to verify that there have not been any inadvertent changes to the operating instructions. In either case, unverified changes to the operating instructions could result in incorrect or unreliable operation of the driver assistance system, which 30 presents a serious safety concern. In the case of malicious changes to the operating

instructions, an unscrupulous party may change the code so that it appears to a driver that the code is working properly, when in fact it is not and the operation of the driver assistance system is unsafe.

This above discussion focuses on updates to the operating instructions, but it is also important to verify an initial installation of the operating instructions. Such an initial installation may occur at the time of manufacture of the driver assistance system.

It is an object of the invention to provide an improved driver assistance apparatus and method of operating a driver assistance system, which seeks to address some or all of these issues.

According to a first aspect, there is provided a driver assistance apparatus for installation in a motor vehicle, the apparatus including a safety electronic control unit ("ECU"), the safety ECU including operating instructions stored thereon that dictate the operation of the safety ECU, the safety ECU further including: a verified hash storage means for storing a verified hash value of at least a portion of the operating instructions; the safety ECU being configured to implement a verification routine, the verification routine including: calculating, using a hash function, a test hash value of the at least a portion of the operating instructions; comparing the test hash value with the verified hash value, and if the test hash value is not equal to the verified hash value, performing a safety routine.

Preferably, the safety ECU includes a program storage means, the operating instructions being stored in the program storage means.

Conveniently, the program storage means and the verified hash storage means are distinct hardware elements within the safety ECU.

Advantageously, the safety routine includes at least one of: disabling the safety ECU;

notifying a user of the vehicle, and; notifying a party located remotely from the vehicle.

Preferably, the hash function includes a Secure Hash Algorithm ("SHA").

Conveniently, the hash function is an SHA-256 algorithm.

Advantageously, the verified hash value is encrypted on the verified hash storage means.

Preferably, the apparatus further including at least one secondary ECU having a respective set of secondary operating instructions, wherein a respective secondary verified hash value of at least a portion of the respective secondary operating instructions on the respective secondary ECU is stored on the verified hash storage means.

Conveniently, the safety ECU being further configured to: request from each secondary ECU a respective secondary test hash value, the respective secondary test hash value being calculated on the respective secondary ECU for the at least a portion of the respective secondary operating instructions; comparing each respective secondary test hash value with the corresponding secondary verified hash value, and if the respective secondary test hash value is not equal to the corresponding secondary verified hash value, performing a respective secondary safety routine. Advantageously, the respective secondary safety routine includes ignoring by the safety ECU any further inbound communication from the respective secondary ECU.

Preferably, the respective secondary safety routine includes at least one of: disabling the respective secondary ECU; notifying a user of the vehicle, and; notifying a party located remotely from the vehicle. According to a second aspect, there is provided a method of verifying the operation of a driver assistance apparatus for installation in a motor vehicle, the apparatus including a safety electronic control unit ("ECU") having operating instructions stored thereon that dictate the operation of the safety ECU, the method including: calculating, using a hash function, a test hash value of at least a portion of the operating instructions; comparing the test hash value with a verified hash value, the verified hash value having been determined for at least a portion of verified operating instructions; and if the test hash value is not equal to the verified hash value, performing a safety routine.

Features of the first aspect of the invention may of course be applied to the second aspect of the invention. So that the invention may be more readily understood, and so that further features thereof may be appreciated, embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which:

Figure 1 shows a vehicle including an example driver assistance system; Figure 2 shows a schematic of a safety electronic control unit (ECU) comprised in a driver assistance system;

Figure 3 shows a schematic of the safety ECU of figure 2 located in a vehicle;

Figure 4 shows an example architecture of the safety ECU of figures 2 and 3, and; Figure 5 shows the safety ECU of figures 2 and 3, networked with four secondary ECUs.

Turning now to consider Figure 1 in more detail, there is illustrated a schematic

representation of an exemplary driver assistance system 1 installed in an ego vehicle 2 (only one side panel of which is denoted in figure 1 to indicate the vehicle's orientation). The driver assistance system 1 comprises a number of different types of sensor mounted at appropriate positions on the ego vehicle 2. In particular, the system 1 illustrated includes: a pair of divergent and outwardly directed mid-range radar ("MRR") sensors 3 mounted at respective front corners of the vehicle 2, a similar pair of divergent and outwardly directed multi-role radar sensors 4 mounted at respective rear corners of the vehicle, a forwardly directed long- range radar ("LRR") sensor 5 mounted centrally at the front of the vehicle 2, and a pair of generally forwardly directed optical sensors 6 (cameras) forming part of a stereo vision system ("SVS") 7 which may be mounted, for example, in the region of the upper edge of the vehicle's windscreen. The various sensors 3-6 are operatively connected to a central electronic control system which is typically provided in the form of an integrated electronic control unit (ECU) 8 mounted at a convenient location within the vehicle. In the particular arrangement illustrated, the front and rear MRR sensors 3, 4 are connected to the ECU 8 via a conventional Controller Area Network ("CAN") bus 9, and the LRR sensor 5 and the sensors of the SVS 7 are connected to the ECU 8 via a faster FlexRay serial bus 9, also of a type known per se.

Collectively, and under the control of the ECU 8, the various sensors 3-6 can be used to provide a variety of different types of driver assistance functionalities such as, for example: blind spot monitoring; adaptive cruise control; collision prevention assist; lane departure protection; and rear collision mitigation. Similar sensors may be used in an autonomous driving system. The system may also include at least one secondary ECU. The or each secondary ECU may communicate with the ECU 8 via the CAN bus or the FlexRay serial bus 9. Secondary ECUs are discussed in more detail below.

An example of the apparatus in accordance with the present invention is shown in Figure 2. The system includes an electronic control unit (ECU) 8 of the type shown in Figure 1 . The ECU 8 is a so-called safety or primary ECU. The safety ECU 8 is connected to an ego vehicle communication network 9 within the ego vehicle 2. The ego vehicle communication network 9 may be a CAN bus or a FlexRay system, for example. A particular ECU 8 may be connected to more than one such network, which may not be of the same types. The safety ECU 8 may communicate with other ECUs in the ego vehicle via the ego vehicle

communication network 9.

The safety ECU 8 is connected to at least one sensor 10. In the example shown in Figure 2, three sensors 10 are connected to the safety ECU 8, although this number of sensors should not be considered limiting. The connections of each of the sensors 10 to the safety ECU 8 may be wired or wireless. The sensor connections may also be via the ego vehicle communication network 9. The connection between each sensor 10 and the safety ECU 8 may be a two-way connection - that is, the safety ECU 8 may receive data from the sensor 10 and the safety ECU 8 may send data and/or commands to the sensors 10. The sensors 10 may be providing information concerning the state of the ego vehicle itself and/or the state of the surrounding environment. The sensors 10 may also provide some data reduction capability - that is determined parameters may be calculated at the sensors 10 and sent to the safety ECU 8 from the sensors 10, rather than (or in addition to) the sensors 10 sending raw measurements performed by the sensors 10 to the safety ECU 8.

The safety ECU 8 is also capable of wireless communication with the internet across a 2-way internet communication link 1 1. The internet includes a cloud computing capability 12, to which the safety ECU 8 may offload processing tasks. The internet communication link 1 1 may comprise a connection to a mobile telephone communications network, for example. The safety ECU 8 may send processing tasks to the cloud 12 over the internet

communication link 1 1 , where the processing task is performed in the cloud 12, before the results of the processing task are sent back to the safety ECU 8 over the internet

communication link 1 1. The internet communication link 1 1 may also provide access to data that is not available immediately to the ECU 8. Such data may include map data, for example.

The internet communication link 1 1 also provides a pathway for over-the-air

update/installation of operating instructions onto the safety ECU 8. The operating instructions are discussed in more detail below.

The safety ECU 8 also has a second wireless communication link 13, which provides access to a distributed functionality 14 external to the ego vehicle. The distributed functionality may include Vehicle-to-Vehicle communications, and/or Vehicle-to-lnfrastructure communications. These may permit driver assistance functionality and/or autonomous driving functionalities in which information can be shared with the ego vehicle, and/or to which the ego vehicle can share information across the second wireless communication link 13.

Figure 3 shows a schematic end view of the ego vehicle 2. The ego vehicle 2 includes a safety ECU 8. Also included in the ego vehicle 2 are two secondary ECUs 15, 16. The safety ECU 8 and the secondary ECUs 15, 16 are interconnected via an in-vehicle communication network 17. The in-vehicle communication network 17 may be a CAN bus, a FlexRay bus, a Local Interconnect Network (LIN) or an Ethernet network, for example.

The ego vehicle 2 also includes a wireless communication transceiver 18, which is operatively connected to the ECU 8 (although that connection is not shown in Figure 3). The wireless communication transceiver 18 is configured for communication with a network 19, via a two-way wireless communication link 20. The network 19 includes storage of operating instructions, and/or operating instruction updates in at least one storage location 21 .

Figure 4 illustrates an example architecture of the safety ECU 8. The safety ECU 8 includes a safety microcontroller unit (MCU) 22 and a performance System on a Chip (SoC) 23. The safety MCU 22 includes a program storage means 24. The program storage means 24 is internal to the safety MCU 22. The program storage means 24 may be flash memory, for example PFLASH. The operating instructions for the operation of the safety MCU 22 are stored on the program storage means 24.

The safety ECU 8 also includes a verified hash storage means 25. The verified hash storage means 25 is external to the safety MCU 22, but internal to the safety ECU 8. The verified hash storage means 25 may be flash memory, for example PFLASH. A verified hash value of the operating instructions (which are stored on the program storage means 24) is stored in the verified hash storage means 25. The verified hash value may have been generated for the data corresponding to a portion of the operating instructions or for data corresponding to the whole of the operating instructions. The verified hash value is generated by a hash function at the time that the operating instructions were produced in a verified and trusted form by the manufacturer (i.e. a trusted source). The verified hash stored on the verified hash storage means 25 is encrypted.

The hash value is calculated by a hash value calculation unit, the hash value calculation unit implementing the hash function. In the embodiment of Figure 4, the hash value calculation unit is the performance System on a Chip (SoC) 23. The SoC 23 implements the hash function that calculates a test hash value. The test hash value may be generated for the data corresponding to a portion of the operating instructions or data corresponding to the whole of the operating instructions as the input data of the hash function.

In general, a hash function (or hash algorithm) is a computational routine that, given input data, generates a hash value (alternatively known as hash code, digest, or hash) of said input data. A hash function is a mathematical algorithm that maps input data of arbitrary size to a bit string of a fixed size (the hash value). Hash functions per se are known, and will not be described in detail here. For a first input data the hash function generates a first hash value. If the first input data is changed, even by only a tiny amount, the probability is extremely high that the hash function (when run on the input data again) will generate a second hash value that is different to the first hash value. Thus, by looking at the hash values of a piece of input data generated by the same hash function at two different times, it is possible to determine with an extremely high degree of certainty whether or not the input data has changed, even by a small amount. It is noted that the underlying meaning or contents of the input data is irrelevant for the purposes of a hash function. The hash function operates on the data at a binary level.

As mentioned, the performance SoC 23 implements the hash function. Thus, the safety ECU 8 is configured to calculate a test hash value for the operating instructions (or a portion thereof). As discussed, the input data to a hash function is simply considered as binary input data. The meaning of the operating instructions in this case is neither important, known, nor used by the hash function. In the present embodiment, the hash function is an SHA-2 algorithm, which is a Secure Hash Algorithm - second generation. The particular algorithm used in the described embodiment generates a 256-bit hash value, and is known as SHA-256. However, the present invention should not be limited to SHA-256 or to SHA-2 algorithms. It will be apparent to the skilled person in light of this disclosure that hash functions in general are suitable for use in the present invention.

The test hash value generated from the operating instructions in the program storage means 24 is compared to the verified hash value stored in the verified hash storage means 25. The verified hash value stored in the verified hash storage means 25 may be encrypted. If the verified hash value on the verified hash storage means 25 is encrypted, then it must be decrypted before the comparison can be made.

There are two possible outcomes of the comparison: either, i) the test hash value and the verified hash value are identical to one another, or ii) the test hash value and the verified hash value are different and thus not identical to one another. Depending on the outcome of the comparison, the safety ECU 8 may be configured to act differently.

If the verified hash value and the test hash value are identical, then the binary content of the operating instructions on the program storage means 24 is overwhelmingly likely to be identical to the binary content of the verified operating instructions that were used to generate the verified hash value. If the binary content is identical, then it follows that the substance of the operating instructions (i.e. the operation of the ECU that those instructions dictate) on the program storage means 24 are identical to the verified operating instructions. In the event that the test hash value and the verified hash value are identical, then the operating instructions on the program storage means have not been tampered with (i.e. they have not been changed relative to the verified operating instructions). If the verified hash value and the test hash value are not identical (i.e. they are different), then the binary content of the operating instructions on the program storage means 24 is overwhelmingly likely to be different to the binary content of the verified operating instructions that were used to generate the verified hash value. If the binary content is different, then it follows that the substance of the operating instructions (i.e. the operation of the safety ECU that those instructions dictate) on the program storage means 24 is different from the verified operating instructions. Accordingly, in the event that the test hash value and the verified hash value are not identical, then the operating instructions on the program storage means may have been tampered with. At the least, they have been changed relative to the verified operating instructions, which may have been malicious.

In any case, if the verified hash value and the test hash value are not identical, the safety ECU 8 may implement a safety routine. The safety routine may include a variety of actions. The action taken during the safety routine may depend on a level of danger presented by a change to the operating instructions on the program storage means 24.

For example, the safety routine may include:

• Disabling the safety ECU 8 entirely, so that it cannot function;

• Notifying a user of the vehicle. Such a notification may include notifying the user of a potential problem with the driver assistance system, or notifying the user that the driver assistance system (or part of it) has been disabled in light of an error;

• Notifying a remotely located party of the unverified operating instructions on the

program storage means. The remotely located party may be the manufacturer of the driver assistance system, or the manufacturer of the vehicle, for example. The safety routine may include any or all of these actions.

The verification sequence (i.e. the calculation of the test hash value, the comparison of the test hash value and the verified hash value, and the potential safety routine) may be performed as part of a boot up routine/sequence of the safety ECU 8. Of course, however, the verification sequence could be performed at any time. The safety ECU 8 may be connected to one or more secondary ECUs also located within the vehicle - see Figure 3, which shows two secondary ECUs 15, 16 connected to the safety ECU via in-vehicle communication network 17.

The ECU 8 of Figure 4 has a COM transceiver 26, which provides for a first in-vehicle communication network connection 27. The first in-vehicle communication network connection 27 may be to a CAN Bus, LIN, or a FlexRay network.

The safety ECU 8 of Figure 4 also has an Ethernet switch 28, which provides for a second in- vehicle communication network connection 30. The second in-vehicle communication network connection 30 is an Ethernet connection. The connection(s) between the safety ECU 8 and the secondary ECUs 15, 16 may be via either the first or second in-vehicle communication network connections 27, 30. Both first and second in-vehicle communication network connections 27, 30 may be utilised. That is, the safety ECU 8 may be connected to one or more secondary ECUs via the first in-vehicle communication network connection 27, and to one or more different secondary ECUs via the second in-vehicle communication network connection 30.

Figure 5 illustrates the safety ECU 8 in a network of ECUs in an ego vehicle. As described in respect of Figure 4, the safety ECU 8 has first and second in-vehicle communication network connections 27, 30. The first in-vehicle communication network connection 27 connects to a first in-vehicle communication network 31. The second in-vehicle communication network connection 30 connects to a second in-vehicle communication network 32.

Each of four secondary ECUs 33 is shown connected to either the first or second in-vehicle communications network 27, 30. Of course, there may be greater or fewer than four secondary ECUs; four is used only as an example to demonstrate the principle. Each secondary ECU 33 includes a secondary program storage means 33A in which the operating instructions for that secondary ECU 33 are stored. Each secondary ECU 33 is configured to implement a hash function for calculating a respective secondary test hash value for that secondary ECU 33. The respective secondary test hash value may be generated for a portion of the operating instructions in the respective secondary program storage means 33A, or for the whole of the operating instructions as the input data of the hash function on the secondary ECU 33.

After each secondary ECU 33 has generated its respective secondary test hash value, it sends that secondary test hash value to the safety ECU 8 via the respective in-vehicle communication network 27, 30 to which it is connected. The secondary ECU 8 then compares each received secondary test hash value with a secondary verified hash value for the respective secondary ECU 33, which is stored on the safety ECU 8. The secondary verified hash values are stored in the verified hash storage means 25, which is part of the safety ECU 8 (see Figure 4). Thus, the verified hash value storage means 25 on the safety ECU 8 stores a collection of verified hash values corresponding to (at least) the secondary ECUs 33 to which the safety ECU 8 is networked. The safety ECU 8 therefore performs a check of the operating instructions for each of the secondary ECUs 33, as stored in corresponding secondary program storage means 33A. If the safety ECU 8 finds that the secondary test hash value is not identical to the

corresponding secondary verified hash value, then the safety ECU 8 may run a secondary safety routine.

The secondary safety routine may include a variety of actions. The action taken may depend on a level of danger presented by a change to the operating instructions on the program storage means 33A of the secondary ECU 33.

For example, the safety routine may include:

• Disabling the secondary ECU 33 entirely, so that it cannot function;

• Ignoring any communications from the secondary ECU 33 with non-identical hash values

• Notifying a user of the vehicle. o Such a notification may include notifying the user of a potential problem with the driver assistance system, or with the specific part of the driver assistance system that is controlled by the secondary ECU 33 with non-identical hash values o or notifying the user that the driver assistance system (or part of it) has been disabled

• Notifying a remotely located party of the unverified operating instructions on the secondary program storage means 33A of the secondary ECU 33. The remotely located party may be the manufacturer of the driver assistance system, the manufacturer of the vehicle, or the manufacturer of the secondary ECU 33, for example.

The secondary safety routine may include any or all of these actions.

When a verified source updates the operating instructions on the safety ECU 8 or on one or more of the secondary ECUs 33, the corresponding verified hash value stored in the verified hash storage means is also updated. The verified source may for example, use the network 19. The network 19 may include a decentralised blockchain in which versions of the operating instructions are stored. The decentralised blockchain includes a plurality of nodes (corresponding to storage locations). Each node of the decentralised blockchain contains a secure copy of the blockchain (in the absence of a change to any of said copies). In other words, each of the nodes has a copy of the blockchain; together the nodes form the distributed blockchain.

Each node includes a copy of the blockchain. Together the blocks form a local copy of the blockchain (local to the node). Each block includes a data section. Each block also includes block metadata. Each block may include a version of the operating instructions and a corresponding verified hash value of those operating instructions.

Thus, future verifications of updated operating instructions sourced from a node of the distributed blockchain, involving the comparison to the verified hash value, are possible. When used in this specification and claims, the terms "comprises" and "comprising" and variations thereof mean that the specified features, steps or integers are included. The terms are not to be interpreted to exclude the presence of other features, steps or integers.

The features disclosed in the foregoing description, or in the following claims, or in the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for obtaining the disclosed results, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.

While the invention has been described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art when given this disclosure. Accordingly, the exemplary embodiments of the invention set forth above are considered to be illustrative and not limiting. Various changes to the described embodiments may be made without departing from the spirit and scope of the invention.