Updating vehicle electronic control unit software

Abstract

A control system (100) for use in updating software in a plurality of electronic control units, ECUs (112, 114, 116), of a vehicle (200). The control system receives software data (104) comprising sof

Description

TECHNICAL FIELD The present disclosure relates to updating vehicle electronic control unit software. Aspects of the invention relate to a control system, a vehicle system, a vehicle, a method, and computer readable instructions. BACKGROUND It is known to provide electronic control units (ECUs) in a vehicle. Each ECU controls the operation of one or more systems of the vehicle. Modern vehicles may have tens of ECUs, each of which is responsible for a different system or sub-system of the vehicle. Examples of systems controlled by ECUs include the HVAC and infotainment systems. It may be desirable to update software run by one or more of the ECUs. It is an aim of the present invention to address one or more of the disadvantages associated with the prior art. SUMMARY OF THE INVENTION Aspects and embodiments of the invention provide a control system, a vehicle system, a vehicle, a method, and computer readable instructions as claimed in the appended claims. According to an aspect of the present invention there is provided a control system for use in updating software in a plurality of electronic control units, ECUs, of a vehicle, the control system comprising one or more processors collectively configured to: receive software data comprising software update information associated with one or more of the ECUs; verify the software update information using a cryptographic protocol; and responsive to successful verification of the software update information according to the cryptographic protocol, output a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU. This may enable ECU software to be updated in a verified manner without individual ECUs needing to perform the verification. The control system may comprise one or more controllers collectively comprising at least one electronic processor having an electrical input for receiving an input signal; and at least one memory device electrically coupled to the at least one electronic processor and having instructions stored therein; and wherein the at least one electronic processor is configured to access the at least one memory device and execute the instructions thereon so as to: receive software data comprising software update information associated with one or more of the ECUs; verify the software update information using a cryptographic protocol; and responsive to successful verification of the software update information according to the cryptographic protocol, outputting a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU. The cryptographic protocol may be an asymmetric encryption protocol. The use of an asymmetric encryption protocol may enable an improved level of security. The one or more processors may be collectively configured to, prior to verifying the software data: receive a security certificate associated with an entity; and authenticate the certificate. This may enable an improved level of security. At least some of the software updates sent to the ECUs may be encrypted using a further cryptographic protocol. This may enable compatibility with ECUs that use a different cryptographic protocol to the cryptographic protocol used by the control system to verify the software data. The further cryptographic protocol may be a symmetric encryption protocol. The one or more processors may be configured to: identify, at least partly based on at least one address offset within the software update information, at least one ECU with which the software update information is associated; and send each software update to the corresponding identified ECU, each software update being based on an address range of the software update information, the address range being associated with the address offset based upon which the corresponding identified ECU was identified. This may enable convenient mapping between addresses of the software update data and the ECUs. The one or more processors may be configured to: extract the corresponding address range from the software update information; convert the extracted corresponding address range into a further address range for the corresponding identified ECU; and send each software update to the further address range for the corresponding identified ECU. This may enable efficient conversion of address ranges within the software update information to address ranges of the ECUs. The one or more processors may be collectively configured to convert the corresponding address range within the software update information into the further address range for the corresponding identified ECU by subtracting the corresponding address offset from each address within the corresponding address range. The one or more processors may be collectively configured to identify the ECU by using a lookup table, the lookup table containing a mapping between address offsets and ECUs. This may enable simple identification of the ECU to which each software update relates. The lookup table may define an address range for each ECU, each address range being associated with an address offset. The one or more processors may be collectively configured to, after converting the extracted corresponding address range into a further address range for the corresponding identified ECU, re-encrypt at least some of the software updates using the further cryptographic protocol. According to a further aspect of the present invention there is provided a vehicle system comprising the control system of any disclosed aspect and a plurality of the ECUs. At least one of the ECUs may be configured to verify the software update it receives. At least one of the ECUs may be configured to verify the received software update using a symmetric encryption protocol. At least one of the ECUs may be incapable of implementing the cryptographic protocol used by the control system to verify the software data. According to a further aspect of the present invention there is provided a vehicle comprising the vehicle system of any disclosed aspect. According to a further aspect of the present invention there is provided a method for use in updating software in a plurality of electronic control units, ECUs, of a vehicle, the method comprising: receiving software data comprising software update information associated with one or more of the ECUs; verifying the software update information using a cryptographic protocol; and responsive to successful verification of the software update information according to the cryptographic protocol, outputting a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU. According to a further aspect of the present invention there is provided computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform method according to an embodiment the invention. According to a further aspect of the present invention there is provided a control system of a vehicle, the control system comprising one or more processors collectively configured to: receive software update information associated with one or more of the ECUs; verify the software update information using a cryptographic protocol; and responsive to successful verification of the software update information according to the cryptographic protocol, output a software update for each of the one or more ECUs. According to a further aspect of the present invention there is provided a control system for updating software in a plurality of electronic control units, ECUs, of a vehicle, the control system comprising one or more processors collectively configured to: receive software data comprising software update information associated with one or more of the ECUs; identify, at least partly based on at least one address offset within the software update information, at least one ECU with which the software update information is associated; and output a software update for each identified ECU, each software update being based on an address range of the software update information, the address range being associated with the address offset based upon which the corresponding identified ECU was identified. Identifying an ECU based on an address offset may allow for more a smaller software transmission, and may allow the use of existing communications protocols without modification. The one or more processors may be collectively configured to: generate each software update, where generating each software update includes converting, based on the address offset, the corresponding address range within the software update information into a further address range for the corresponding identified ECU. The one or more processors may be collectively configured to: convert the corresponding address range within the software update information into the further address range for the corresponding identified ECU by subtracting the corresponding address offset from each address within the corresponding address range. The one or more processors may be collectively configured to identify the ECU by using a lookup table, the lookup table containing a mapping between address offsets and ECUs. The lookup table may define an address range for each ECU, each address range being associated with an address offset. Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and / or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and / or features of any embodiment can be combined in any way and / or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and / or incorporate any feature of any other claim although not originally claimed in that manner. BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows a vehicle in accordance with an embodiment of the invention; Figure 2 shows a schematic diagram of the vehicle of Figure 1, comprising a control system in accordance with an embodiment of the invention, and an offboard vehicle tester; Figure 3 shows a simplified schematic diagram of the vehicle and offboard vehicle tester of Figure 2; Figure 4 shows a schematic diagram of an electronic control unit (ECU) of the vehicle of Figures 1 to 3; Figure 5 is a schematic view of a binary file for use with an embodiment of the invention; Figure 6 shows a flowchart of a method of updating software of an ECU, in accordance with an embodiment of the invention; Figure 7 is a schematic view of a further binary file for use with an embodiment of the invention; Figure 8 to 10 show a flowchart of a method of updating software of an ECU, in accordance with a further embodiment of the invention; and Figure 11 shows a flowchart of a method of updating software of an ECU, in accordance with a further embodiment of the invention. DETAILED DESCRIPTION A control system in accordance with an embodiment of the present invention is described herein with reference to the accompanying Figure 2. With reference to Figure 2, there is illustrated a control system 100 for a vehicle. The control system 100 comprises one or more controller 102. The control system 100 is configured to receive software data 104 (as described in more detail below). The control system 100 may verify the software data 104 using a cryptographic protocol, and then output software updates 106,108,110 for respective electronic control units (ECUs) 112,114,116 of the vehicle 200. The control system 100 as illustrated in Figure 2 comprises one controller 102, although it will be appreciated that this is merely illustrative. The controller 102 comprises processing means 118 and memory means 120. The processing means 118 may be one or more electronic processing device 118 that operably executes computer-readable instructions. The memory means 120 may be one or more memory device 120. The memory means 120 is electrically coupled to the processing means 118. The memory means 120 is configured to store instructions, and the processing means 118 is configured to access the memory means 120 and execute the instructions stored thereon. The controller 102 comprises an input / output (I / O) means 122. The I / O means 122 may comprise separate input and output means (not shown), comprising respective electrical inputs and outputs of the controller 102. The I / O means 122 may be configured to communicate over a physical and / or wireless connection, for example as described in the embodiments below. The I / O means 122 is arranged to receive the software data 104 from, for example, an external vehicle tester 126 that, when in use, is physically (i.e., hardwired) or wirelessly connected to the controller 102. The software data 104 comprises software update information associated with one or more of the ECUs 112,114,116. The I / O means 122 is arranged to output, under the control of the controller 102, the software updates 106,108,110 for one or more of the ECUs 112,114,116. Each software update 106,108,110 is based on software update information associated with the corresponding ECU 112,114,116. Figure 2 omits optional functional components that may be present in some embodiments. For example, the control system 102 (or the vehicle 200) may comprise a gateway or other communication controller, disposed between the tester 126 and the I / O means 122. Alternatively, or in addition, at least part of the communication between the tester 126 and the control system 102 may be via a vehicle diagnostics network (not shown). Figure 1 illustrates a vehicle 200 according to an embodiment of the present invention. The vehicle 200 comprises a control system 100 as illustrated in Figure 1, and may take the form of a road-going or offroad car, van, truck, or the like. Turning to Figure 3, there is shown a simplified schematic of the control system 100 and ECUs 112,114,116 in the vehicle 200. The control system 100 in this example takes the form of a master controller 100 (hereinafter the “master 100”). Also shown is a gateway 128, which acts as a communication controller between the vehicle tester 126 and the master 100. The vehicle tester 126 is configured for temporary connection to the master 100 for the purposes of updating the operating software of the ECUs 112,114, 116. The connection between the vehicle tester 126 and the gateway 128 can be physical (e.g., hardwired) and / or wireless, depending upon the implementation. Each ECU 112, 114,116 comprises an embedded system for controlling the operation of one or more systems of the vehicle 200. Modern vehicles may have tens of ECUs, each of which is responsible for a different system or sub-system of the vehicle. Examples of systems controlled by ECUs include the vehicle’s HVAC and infotainment systems. Figure 4 shows a schematic of the ECU 112. The ECU 112 includes a processor 300 operatively coupled with a memory 302. The memory 302 comprises non-volatile memory, such as flash memory, for storing operating software. The memory may also comprise working memory, which may be volatile. An input / output (I / O) interface 304 operatively couples the ECU 112 to the I / O means 122 of the controller 102. This I / O interface 304 allows for two-way communication between the ECU and the controller 102. Although only ECU 112 is described in detail, the other ECUs 114, 116 may have similar components and features. Optionally, one or more of the ECUs can conform to the 18014229 (Unified Diagnostics Services) standard. Operation of the master 100 to allow updating, by the tester 126, of the software stored in the ECUs 112,114,116 will now be described with reference to flowchart 400 shown in Figure 6. A general operating principle of the implementations shown in flowchart 400 (and the command sequence 500 shown in Figures 8 to 10) is that the vehicle tester 126 does not communicate directly with the ECUs 112,114,116. Instead, communication is between the vehicle tester 126 and the master 100. The master 100 takes care of communications and data flow between the master 100 and the ECUs 112,114,116. This is in contrast with known systems, in which the master merely acts as a gateway allowing the tester to communicate and exchange data directly with the ECUs. These comments are particularly applicable when at least some of the ECUs are compliant with the 18014229 (Unified Diagnostics Services) standard. The process of the flowchart 400 starts at 402. At 404, communication is established between the vehicle tester 126 and the master 100. As described above, communication between the vehicle tester 126 and the master 100 can be by way of a wired and / or wireless connection, and can optionally be via a gateway and / or a diagnostics network, depending on the implementation. The procedure required for establishing communication between the vehicle tester 126 and the master 100 will be dependent upon the communication network type(s) supported by the master 100. For example, if the master 100 communicates using the Automotive Ethernet standard, then establishing communication between the master 100 and the vehicle tester 126 may include a sequence including, for example, IP discovery, negotiation and socket opening. If the master 100 uses a communication protocol such as the CAN (Controller Area Network) protocol, then specific steps may not be required to establish communication. In general, connection establishment may be a one-time process, and need not be repeated unless, for example, communications are halted by one of the devices due to, for example, a reset. At 405, the vehicle tester 126 requests, from the master 100, a hardware part number. The hardware part number is indicative of the hardware and firmware of the master 100. At 406, after receiving, from the master 100, the requested hardware part number, the vehicle tester determines software identifiers for the master 100 and all connected ECUs. This can be done by way of a local or remote lookup table, for example, which maps the hardware part number to the software identifiers available via the master 100 (including that of the master 100 itself). At 407, the vehicle tester 126 requests, from the master 100, one or more software identifiers, each relating to one of the ECUs 112, 114, 116 or the master 100 itself. For conciseness, the remaining description of the flowchart 400 will be based on the vehicle tester 126 updating only the ECU 112. It will be understood that the software of any or all of the ECUs 112,114,116, or the master 100, can be updated using a similar procedure. Responsive to receiving the request for the software identifier for the ECU 112, the master 100 sends a message to the ECU 112, requesting that the ECU 112 supply its software identifier. In response to that message, the ECU 112 sends a message to the master 100, the message including a software identifier corresponding to the software the ECU 112 is currently running. The software identifier may comprise a data string identifying the hardware and software (including software version) of the ECU 112. If the ECU 112 complies with the 18014229 (Unified Diagnostics Services) standard, then the software identifier may comprise an ECU Core Assembly Number, which is discussed in more detail below in relation to the command sequence chart 500 of Figures 8 to 10. The ECU Core Assembly Number is a part number representative of both the hardware and current software of the ECU. Step 407 can optionally be repeated for one or more of the ECUs 114,116, and for the master 100 itself. At 408, the tester 126 determines whether ECU 112 requires a software update. This can be done by determining, from the software identifier retrieved at 406, the hardware type of the ECU 112 and the current version of the software that is stored on the ECU 112. The tester 126 uses the hardware type and software version to determine whether a later software version is available for the ECU 112. This can be done by looking up, for example in a lookup table, the latest software version for the hardware type indicated by the software identifier, and then comparing that software version with the current software version indicated by the software identifier. Alternatively, the software itself can be stored in such a way that the tester 126 can use information in a file name, header, or other data structure associated with the software to determine whether a later software version is available for the ECU 112. In either case, the lookup table, files, or other source of information about the latest version of the software associated with the hardware identified by the software identifier can be stored in a memory of the tester 126, or can be accessed remotely, for example by way of a local wireless communication network and / or an internet connection. If the current software version indicated by the software identifier is the same as the latest software version identified by the tester 126, then there is no need to update the software on the ECU 112. The flowchart therefore terminates at 436, which can optionally include outputting a message to a user of the tester 126, the message giving a reason for the flowchart terminating. In this case, the message may be something like “Current software version x.xxx is the same version. No update required”. If the current software version indicated by the software identifier is older than the latest software version identified by the tester 126, then the ECU software is updated. The ECU software is updated by transferring software data to the ECU, as described in more detail below. The software data can take the form of a binary file. Figures 5 and 7 show examples of such binary files 130 and 150. The binary file 130 includes software data including a header 132 and a block of software update information in the form of an executable file 134. The header 132 includes information that the master 100 uses to ensure the correct routing and processing of the executable file 134. By way of non-limiting example, the header 132 in Figure 5 includes: • a software identifier 136, which identifies the software update as described above. • a software type indicator 138, which identifies the type of software (executable, in this case). • a software part number identifier 140. • a data format identifier 142, which indicates whether the software update is compressed. • a network identifier 144, which identifies the vehicle communication network (e g., a CAN high speed main network) via which the target ECU can be reached. • an ECU address 158, which is the address at which the target ECU can be reached on the network identified by the network identifier 144. • erase information 146, which defines a starting address and a length (i.e., a number of addresses to erase after the starting address). The starting address is not, however, necessarily the same as the corresponding starting address within the memory of the ECU, as described in more detail below. • a checksum 148 for the binary file 130. Returning to Figure 6, at 410, a programming session is initiated by the vehicle tester 126. The requirements for initiating a programming session are known to those skilled in the art, and so will not be described in detail here. One example of initiating a programming session is described below in sequence 502 of the command sequence chart 500. At 412, the master 100 is unlocked. The master 100 also unlocks the ECU 112. One example of unlocking the master 100 and the ECU 112 is described below in the sequence 506 of the command sequence chart 500. If the attempt to unlock the master 100 and ECU 112 at 412 fails, the flowchart terminates at 436, which can again optionally include outputting a message to a user of the tester 126. In this case, the message may be something like “Attempt to unlock master failed”. If the attempt to unlock the master 100 is successful, then, at 414, a security certificate is supplied by the tester 126 and authenticated by the master 100. The requirements for supplying and authenticating a security certificate are known to those skilled in the art and so will not be described in detail here. One example of supplying and authenticating a security certificate is described below in the sequence 508 of the command sequence chart 500. By receiving and authenticating a security certificate, the master 100 is subsequently able to cryptographically verify the source and contents of a software update information received on behalf of the ECU 112, as described in more detail below. If the attempt to verify the security certificate at 414 fails, the flowchart terminates at 436, which can again optionally include outputting a message to a user of the tester 126. In this case, the message may be something like “Cannot verify security certificate”. Optionally, a security certificate is not used. Instead, authorisation is based on public-private key cryptography using a public key stored in the ECU 112, the public key corresponding with a private key used by the provider of the software. If the attempt to verify the security certificate at 414 succeeds, then, at 416, a portion of the memory 302 of the ECU 112 is erased in preparation for receiving software update information comprising a software update for the ECU 112. The range of memory addresses to be erased can be determined based on the erase information 146 in the header 132 (strictly speaking, the tester 126 may notyet have assembled the header 132 at this point. In that case, the range of memory addresses is still accessible to the tester 126, either by being stored locally or accessed remotely). This process includes the master 100 identifying the ECU for which a memory region is to be erased. This can involve determining, via a lookup table for example, an association between: a starting address indicated by the erase message received by the master 100 from the tester 126; and a particular ECU. The starting address indicated in the erase message is not necessarily the (real) starting address of the region to be erased within the ECU’s memory. Accordingly, the master 100 can also determine the (real) starting address for the software update within the memory of the identified ECU. This can involve determining, via a lookup table for example, an association between: a starting address indicated by the erase message received by the master 100 from the tester 126; and a real starting address for the identified ECU. Having identified the correct ECU and (real) starting address for the region to be erased within the memory of the ECU, an erase message is sent to the ECU. The erase message includes the (real) starting address and the length of the region to be erased. The requirements for erasing the required portion of the memory 302 are known to those skilled in the art and so will not be described in detail here. Additionally, one example of erasing the required portion of the memory 302 is described below in the sequence 510 of the command sequence chart 500. In general, the erase range will be equal to or larger than the size of the software update. If the attempt to erase the required portion of the memory 302 at 416 fails, the flowchart 400 terminates at 436, which can again optionally include outputting a message to a user of the tester 126. This case, the message may be something like “Cannot erase required memory”. If the attempt to erase the required portion of the memory 302 is successful, then, at 418, the master 100 receives software data comprising software update information associated with the ECU 112 and stores it in RAM memory of the master 100. The tester 126 also forwards to the master 100 a signed cryptographic hash of the software update information. The signed cryptographic hash can also be included in the binary 130, for example, or forwarded in any other suitable manner. The signed cryptographic hash is typically stored onboard the tester 126, and will typically be saved to the tester 126 at the same time as the corresponding software data. The signed cryptographic hash was generated by hashing the software update information using a hash function, such as SHA-2. The resultant hash was then signed using a private key controlled by the provider (such as the manufacturer of the vehicle 200) of the software update information. The public key corresponding to the private key is in the security certificate (if provided). Alternatively, or in addition, the public key can be permanently stored within the master 100, typically at the time of manufacture. One example of a binary file format and cryptographic protocols used to cryptographically sign the software update information is described below with reference to the command sequence chart 500. At 420, the master 100 verifies the software update information using a cryptographic protocol. The cryptographic protocol can be an asymmetric cryptographic protocol. The asymmetric cryptographic protocol includes a verification algorithm that accepts the public key and the software update information as inputs. The master 100 hashes the software update information using the same hashing algorithm (e.g., SHA-2) as was used to generate the hash that was received from the tester 126. By comparing the hash generated by the master 100 with the hash received from the tester 126, the master 100 can verify that the software update information has not been changed, whether due to file corruption or through interference by, for example, a bad actor. The master 100 then decrypts the signed hash received from the tester 126, using the public key stored in the master 100, to generate a decrypted hash. The decrypted hash is compared with the hash generated by the master 100. If they match, then the master 100 can verify that the software update information was supplied by the provider (e.g., the manufacturer of the vehicle 200). By performing cryptographic verification at the master 100, ECU software may be updated in a cryptographically verifiable manner, without individual ECUs needing to perform resource-intensive cryptographic verification. This may reduce the need for ECUs to be capable of performing such resource-intensive cryptographic verification. As such, simpler ECUs may be employed, which may be more cost-effective. Public-private key cryptography is one form of cryptographic protocol that is relatively resource-intense. If the attempt to cryptographically verify the software update information at 420 fails, the flowchart 400 terminates at 436, which can again optionally include outputting a message to a user of the tester 126. In this case, the message may be something like “Cannot verify software”. If the attempt to verify the software update information is successful, then, at 422, a software update, based on the software update information, is transferred to the ECU 112. This process includes identifying the ECU for which the software update is intended, for example by looking up an association between a starting address of the software update (within the software update data) and an ECU. In addition, the master 100 determines, for example via a lookup table, the (real) starting address for the software update within the memory of that ECU is determined. This is because the starting address indicated in the software update information is not necessarily the (real) starting address, for the software update, within the ECU’s memory. It will be appreciated that the length of the software update does not need to be changed. Having identified the correct ECU and (real) starting address for the software update within the memory of the ECU, the software update is sent to the ECU. One example of a process of transferring the software update to the ECU 112 is described below in the sequence 512 of the command sequence chart 500. Once the software update has been transferred to the ECU 112, the ECU 112 optionally performs, at 424, a software validation step. The validation step involves the ECU 112 checking for one or more labels within the software update it received. For example, the software update can include a particular label (e.g., a string of data) at a known location, which is checked by the ECU 112 to confirm that the software update is as expected. Typically, such labels are supplier specific. For example, a vehicle manufacturer may work with several suppliers of ECUs. Each supplier may use its own unique label. By checking that the appropriate label is present, it may be possible to avoid inadvertently installing software from the wrong supplier. Once the ECU 112 has validated the software update, the ECU 112 sends a message to the master 100 confirming that the software update is valid, and the master 100 sends a corresponding message to the tester 126. The validation step can alternatively be performed by the master 100 on behalf of the or each ECU that is being updated. In that case, the master 100 stores (or at least has access to) the required labels, so it can look them up when validating each software update. Assuming the further software validation step is successful (and no further software updates are to be provided), then, at 426, a system reset is performed. This typically involves the master 100 receiving a reset instruction from the tester 126. Responsive to receiving the reset instruction, the master 100 sends a reset instruction to all ECUs, including the ECU 112, causing the ECUs to reset themselves. The result of the ECU 112 resetting is that, during the subsequent reboot, the ECU 112 loads the updated software into operating memory. The master 100 also performs a reset. At 428, after the master 100 reset is complete, communication is re-established between the vehicle tester 126 and the master 100, in a similar manner as was described above at 404. At 430, the vehicle tester 126 reads, from the master 100, the software identifier for the ECU 112, in a similar manner as was described above at 406. At 432, the vehicle tester receives the software identifier from the master 100 and confirms that the software version it refers to corresponds with the latest software version for that hardware type. If successful, this confirms that the software of the ECU 112 was successfully updated. The software update process can be repeated for any of the other ECUs 114, 116 that need updating. It is not necessary to establish communications again, so the process can be repeated from 404. The order in which the steps of the flowchart 400 are performed may be varied depending upon the implementation. For example, in the flowchart 400, the programming session is initiated at 410 after the software identifier has been read at 406. In other implementations, the programming session can be initiated prior to reading the software identifiers. Other changes in the order of the steps of the flowchart 400 will suggest themselves to the skilled person. Optionally, the master 100 may be configured to encrypt the software update prior to transferring it to the ECU. Such encryption may be performed if the ECU is capable of (or demands) that the software update be provided in an encrypted form. Such encryption may use different keys and / or a different cryptographic protocol as compared with any other cryptographic protocol used in relation to the software update information provided by the tester 126 to the master 100. For example, the master 100 may be configured to encrypt the software update using a symmetric encryption protocol. In that case, the master 100 and the ECU 112 share a key that is used for both encryption and decryption. Such protocols may be less resource-intensive than public-private key encryption protocols, which may reduce the required hardware specifications of the ECU 112 and the processing load on the master 100. The flowchart 400 describes a process in which the tester 126 requests software identifiers for each ECU 112,114,116 via the master 100. In response, the master 100 requests software identifiers from each ECU 112,114,116 and sends the software identifiers to the tester 126 upon receipt. In alternative embodiments, the master 100 retains in its memory 120 a record of the software identifiers for at least some of the ECUs. The record can be updated by the master 100 each time a software update is successfully installed on an ECU 112,114,116. In such embodiments, when the tester 126 sends a request to the master 100 for one or more software identifiers of one or more ECUs, the master 100 can reply with the requested software identifier(s) for which it has a record, without having to contact the ECU(s). While this embodiment requires additional memory within the master 100, it may speed up the process of updating ECU software, especially where many ECUs are to be updated within a session. In other implementations, two or more software updates can be sent in the same binary. For example, the tester 126 can request the software identifier for the master and each of the ECUs, for example as described above with reference to step 406 of the flowchart 400. The tester 126 has in its memory an electronic bill of materials, which includes identifiers for the master 100 and all ECUs, allowing the tester to know the entities for which it needs to request information such as the software identifier. If multiple ECUs need updating, then the tester erases the appropriate memory range in each ECU. For each ECU for which memory is to be erased, the tester 126 sends an erase message to the master 100, the erase message including an address range comprising a starting address and a length. As described above, the starting address is not necessarily the actual starting address within the memory of the target ECU. Rather, the starting address can be indicative of the target ECU. The master 100 receives the erase message and determines, from the starting address, the ECU to which the erase message is directed. The master 100 also stores a relationship between the received starting address and the (real) starting address within the ECU’s memory. For example, the received starting address may be 100000. The master 100 looks this address up in a lookup table and determines that starting address 100000 corresponds with a particular ECU within the system. The same (or another) table can also indicate that the destination address (i.e., the actual starting address) in the memory of that ECU is 28000. The master 100 then knows that it needs to erase memory with the identified ECU starting at address 28000, not 100000 as was indicated by the starting address in the erase message it received from the tester 126. The ECU assembles a binary 150, as shown in Figure 7. The binary 150 shares many of the features of the binary 130 of Figure 5, and like features are indicated with like reference signs. In contrast to the binary 130, the binary 150 includes software update information for multiple ECUs for which a software update is required. In this example, there are four ECUs requiring updates, and so the software update information includes four executable files 134,152,154, and 156 for the four respective ECUs. In other implementations, an executable file could also be provided for updating the software of the master 100. The header 132 of the binary 150 is different to the header 132 of the binary 130, due to the need to take into account the multiple executable files 134,152,154,156 in the binary 150. For example, instead of the one software identifier 136 in binary 130, the header 132 of the binary 150 includes four software identifiers 136, one for each of the four ECUs for which the respective executable files 134, 152, 154, 156 are intended. The binary 150 similarly includes four software type indicators 138, four software part number identifiers 140, four data format identifiers 142, four network identifiers 144, four ECU addresses 158, and four instances of erase information 146, corresponding to the respective target ECUs. The erase information 146 for each ECU includes a starting address and a length. As described above, the starting address indicated by the erase information is not necessarily the same address as the starting address within the corresponding ECU. Rather, the starting address indicated by the erase information is indicative of the ECU itself. At the master 100, the binary 150 is parsed using the starting address-to-ECU mapping described above (and stored at the master 100), allowing the master 100 to identify, from each starting address, the ECU to which each software update relates, in a similar manner as was performed in response to the erase message. The master 100 again determines the (real) starting address for the software update for each ECU, and sends each software update to the relevant ECU along with the correct starting address. The length of the software update does not need to be changed. The update process continues as described above in relation to flowchart 400, for each ECU to be updated, until the process is complete. The master 100 has a memory region for its own software updates, corresponding with an address range having a starting address. A starting address in the header 132 of the binary 150 that corresponds with the starting address of the master 100 indicates that the corresponding software update information is for the master 100. In this example, there is no software update for the master 100. Although the starting address is used to identify an ECU in this embodiment, it will be appreciated that an address offset or an address range can be used in other embodiments. Similarly, although the starting address has been described as translating to a destination address, it will be appreciated that a starting address, an address offset, or an address range can be translated to a destination address or a destination address range in other embodiments. In certain circumstances, software can be stored in two or more non-continuous ranges within the memory, although this is not generally the case for ECUs given the relatively small memories and software involved. Turning to Figures 8 to 10, there is shown a command sequence chart 500 for an alternative implementation of the invention. Due to its length, the command sequence chart 500 is split into sub-parts 500-1, 500-2, and 500-3 across Figures 8, 9, and 10 respectively. The command sequence chart 500 shows communications between the tester 126, the master 100, the ECU 112 and the ECU 114. It will be appreciated that similar principles can be applied to one or more additional ECUs, or to a single ECU. The tester 126, the master 100, the ECU 112, and the ECU 114 may correspond with the tester 126, the master 100, the ECU 112, and the ECU 114 described above, in terms of hardware and the communication protocols they use to communicate with each other, but may also take different forms known to those skilled in the art. All messaging shown in Figures 8 to 10 is in accordance with the 18014229 (Unified Diagnostics Services) standard. The use of messaging that follows this standard allows existing standard-compliant components, such as ECUs, to be employed, which avoids the need for novel ECU hardware or the development of non-standard messaging protocols. It will be appreciated that, in other embodiments, other standards or protocols may be employed for the messaging between any of the entities. For example, in an alternative embodiment, the ECU 114 is not compliant with the 18014229 (Unified Diagnostics Services) standard. Instead, it uses a different communication protocol. In that case, the master 100 would be capable of communicating in accordance with the communication protocol used by the ECU 114. However, communications between the master 100 and the tester 126, and between the master 100 and the ECU 112, could still be in accordance with the 18014229 (Unified Diagnostics Services) standard (or other standard(s), in further implementations). The command sequence chart 500 commences after communications have been established between the tester 126 and the master 100. The communications may be established as described at 404 in the flowchart 400 of Figure 6. A programming session is initiated in 500 by way of a sequence 502 of messages. Initiation of the programming session is similar to step 412 in Figure 6. However, in contrast to the embodiment of Figure 6, the programming session at 500 is initiated in sequence 502 prior to reading of the software identifier. The sequence 502 includes the following messages: • The tester 126 sends to the master 100 a message 10 02 (10 = programming session control, 02 = programming session). • The master 100 replies to the tester 126 with a message 7F 10 78 (7F = negative response 10 = programming session control, 78 = pending). • The master 100 sends to the ECU 112 a message 10 02 (10 = programming session control, 02 = programming session). • The ECU 112 sends to the master 100 a message 50 02 (50 = session control response, 02 = programming session). • The master 100 sends to the ECU 114 a message 10 02 (10 = programming session control, 02 = programming session). • The ECU 114 sends to the master 100 a message 50 02 (50 = session control response, 02 = programming session). • The master 100 sends to the tester 126 a message 50 02 (50 = session control response, 02 = programming session). At this point, the tester 126 understands that the programming session has successfully been established. It is not aware of specific communications between the master 100 and the ECUs 112 and 114. Next, the tester 126 requests from the master 100 a hardware part number. The hardware part number represents a hardware / software schema for the entire system, including part number identifiers of the master 100 and the ECUS 112, 114. The tester 126 requests the hardware part number in accordance with the 18014229 (Unified Diagnostics Services) standard, by way of sequences 503 of messages. The sequence 503 includes the following messages: • The tester 126 sends to the master 100 a message 22 F1 11 (22 = read diagnostics, F1 11 = hardware part number. • The master 100 sends to the tester 126 a message 62 F1 11 aa bb cc (62 = reporting data, F1 11 = hardware part number, aa bb cc = value of hardware part number. The tester 100 uses the value of the hardware part number aa bb cc to look up, either locally or remotely, information including part number identifiers for the master 100 and the ECUS 112,114. Next, the tester 126 requests part numbers of the master 100 and the ECUs 112,114 in accordance with the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 504 of messages. Where the master 100, the ECU 112, and / or the ECU 114 comply with the 18014229 (Unified Diagnostics Services) standard, then the part number may comprise an ECU Core Assembly Number. The sequence 504 includes the following messages: • The tester 126 sends to the master 100 a message 22 F1 PP (22 = read diagnostics, F1 PP = part number of the master 100). • Based on the part number PP, the master 100 identifies that the request is intended for itself, and sends to the tester 126 a message 62 F1 PP dd eeff (62 = reporting data, F1 PP = part number of the master 100, dd eeff = value of part number of the master 100). • The tester 126 sends to the master 100 a message 22 F1 QQ (22 = read diagnostics, F1 PP = part number of the ECU 112). • Based on the part number QQ, the master 100 identifies that the request is intended for the ECU 112, and sends to the ECU 112 a message 22 F1 QQ (62 = reporting data, F1 QQ = part number of the ECU 112). • The ECU 112 sends to the master 100 a message 62 F1 QQ gg hh ii (62 = read diagnostics, F1 QQ = part number of the ECU 112, gg hh ii = value of part number of the ECU 112). • The master 100 sends to the tester 126 a message 62 F1 QQ gg hh ii (62 = read diagnostics, F1 QQ = part number of the ECU 112, gg hh ii = value of part number of the ECU 112). • The tester 126 sends to the master 100 a message 22 F1 RR (22 = read diagnostics, F1 RR = part number of the ECU 114). • Based on the part number RR, the master 100 identifies that the request is intended for the ECU 114, and sends to the ECU 114 a message 22 F1 RR (62 = reporting data, F1 RR = part number of the ECU 114). • The ECU 114 sends to the master 100 a message 62 F1 RR jj kk mm (62 = read diagnostics, F1 RR = part number of the ECU 114, jj kk mm = value of part number of the ECU 114). • The master 100 sends to the tester 126 a message 62 F1 RR jj kk mm (62 = read diagnostics, F1 RR = part number of the ECU 114, jj kk mm = value of part number of the ECU 114). At this point, the tester 126 knows the part number (i.e., the ECU Core Assembly Number) for the master 100 and each of the ECUs 112, 114. It uses the received part numbers to determine the hardware and current software versions of the master 100 and the ECUs 112,114. From that information, the tester 126 can determine which, if any, of the master 100 and the ECUs 112, 114 can be updated with a later software version. In the present example, only the ECU 112 has a later software version available. Next, the tester 126 gains secure access to the master 100 in accordance with the “security access” procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 506 of messages. The security access procedure unlocks the master 100 and the ECUs 112,114, allowing access to their respective memories. The sequence 506 includes the following messages: • The tester 126 sends to the master 100 a message 27 01 (27 = security access function, 01 = seed generation function ID). • The master 100 sends to the ECU 112 a message 27 01 (27 = security access function, 01 = seed generation function ID). • The ECU 112 sends to the master 100 a message 67 01 XX2 XX2 XX2 (67 = positive response, 01 = security access function, XX2 XX2 XX2 = ECU 112 seed). • The master 100 sends to the ECU 114 a message 27 01 (27 = security access function, 01 = seed generation function ID). • The ECU 114 sends to the master 100 a message 67 01 XX3 XX3 XX3 (67 = positive response, 01 = security access function, XX3 XX3 XX3 = ECU 114 seed). At this point, the master 100 has the seeds it requested from the ECUs 112, 114. It can now safely continue with its own seed generation process: • The master 100 sends to the tester 126 a message 67 01 XX1 XX1 XX1 (67 = positive response, 01 = security access function, XX1 XX1 XX1 = master 100 seed). Next, the tester 126 initiates the second part of the security access process: • The tester 126 sends to the master 100 a message 27 02 YY1 YY1 YY1 (27 = security access function, 02 = key verification, YY1 YY1 YY1 = key based on master seed XX1 XX1 XX1). • The master 100 sends to the ECU 112 a message 27 02 YY2 YY2 YY2 (27 = security access function, 02 = key verification, YY2 YY2 YY2 = key based on ECU 112 seed XX2 XX2 XX2). • The ECU 112 sends to the master 100 a message 67 02 (67 = positive response, 02 = key verification function). • The master 100 sends to the ECU 114 a message 27 02 YY3 YY3 YY3 (27 = security access function, 02 = key verification, YY3 YY3 YY3 = key based on ECU 114 seed XX3 XX3 XX3). • The ECU 114 sends to the master 100 a message 67 02 (67 = positive response, 02 = key verification function). At this point, the master 100 has confirmation of verification of the keys generated based on the seeds it requested from the ECUs 112,114. The master 100 can now safely continue with its own key verification messaging: • The master 100 sends to the tester 126 a message 67 02 (67 = positive response, 02 = key verification function). At this point, the tester 126 knows that the master 100 and the ECUs 112,114 have successfully been unlocked. Next, there is an optional step in which the tester 126 sends a security certificate to the master 100 for verification in accordance with the security certificate verification procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 508 of messages. The sequence 508 includes the following messages: • The tester 126 sends to the master 100 a message 31 01 02 23 M N (31 = general service identifier, 01 = start, 02 03 = submit certificate, M = certificate type, N = certificate). • The master 100 sends to the tester 126 a message 71 01 02 23 4A 02 (71 = positive response, 01 = start, 02 03 = submit certificate, 4A = routine info byte, 02 = accepted). At this point, the master 100 has an authenticated copy of the security certificate. That security certificate includes a public key that the master 100 can use to cryptographically verify data that is signed with the corresponding private key. Next, the required space in the memory of ECU 112 is erased in accordance with the erase procedure of the 18014229 (Unified Diagnostics Services) standard, byway of a sequence 510 of messages. The sequence 510 includes the following messages: • The tester 126 sends to the master 100 a message 31 01 FF 00 AA AA AA AA BB BB BB BB (31 = general service identifier, 01 = start, FF 00 = flash erase, AA AA AA AA = starting address, BB BB BB BB = length of address range). The master 100 refers to a lookup table that stores mappings between starting addresses and ECUs, as described in more detail above in relation to the flowchart 400 in Figure 5. Based on the starting address AA AA AA AA, the master 100 determines from the lookup table that the software update is for the ECU 112. The master 100 also looks up, in the same ora different lookup table, an offset to apply to the received starting address, in order to translate it to the destination address (i.e., the actual address) of the ECU 112 to which the software is to be written. The offset is subtracted from the received starting address AA AA AA AA to give actual starting address CC CC CC CC. In other embodiments, instead of subtracting an offset from the received starting address, a lookup table can store a direct mapping between received starting addresses and destination addresses. • The master 100 sends to the ECU 112 a message 31 01 FF 00 CC CC CC CC BB BB BB BB (31 = general service identifier, 01 = start, FF 00 = flash erase, CC CC CC CC = starting address within ECU 112 memory, BB BB BB BB = length of address range). The ECU 112 erases its memory in accordance with the values CC CC CC CC and BB BB BB BB. • The ECU 112 sends to the master 100 a message 71 01 FF 00 4A (71 = positive response, 01 = start, FF 00 = flash erase, 4A = routine info byte. • The master 100 sends to the tester 126 a message 71 01 FF 00 4A (71 = positive response, 01 = start, FF 00 = flash erase, 4A = routine info byte). At this point, the tester 126 knows that the ECU 112 has erased the memory required for the software update. Next, the new software is sent to the ECU 112 via the master 100 in accordance with a software update procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 512 of messages. The sequence 512 includes the following messages: • The tester 126 sends to the master 100 a message 34 00 44 AA AA AA AA BB BB BB BB (34 = transfer data, 00 44 = indicates 4 bytes for the address and 4 bytes for the length of the software update, AA AA AA AA = starting address, BB BB BB BB = length of the software update). The master 100 again refers to a lookup table that stores mappings between starting addresses and ECUs, as described in more detail above. Based on the starting address AA AA AA AA, the master 100 determines from the lookup table that the software update is for the ECU 112. The master 100 also looks up, in the same or a different lookup table, an offset to apply to the received starting address, in order to translate it to the destination address (i.e., the actual address) of the ECU 112 to which the software is to be written. The offset is subtracted from the received starting address AA AA AA AA to give destination starting address CC CC CC CC. In other embodiments, instead of subtracting an offset from the received starting address, a lookup table can store a direct mapping between received starting addresses and destination addresses. • The master 100 sends to the ECU 112 a message 34 00 44 CC CC CC CC BB BB BB BB (34 = transfer data, 00 44 = indicates 4 bytes fortheaddress and 4 bytes for the length of the software update, CC CC CC CC = starting address within ECU 112 memory, BB BB BB BB = length of the software update). • The ECU 112 sends to the master 100 a message 74 20 DD DD (74 = positive response, 20 = length format ID, DD DD = maximum size of each data block (based on buffer size of the ECU 112)). • Themaster 100 sends to the tester 126 a message 74 20 DD DD (74 = positive response, 20 = length format ID, DD DD = maximum size of each data block (based on buffer size of the ECU 112)). At this point, the tester 126 knows that the master 100 is ready to receive the software update, and knows the maximum size for each data block. Next, the software update is progressively transferred from the tester 126 to the ECU 112 via the master 100 in accordance with a data transfer procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a looped sequence 514 of messages. Within each loop, the tester 126 sends a portion of the software update not exceeding the maximum size DD DD described above. The sequence 514 includes the following messages: • The tester 126 sends to the master 100 a message 36 NN XX XX (36 = data transfer, NN = block index, XX XX = data) • The master 100 sends to the ECU 112 a message 36 NN XX XX (36 = data transfer, NN = block index, XX XX = data). The ECU 112 writes the data to its memory, sequentially from the starting address previously provided. • The ECU 112 sends to the master 100 a message 76 NN (76 = positive response, NN = block index) • The master 100 sends to the tester 126 a message 76 NN (76 = positive response, NN = block index) The looped sequence 514 of messages repeats. The data supplied in each loop continues from the end of the data provided in the previous loop, and the ECU 112 similarly advances the starting address from which the data in each loop is written. The process continues until all of the software update has been received by the ECU 112 and written into its memory. After receiving the last 76 NN message from the master 100, the tester 126 knows that the software update has successfully been stored in the memory of ECU 112. Next, the tester 126 ends the data transfer process in accordance with a transfer exit procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 516 of messages. The sequence 516 includes the following messages (noting that the master 100 implicitly knows that the message 37 is for the ECU 112, based on it being received after the previous sequence was directed to the ECU 112): • The tester 126 sends to the master 100 a message 37 (37 = transfer exit service identifier). • The master 126 sends to the ECU 112 a message 37 (37 = transfer exit service identifier). The ECU 112 calculates a two-byte checksum GG for the received data. • The ECU 112 sends to the master 100 a message 77 GG (77 = positive response, GG = two-byte checksum). The master 100 calculates a full hash HH HH of the software update. This can be done in any suitable way, and at any suitable time. For example, the hash can be calculated by the master 100 when the software update was first received: • The master 100 sends to the tester 126 a message 77 HH HH (77 = positive response, HH HH = hash of software update). Next, the tester 126 verifies the signed hash in accordance with a signature verification procedure of the 18014229 (Unified Diagnostics Services) standard, byway of a sequence 518 of messages. The sequence 518 includes the following messages: • The tester 126 sends to the master 100 a message 31 01 02 21 (31 = general service identifier, 01 = start, 02 21 = send signed signature). The master 100 verifies the signed hash using the public key corresponding to the private key used to sign the hash. Where a security certificate has been received and authenticated, the public key is known from the security certificate. If no security certificate was used, a public key stored on the master 100 is used. • The master 100 sends to the tester 126 a message 71 01 02 21 (71 01 = positive response, 02 21 send signed signature). At this point the master 100 has verified the signed hash, and therefore knows that the software update is from an authorised provider. Next, the validity of the software is checked in accordance with a software validating procedure of the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 520 of messages. The sequence 520 includes the following messages: • The tester 126 sends to the master 100 a message 31 01 03 04 (31 01 = general service identifier, 03 04 check valid app). • The master 100 sends to the ECU 112 a message 31 01 03 04 (31 01 = general service identifier, 03 04 = check valid app). The ECU 112 validates the software update by checking for a label such as a string or other data pattern, for example as described above in software validation step 424 of the flowchart 400. • The ECU 112 sends to the master 100 a message 71 01 03 04 02 (71 01 = positive response, 03 04 = check valid app, 02 = valid application). In this embodiment, the software validation check is a system level check, so the master 100 repeats the software validation for the ECU 114, even though the software for the ECU 114 was not updated: • The master 100 sends to the ECU 114 a message 31 01 03 04 (31 01 = general service identifier, 03 04 = check valid app). The ECU 114 validates its software by checking for a label such as a string or other data pattern, for example as described above in software validation step 424 of the flowchart 400 (the software of the ECU 114 has not changed, and so the check will be positive): • The ECU 114 sends to the master 100 a message 71 01 03 04 02 (71 01 = positive response, 03 04 = check valid app, 02 = valid application). At this point, the master 100 is aware that the software update stored in the ECU 112 has been validated. • The master 100 sends to the tester 126 a message 71 01 03 04 02 (71 01 = valid response, 03 04 = check valid app, 02 = valid application). At this point, the tester 126 is aware that the software update stored in the ECU 112 has been validated. Next, the system, including the master 100, the ECU 112, and the ECU 114, is reset in accordance the 18014229 (Unified Diagnostics Services) standard, by way of a sequence 522 of messages. The sequence 522 includes the following messages: • The tester 126 sends to the master 100 a message 11 01 (11 = reset, 01 = hard reset). • The master 100 sends to the ECU 112a message 11 01 (11 = reset, 01 = hard reset). • The ECU 112 sends to the master 100 a message 51 01 (51 = positive response, 01 = hard reset) The ECU 112 resets itself, during which the updated software is loaded into the working memory of the ECU 112. The ECU 112 then operates based on the updated software. • The master 100 sends to the ECU 114 a message 11 01 (11 = reset, 01 = hard reset). • The ECU 114 sends to the master 100 a message 51 01 (51 = positive response, 01 = hard reset). The ECU 114 resets itself, during which its software is loaded into the working memory of the ECU 114. Since its software was not updated in this example, the ECU 114 software remains the same as before the reset. After initiating resets of all ECUs, the master 100 resets itself, during which its software is loaded into the working memory of the master 100. Since its software was not updated in this example, the master 100 software remains the same as before the reset. • Once reset, the master 100 sends to the tester 126 a message 51 01 (51 = positive response, 01 = hard reset). At this point, the tester 126 knows that the system reset is complete. Next, the tester 126 can check that the ECU 112 has successfully updated its software by requesting software identifiers from the ECU 112 in accordance with the 18014229 (Unified Diagnostics Services) standard. The sequence 504 of messages, as described above, can be used to implement this check. The command sequence chart 500 then ends. The master 100 in the embodiment of Figures 8 to 10 does not encrypt the software update (for example, using a symmetrical encryption algorithm) prior to transferring it to the ECU 112, as was described in relation to the embodiment of Figure 5. The skilled person will understand the additional steps and message sequences required to implement such encryption. In the examples above, only ECU 112 required updating, and so only one software update was provided in the software update information sent by the tester 126 to the master 100. In other cases, more than one ECU, and / or the master, may require updating. In that case, it may be more efficient to send software updates for more than one ECU and / or the master as part of one data transfer (e g., the data transferred in the looped sequence 514). Figure 11 illustrates a method 600 according to an embodiment of the invention. The method 600 is a method for use in updating software in one or more of a plurality of ECUs, such as ECUs 112,114,116 of a vehicle, such as the vehicle 200 illustrated in Figure 1. The method 600 may be performed by the control system 100 illustrated in Figure 2. In particular, the memory 120 may comprise computer-readable instructions that, when executed by the processor 118, perform the method 600 according to an embodiment of the invention. The method 600 comprises receiving 602 software data comprising software update information associated with one or more of the ECUs, 5 verifying 604 the software update information using a cryptographic protocol; and, responsive to successful verification of the software update information according to the cryptographic protocol, outputting 606 a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU. An additional advantage that arises out of the master 100 controlling communication between the tester and the ECUs is increased 10 configurability. Ordinarily, the design of a vehicle’s system architecture remains fixed while the vehicle is in production. The present invention may allow changes to vehicle ECUs (e.g., changes in type, number, configuration, etc.) without requiring extensive additional changes to other hardware or software. The tester need not know anything about the details of the ECUs, since they are effectively invisible to the tester as a result of the master’s functionality. For example, a lookup table or other information used to map address ranges to ECUs may be updated to account for any ECU changes, without the need to update the software run by the master 100. 15 It will be appreciated that various changes and modifications can be made to the present invention without departing from the scope of the present application.

Claims

1. A control system for use in updating software in a plurality of electronic control units, ECUs, of a vehicle, the control system comprising one or more processors collectively configured to:receive software data comprising software update information associated with one or more of the ECUs;verify the software update information using a cryptographic protocol; andresponsive to successful verification of the software update information according to the cryptographic protocol, output a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU.

2. The control system of claim 1, wherein the cryptographic protocol is an asymmetric encryption protocol.

3. The control system of claim 2, wherein the one or more processors are collectively configured to, prior to verifying the softwaredata:receive a security certificate associated with an entity;authenticate the certificate.

4. The control system of any preceding claim, wherein at least some of the software updates sent to the ECUs are encrypted using a further cryptographic protocol.

5. The control system of claim 4, wherein the further cryptographic protocol is a symmetric encryption protocol.

6. The control system of any preceding claim, wherein the one or more processors are configured to:identify, at least partly based on at least one address offset within the software update information, at least one ECU with which the software update information is associated; andsend each software update to the corresponding identified ECU, each software update being based on an address range of the software update information, the address range being associated with the address offset based upon which the corresponding identified ECU was identified.

7. The control system of claim 6, wherein the one or more processors are configured to:extract the corresponding address range from the software update information;convert the extracted corresponding address range into a further address range for the corresponding identified ECU; andsend each software update to the further address range for the corresponding identified ECU.

8. The control system of claim 7, wherein the one or more processors are collectively configured to:convert the corresponding address range within the software update information into the further address range for the corresponding identified ECU by subtracting the corresponding address offset from each address within the corresponding address range.

9. The control system of any one of claims 6 to 8, wherein the one or more processors are collectively configured to:identify the ECU by using a lookup table, the lookup table containing a mapping between address offsets and ECUs.

10. The control system of claim 9, wherein the lookup table defines an address range for each ECU, each address range being associated with an address offset.

11. A vehicle system comprising the control system of any preceding claim and a plurality of the ECUs.12.The vehicle system of claim 11, wherein at least one of the ECUs is configured to verify the software update it receives.

13. The vehicle system of claim 12, wherein at least one of the ECUs is configured to verify the received software update using a 5 symmetric encryption protocol.

14. A vehicle comprising the vehicle system of any one of claims 11 to 13.

15. A method for use in updating software in a plurality of electronic control units, ECUs, of a vehicle, the method comprising:10 receiving software data comprising software update information associated with one or more of the ECUs;verifying the software update information using a cryptographic protocol; andresponsive to successful verification of the software update information according to the cryptographic protocol, outputting a software update for each of the one or more ECUs, each software update being based on the software update information for the associated ECU.Application No: GB2414876.9 Examiner: Mr Stephen MartinClaims searched: 1-15 Date of search: 25 March 2025Patents Act 1977: Search Report under Section 17Documents considered to be relevant:Category Relevant to claims Identity of document and passage or figure of particular relevance X 1-15 US 2017 / 0060559 Al (YE et al.) See in particular paragraphs 0003, 0004, 0016, 0032, 0043 X 1-15 US 2018 / 0048473 Al (MILLER et al.) See in particular paragraphs 0003, 0004, 0020, 0039 X 1-15 US 2018 / 0145991 Al (MCCAULEY et al.) See in particular paragraphs 0004, 0017, 0018, 0025, 0048 X 1 at least US 2018 / 0336024 Al (KLISCHE) See in particular paragraphs 0021, 0034, 0051, 0078, 0086 X 1 at least US 2022 / 0179636 Al (BARRY et al.) See in particular paragraphs 0007, 0009, 0010, 0055, 0056 X 1-15 US 2009 / 0126028 Al (TRAENKENSCHUH et al.) See in particular paragraphs 0018, 0023, 0024Categories:X Document indicating lack of novelty or inventive step A Document indicating technological background and / or state of the art. Y Document indicating lack of inventive step if combined with one or more other documents of same category. P Document published on or after the declared priority date but before the filing date of this invention. & Member of the same patent family E Patent document published on or after, but with priority date earlier than, the filing date of this application.Field of Search:Search of GB, EP, WO &US patent documents classified in the following areas of the UKCX :International Classification:Subclass Subgroup Valid From G06F 0021 / 57 01 / 01 / 201321

Images