Vehicle control system

Abstract

A control system 18 for a vehicle 10 the control system comprising a master controller 26 and at least one slave controller 28 that is operable by the master controller. The control system is configur

Description

14^04 25 TECHNICAL FIELD 5 The present disclosure relates to a vehicle control system. Aspects of the invention relate to a control system, to a vehicle, to a method, to computer software and to a non-transitory, computer-readable storage medium. BACKGROUND 10 Automotive vehicles regularly gain new features that are implemented by a control system of the vehicle, for example to meet demands for increasing vehicle autonomy and connectivity. As new features are added, the number of electronic control units (ECUs) within the vehicle control system typically grows. In this respect, the existing ECUs in a control system may not be capable of hosting 15 additional features and so a new ECU supporting the new feature may be required, with corresponding interfaces to the existing architecture. As a result, it is now common to have in excess of 100 ECUs in a vehicle control system, each ECU acting as a separate controller. There is a growing desire to reduce the number of individual ECUs required in vehicle control systems. One option is to bundle a group of ECUs responsible for related features into a combined ECU that is based on a master-slave controller architecture, in which each of the original ECUs are implemented as respective controllers within the new combined ECU, one of the controllers being a master controller that operates the remaining controllers as slaves. Taking this approach may enable the number of separate ECUs to be reduced to 40 or fewer, for example, in turn reducing the 25 complexity of the control system. Vehicle control systems require cybersecurity, for example to protect against after-sales tampering such as altering engine control software to modify performance. In this respect, it is typical for a vehicle control system to verify that each of its controllers includes the correct software components 30 on a regular basis. Such verification may be implemented using security mechanisms such as a ‘secure boot’ procedure, in which each software component of a controller is verified on system boot before any of those components are executed by the controller. Verification may be achieved using encrypted digital keys to confirm the identity of the components, for example. 35 In existing vehicle control architectures, in which each controller is implemented on a separate ECU, each ECU has sufficient processing resources to complete a secure boot within prescribed timeframes. Such timeframes might be dictated by a system basis chip (SBC) or by network startup timings within the control system, for example. However, bundling multiple ECUs and their associated features into a combined ECU with a master-5 slave configuration presents a challenge for maintaining security. In this respect, it is typical to configure slave controllers with reduced processing power relative to the associated master controller, such that a combined ECU does not have the equivalent resources of the corresponding separate ECUs. While the ability to provide the same functionality with reduced resources is an advantage of the master-slave controller architecture, one drawback is that security mechanisms for 10 verifying software components may take longer to complete and therefore be incompatible with the applicable time window. It is an aim of the present invention to address one or more of the disadvantages associated with the prior art. 15 SUMMARY OF THE INVENTION Aspects and embodiments of the invention provide a control system, a vehicle, a method, computer software and a non-transitory, computer-readable storage medium as claimed in the appended claims. According to an aspect of the present invention there is provided a control system for a vehicle. The control system comprises a master controller and at least one slave controller that is operable by the master controller. The control system is configured to: perform a first boot routine when booting the 25 master controller, the first boot routine being configured to verify all software components to be executed by the master controller before booting the master controller; and perform a second boot routine when booting the at least one slave controller, the second boot routine being configured to verify at least some software components to be executed by the at least one slave controller after booting the at least one slave controller. 30 By performing a second boot routine on the slave controller that verifies at least some software components after booting the controller, the slave controller can be booted more quickly than if all components were verified before booting as for the master controller. Conversely, the second boot routine nonetheless verifies all components to be executed, thereby reducing the risk of executing 35 corrupted or modified software. The first and second boot routines therefore together form a hybrid boot routine that balances security with booting performance in a system having a master-slave architecture. The master controller and the at least one slave controller may collectively comprise: at least one electronic processor having an electrical input for receiving a boot command; and at least one memory device electrically coupled to the at least one electronic processor and having instructions 5 stored therein. The at least one electronic processor may be configured to access the at least one memory device and execute the instructions thereon so as to perform the first and second boot routines. The control system may comprise a control unit that comprises the master controller and the at least 10 one slave controller. For example, the control unit may be defined by a vehicle ECU. The first boot routine may comprise a secure boot, thereby maximising security in the master controller. 15 The second boot routine is configured to verify all software components to be executed by the at LO least one slave controller after booting the at least one slave controller. In such embodiments, the CM second boot routine comprises an authenticated boot. Such embodiments minimise the boot time for the at least one slave controller. As a non-claimed alternative, the second boot routine may be configured to verify a boot manager of the at least one slave controller before booting the at least one slave controller. The second boot routine optionally comprises a trusted boot. Such embodiments reduce the risk of executing corrupted or modified software components by verifying at least one component prior to execution. 25 The control system may be configured to complete the first boot routine before commencing the second boot routine. 30 The control system may comprise multiple slave controllers that are operable by the master controller, in which case the control system may be configured to perform the second boot routine when booting each slave controller. Alternatively, the control system may be configured to perform the second boot routine when booting a first slave controller, and to perform a third boot routine when booting a second slave controller, the third boot routine being different to the second 35 boot routine. Boot routines performed on slave controllers may be run in series or in parallel. The third boot routine may be configured to verify at least some software components to be executed by the second slave controller after booting the second slave controller. For example, the third boot routine may be configured to verify all software components to be executed by the second slave controller after booting the second slave controller. Alternatively, the third boot routine may be 5 configured to verify a boot manager of the second slave controller before booting the second slave controller. The third boot routine may comprise a trusted boot or an authenticated boot. For example, the second boot routine may comprise a trusted boot and the third boot routine may comprise an authenticated boot, or alternatively the second boot routine may comprise an authenticated boot and the third boot routine may comprise a trusted boot. 10 Alternatively, it is also possible for the third boot routine to be configured to verify all software components to be executed by the second slave controller before booting the second slave controller. For example, the third boot routine may comprise a secure boot. 15 If further slave controllers are present in the control system, any mixture of boot routines may be performed on the individual slave controllers. LD CM The control system may comprise multiple master controllers and at least one respective slave controller for each master controller. According to another aspect of the invention, there is provided a vehicle comprising the control T"“ system of the above aspect. Another aspect of the invention provides a method for operating a vehicle control system. The 25 system comprises a master controller and at least one slave controller that is operable by the master controller. The method comprises: verifying all software components to be executed by the master controller before booting the master controller; and verifying at least some software components to be executed by the at least one slave controller after booting the at least one slave controller. 30 The method may comprise performing a first boot routine when booting the master controller, the first boot routine being configured to verify all software components to be executed by the master controller before booting the master controller; and performing a second boot routine when booting the at least one slave controller, the second boot routine being configured to verify at least some software components to be executed by the at least one slave controller after booting the at least 35 one slave controller. The invention also extends to computer software that, when executed, is arranged to perform a method according to the above aspect, and to a non-transitory, computer-readable storage medium storing instructions thereon that, when executed by one or more electronic processors, causes the one or more electronic processors to carry out the method of the above aspect. 5 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 10 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. 15 BRIEF DESCRIPTION OF THE DRAWINGS LO One or more embodiments of the invention will now be described, by way of example only, with CM reference to the accompanying drawings, in which: Figure 1 shows a vehicle in accordance with an embodiment of the invention in plan view; Figure 2 shows an ECU of the vehicle of Figure 1; Figure 3 shows a flow chart showing a bootup procedure to be performed on the ECU of Figure 2; 25 Figure 4 shows a flow chart showing a secure boot routine of the procedure of Figure 3; Figure 5 shows a flow chart showing a trusted boot routine of the procedure of Figure 3; and 30 Figure 6 shows a flow chart showing an authenticated boot routine of the procedure of Figure 3. DETAILED DESCRIPTION In general terms, embodiments of the invention provide hybrid boot routines for booting a vehicle 35 control system and / or control modules of a vehicle control system. The hybrid boot routines typically involve using different types of boot routine on different controllers, taking into account the varying hardware resources available on each controller to ensure that the overall boot procedure completes within a prescribed time window and whilst maintaining security. In this respect, hybrid boot routines may find particular application in vehicle control systems 5 incorporating one or more ECUs based on a master-slave architecture and therefore having multiple controllers, to enable the number of individual ECUs in the system to be reduced. In that context, embodiments of the invention beneficially enable existing levels of cybersecurity to be preserved without violating an applicable time window for booting the ECUs and with existing controller hardware. 10 In some examples, a hybrid boot may employ two or more types of boot routine selected from three options: a ‘secure boot’, which as noted above involves verifying all software components before executing them; a ‘trusted boot’, which involves verifying only selected software components before execution, and then verifying the remaining components during runtime; and an 'authenticated boot’, 15 in which substantially all components are verified during runtime. As the trusted boot and authenticated boot each involve verifying some components after booting and therefore during LO runtime, the hybrid boot allows the ECU as a whole to boot before all software components have CM been verified and thereby quickly, whilst ensuring that all components are ultimately verified to reduce the risk of executing corrupted or modified software. For example, a master controller may implement a 'secure boot', while connected slave controllers “ implement either a 'trusted boot' or an 'authenticated boot'. In this way, each controller is able to complete its respective boot process in a prescribed time window, without having to alter the controller hardware. Using a secure boot in the master controller helps to minimise the risk of 25 executing corrupted or modified software in the most critical part of the ECU. As an example, if an SBC of the control system dictates a particular configuration time window for a slave controller at system boot, the slave controller may have to be relatively powerful to complete a secure boot in the specified time, and potentially as powerful as a master controller. While it may 30 be possible to run security mechanisms in master controllers only to avoid increasing the power of the slave controllers, this would make the slave controllers incapable of detecting any corruptions or modifications to their software components. Accordingly, using a hybrid boot routine enables the use of less powerful slave controllers that would not be capable of performing a secure boot in a specified configuration window, therefore reducing system resource requirements, whilst also preserving 35 security. Another use case that may constrain the window for booting an ECU relates to ECU start up timing requirements from a safety perspective. For example, an ECU responsible for operating an ABS (anti-lock braking system) must boot and commence execution of its main application quickly for the vehicle to function safely. In further use cases, ECUs may need to boot quickly for reasons other 5 than safety, for example ECUs responsible for user-facing features where a lag in functionality is deemed undesirable. One example of this is an ECU that operates an instrument panel cluster, which is expected to be ready to use without any perceivable lag when the vehicle is started. To provide context, Figure 1 shows a vehicle 10 in which embodiments of the invention may be 10 implemented. It is noted, however, that embodiments of the invention are applicable to a wide range of vehicles, and so the vehicle 10 shown in Figure 1 is purely an example. The vehicle 10 of this example is an electric vehicle having an electrical powertrain (not shown) that is powered by a battery pack 12. The vehicle 10 further includes a charging port 14 through which 15 to charge the battery pack 12 from an external power source. LO The vehicle 10 also comprises a network architecture or control system 18 that includes a set of CM ECUs 20 that are each responsible for controlling one or more functions of the vehicle 10. Figure 1 shows the control system 18 in simplified form, for example to show only a selection of the ECUs 20, although it will be appreciated that the control system 18 will include many more ECUs 20 in practice. Communication between the ECUs 20 and other components of the control system 18 T"“ occurs through a vehicle bus 22, such as a CAN bus, represented by dashed lines in Figure 1. As shall become clear from the description that follows, the control system 18 is adapted to 25 implement a hybrid boot routine that is represented in Figure 3. One of the ECUs 20 shown in the control system 18 of Figure 1 is a battery control unit (BCU) 24, which controls operation of the charging port 14 and the battery pack 12. The BCU 24 has a masterslave architecture and combines the functionality that is provided by three separate ECUs 20 in other 30 control systems, namely: battery energy management to manage power flow into and out of the battery pack 12; managing communication between the vehicle and external charging infrastructure; and DC-DC conversion. In the BCU 24, each of these functions is handled by a respective controller of the ECU defining the BCU 24. 35 It is emphasised that the BCU 24 is referred to here only as an example of an ECU to which embodiments of the invention may be applied. In other examples, hybrid boot routines may be implemented in other vehicle ECUs, in particular any ECU having a master-slave architecture. The architecture of the BCU 24 is shown schematically and in greatly simplified form in Figure 2, which shows that the BCU 24 includes a master controller 26 and two slave controllers 28 designated as a first slave controller 28a and a second slave controller 28b. The master controller 26 and the 5 slave controllers 28 may be embodied as microcontrollers, for example. As Figure 2 also indicates, in principle further slave controllers could be incorporated into the BCU 24, or indeed any ECU 20 of the control system 18, to provide for additional features. In this example, the master controller 26 acts as a battery energy control module, the first slave 10 controller 28a acts as an on-board charger and so is responsible for controlling communication between the vehicle 10 and external charging infrastructure when the charging port 14 is connected to an external power source, and the second slave controller 28b is configured as a DC-DC converter and so manages power conversion between the charging port 14 and the battery pack 12. In this respect, the on-board charger 28a and the DC-DC converter 28b each need to be managed with 15 knowledge of the state of charge of the battery pack 12, hence the master controller 26 acts as the energy control module in this example. LD CXI The master controller 26 is configured as a full diagnostic server having a suite of security mechanisms providing full cybersecurity capability. The master controller 26 includes a network interface to communicate with the wider vehicle control system 18 over the vehicle bus 22. This also enables the master controller 26 to communicate with an off-board tester 30, through which software components can be uploaded to the master controller 26 and subsequently tested. In turn, the master controller 26 communicates with each slave controller 28 over a private network 25 32 or bus, the slave controllers 28 being capable of communication with the master controller 26 only. Each of the controllers includes an I / O (input / output) interface 34, through which data and signals are issued to and received from the private network 32. The master controller 26 includes the functionality to operate the slave controllers 28. Hence, as the 30 dashed box in Figure 2 indicates, the master and slave controllers 26, 28 form a functional unit defining an ECU in this example. In principle, however, the master and slave controllers could be physically separate. In either case, the BCU 24 is registered as a single ECU having a single diagnostic address for communication in the control system 18. 35 The slave controllers 28 are heavily dependent on the master controller 26 to operate, and cannot operate independently. For example, the slave controllers 28 have limited cybersecurity capability, and may be equipped with different verification hardware. In this respect, the master controller 26 may include a full Hardware Security Module (HSM), whereas the slave controllers 28 may be provided with lower grade HSMs, such as a medium HSM, or a light HSM or 'Secure Hardware Extension’ (SHE). This allows the slave controllers 28 to be lower cost, while a hybrid boot routine such as described below can account for the reduced capability. It is also possible for the slave 5 controllers 28 to be equipped with full HSMs, however. Accordingly, operation of the slave controller 28 proceeds based on exchanges of control and diagnostic data with the master controller 26, such that the slave controller 28 is operable by the master controller 26. 10 It is to be understood that each controller 26, 28 of the BCU 24 can comprise a control unit or computational device having one or more electronic processors (e.g., a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), etc.), and may comprise a single control unit or computational device, or alternatively different functions of the or each controller 26, 15 28 may be embodied in, or hosted in, different control units or computational devices. LO As used herein, the term “controller,” “control unit,” or “computational device” will be understood to CM include a single controller, control unit, or computational device, and a plurality of controllers, control units, or computational devices collectively operating to provide the required control functionality. A set of instructions could be provided which, when executed, cause the controller 26, 28 to implement the control techniques described herein (including some or all of the functionality required for the method described herein). The set of instructions could be embedded in said one or more electronic processors of the controller 26, 28; or alternatively, the set of instructions could be provided as software to be executed in the controller 26, 28. A first controller or control unit may be implemented 25 in software run on one or more processors. One or more other controllers or control units may be implemented in software run on one or more processors, optionally the same one or more processors as the first controller or control unit. Other arrangements are also useful. In the example illustrated in Figures 1 and 2, the master controller 26 comprises at least one 30 electronic processor 36 having one or more electrical input(s) 38 for receiving one or more input signal(s), and one or more electrical output(s) 40 for outputting one or more output signal(s). In this example, the at least one electronic processor 36 includes an HSM, which is configured to provide an area for secure storage of crypto materials used for boot routines described below. The HSM includes firmware that is responsible for using the stored crypto materials for verifying software 35 during boot up of the controller. The master controller 26 further comprises at least one memory device 42 electrically coupled to the at least one electronic processor 36 and having instructions 44 stored therein. The at least one electronic processor 36 is configured to access the at least one memory device 42 and execute the instructions 44 thereon so as to perform a hybrid boot routine such as described below with reference 5 to Figure 3. It should be appreciated that each slave controller 28 may be configured in a similar manner, although this is not represented in Figure 2 for simplicity. It is also noted that the slave controllers may use lower cost, albeit less capable, alternatives to a full HSM, such as SHEs, as noted above. The, or each, electronic processor 36 may comprise any suitable electronic processor (e.g., a microprocessor, a microcontroller, an ASIC, etc.) that is configured to execute electronic instructions. The, or each, electronic memory device 42 may comprise any suitable memory device and may store a variety of data, information, threshold value(s), lookup tables or other data structures, and / or 15 instructions therein or thereon. In an embodiment, the memory device 42 has information and instructions for software, firmware, programs, algorithms, scripts, applications, etc. stored therein or LO thereon that may govern all or part of the methodology described herein. The processor, or each, CM electronic processor 36 may access the memory device 42 and execute and / or use that or those instructions and information to carry out or perform some or all of the functionality and methodology describe herein. T"“ The at least one memory device 42 may comprise a computer-readable storage medium (e.g. a non- transitory or non-transient storage medium) that may comprise any mechanism for storing information in a form readable by a machine or electronic processors / computational devices, 25 including, without limitation: a magnetic storage medium (e.g. floppy diskette); optical storage medium (e.g. CD-ROM); magneto optical storage medium; read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g. EPROM ad EEPROM); flash memory; 'one time programmable memory' (OTP), for example for storing security critical data that should not be erased throughout the lifecycle of the controller; or electrical or other types of medium for storing 30 such information / instructions. Example controllers 26, 28 have been described comprising at least one electronic processor 36 configured to execute electronic instructions stored within at least one memory device 42, which when executed causes the electronic processor(s) 36 to carry out a method as described below. 35 However, it is contemplated that the present invention is not limited to being implemented by way of programmable processing devices, and that at least some of, and in some embodiments all of, the functionality and or method steps of the present invention may equally be implemented by way of non-programmable hardware, such as by way of non-programmable ASIC, Boolean logic circuitry, etc. Turning now to Figure 3, a boot procedure defining a hybrid boot routine 50 is shown that is 5 implemented by the control system 18 when booting the control system 18, for example at vehicle start-up. The hybrid boot routine 50 is shown as applied to the BCU 24 in Figure 3, but it should be appreciated that similar boot routines may be applied in each of the other ECUs 20 of the control system 18 that are configured with a master-slave architecture. 10 In general terms, each of the controllers 26, 28 of the BCU 24 is equipped with standard hardware and software components that are involved in the hybrid boot routine 50 for booting the controller 26, 28. These features include: a bootROM, which is a memory used for storing instructions for booting the controller 26,28, and in this example forms part of the memory device 42 of the controller 26, 28; a hardware security module (HSM), which is a device that executes instructions from the 15 bootROM to verify executable software components of the controller 26, 28 using digital keys and encryption, and in this example forms part of the electronic processor 36 of the controller 26, 28; a LO bootmanager, which is a program that is responsible for booting the controller 26, 28; and a main CM application, which is a program that, when executed, implements the features provided by the controller 26, 28, once booted. The bootROM is configured to run the first piece of code stored and defines the trust anchor. This code is not verified because it is programmed in an OTP area and so does not change throughout the lifecycle of the ECU. This first piece of code activates the HSM and requests verification of the other executable software components. 25 The bootmanager determines, based on predefined conditions, which software component to hand control over to in the present cycle. In this example, the bootmanager selects between a bootloader and the main application. Once the bootmanager is verified and has made its selection, the bootmanager then asks the HSM to verify the selected software component, before handing over 30 the control to the selected component. For example, the bootloader may be used primarily on cycles in which a new application is being installed, with control being handed directly to the application in all other cycles. Beneficially, providing the bootloader separately from the bootmanager also entails that the bootloader should be available to hand control to in the event that the application is not verified. The bootmanager itself is typically a small piece of code that can be stored securely in an 35 OTP area and so is less vulnerable to corruption. The BCU 24 also includes a power manager, also referred to as ‘power modes’, which is a program that controls powering up and down of the BCU 24. The power manager is configured to waken the BCU 24 and commence the hybrid boot routine 50 when a particular power mode corresponding to a vehicle state is published in the network. 5 The hybrid boot routine 50 commences with a command at step 52 to activate the ECU defining the BCU 24. This command may be received from the vehicle bus 22 by the power manager of the BCU 24. 10 Instructions are then read from the bootROM of the master controller 26 to initiate a boot routine for the master controller 26 at step 54, specifically a secure boot routine 56 that is shown in Figure 4. The secure boot routine 56 starts by activating the HSM of the master controller 26 at step 58, and then performing a verification sequence at step 60 in which the HSM verifies each software component of the master controller 26, the components being checked and verified in a predefined 15 sequence to confirm that each component is present, correct and not corrupted. This is achieved by comparing a ‘cipher-based message authentication code’ (CMAC) of the current software with a LO CMAC held by the HSM of the authentic software that was originally downloaded, to confirm a match CM and thereby identify the component. The components to be verified by the HSM include the bootmanager, the bootloader and the main application of the master controller 26, although this list is not exhaustive. At a predefined stage of the verification sequence, the HSM starts the bootmanager of the master controller 26 and then, when the verification sequence subsequently completes, the outcome of the verification sequence performed by the HSM is issued to the bootmanager at step 62. As Figure 3 25 shows, at this stage the bootmanager checks at step 64 the result of the verification sequence. If the verification has failed, for example because a software component has been found to be corrupted or missing, the bootmanager prohibits the main application of the master controller 26 from loading at step 66. The hybrid boot routine 50 is then indicated to have failed at step 70, and the control remains with the last verified software component, in this example the bootmanager. A flag is also 30 raised to indicate that the BCU is not functioning due to corrupted or otherwise unverified software. Alternatively, if the verification sequence outputs a positive result such that all software components of the master controller 26 are verified, the main application of the master controller 26 is loaded at step 72 and the secure boot routine 56 completes. Then, the hybrid boot routine 50 moves on to the 35 first slave controller 28a. In this respect, the main application of the master controller 26 issues a control signal to the first slave controller 28a to read instructions from the bootROM of the first slave controller 28a to initiate a boot routine at step 74. In this example, the BCU 24 is configured such that a trusted boot routine 76 is performed on the first slave controller 28a, which is represented in Figure 5. 5 As Figure 5 shows, the trusted boot routine 76 commences by activating the HSM of the first slave controller 28a at step 78. For the trusted boot routine 76, this triggers a pre-verification process 79 that is also shown in Figure 5, that involves verification of selected software components of the first slave controller 28a only by the HSM. Other software components are verified later by the HSM 10 during runtime of the main application. Specifically, in this example, for the trusted boot routine 76 the HSM verifies only the bootmanager at step 80 before loading the main application of the first slave controller 28a. If the bootmanager is successfully verified at step 82, the bootmanager is then started at step 84. Once started, in a second 15 stage of the pre-verification process 79 the bootmanager receives a verification result for the components of the first slave controller 28a from the previous run cycle. If the verification result is LO found to be clear of flags at step 85, the main application of the first slave controller 28a is loaded at CM step 86. If the bootmanager is not verified at step 82, the bootmanager is not started so that the main application is prohibited from loading at step 88, and the hybrid boot routine 50 fails at step 70. Similarly, if the bootmanager is started but then detects one or more flags in the verification result at step 85, the main application is prohibited from loading at step 88, and the hybrid boot routine 50 25 fails at step 70. In general terms, when the hybrid boot routine 50 fails due to an issue in one of the slave controllers 28, a decision can be made either to reset the BCU 24 entirely or to raise a flag and prevent execution of the flagged component in a subsequent power cycle. 30 Returning to Figure 5, if the bootmanager is verified and the main application loads, the HSM then continues to verify the remaining components of the first slave controller 28a during runtime of the main application at step 90. This continued verification is performed in a similar sequence to the verification sequence of the secure boot 56 of the master controller 26. So, the components are 35 checked and verified in a predefined sequence to confirm that each component is present, correct and not corrupted. In this example, the remaining components to be verified primarily include the main application itself, which is therefore verified by the HSM while executing. If the HSM finds a problem with the main application, for example the CMAC is incorrect such that the verification fails, the application can either be terminated or else the application may be flagged and prevented from executing on the next power cycle. It is noted that some ECUs may include calibration software, which would also be verified in runtime for a trusted boot routine, typically after the main application. 5 Alternatively, if the HSM verifies that the main application is correct, the application is allowed to continue executing and the trusted boot routine 76 completes. Then, the hybrid boot routine 50 moves on to the second slave controller 28b. 10 In this respect, the main application of the first slave controller 28a issues a control signal to the second slave controller 28b to read instructions from the bootROM of the second slave controller 28b to initiate a boot routine for the second slave controller 28b at step 92. In this example, the BCU 24 is configured such that an authenticated boot routine 94 is performed on the second slave controller 28b, which is represented in Figure 6. 15 As Figure 6 shows, the authenticated boot routine 94 commences by activating an HSM of the LO second slave controller 28b at step 96. For the authenticated boot routine 94, no verification of CM software components occurs before starting the bootmanager of the second slave controller 28b, although the HSM does check at step 98 for flags that preclude booting of the second slave controller 28b. For example, similarly to the first slave controller 28a, the HSM of the second slave controller 28b may analyse a verification result from a previous run cycle of the second slave controller 28b. In this respect, it is noted that each step of the hybrid boot routine 50 may include checks for relevant flags, and the hybrid boot routine 50 can be terminated upon detection of a relevant flag. Such flags 25 may have been allocated in earlier iterations of the hybrid boot routine 50, for example. Assuming no flags are present, the bootmanager of the second slave controller 28b is started immediately, and the main application of the second slave controller 28b is loaded at step 100. Then, after loading the main application, the HSM commences a verification sequence at step 102 in which 30 all of the software components of the second slave controller 28b are verified in series, including the bootmanager and the main application, as well as calibration software if present, all of which are therefore verified during runtime. If the verification of any of the software components of the second slave controller 28b fails at step 35 104, a flag is raised. The master controller 26 then investigates the flag and determines whether to allow the second slave controller 28b to continue running or to stop the main application at step 106, such that the authenticated boot routine 94 fails at step 70. To make this decision, the master 14 04 25 controller 26 may take various parameters of the vehicle state into account, such as the vehicle speed or safety states. Corrective action for a slave controller 28 presenting an issue can then be implemented as noted above, by either flagging the issue for the next power cycle or by resetting the BCU 24. 5 Alternatively, if the software components of the second slave controller 28b are successfully verified, the authenticated boot routine 94 completes, which in turn completes the overall hybrid boot routine 50 at step 108. The BCU 24 is then successfully booted with all software components verified and can operate normally. 10 The hybrid boot routine 50 shown in Figure 3 is merely an example, and many variants are possible. For example, slave controllers 28 may be booted in parallel instead of in series as in the hybrid boot routine 50 of Figure 3. 15 Also, while a secure boot is always used for the master controller 26, any combination of trusted boots and authenticated boots can be used for slave controllers 28. So, all slave controllers 28 may use authenticated boot routines, all may use trusted boots, or the controllers 28 may use any mixture of authenticated and trusted boots, for example. It may also be possible to use a secure boot routine for some, but not all, slave controllers. It will also be appreciated that for ECUs having more than two slave controllers, a further boot routine will be performed on each additional slave controller, for example a trusted boot or an authenticated boot. 25 It will be clear from the above that a trusted boot is more secure than an authenticated boot, due to the reduced number of components that are verified during runtime. Conversely, a slave controller 28 can be booted more quickly using an authenticated boot. The choice of boot routine adopted in the slave controllers 28 will therefore depend on a balance between the level of security required and the resources available to complete the boot routine in the relevant time window. 30 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 a vehicle, the control system comprising a master controller and at least one slave controller that is operable by the master controller, the control system being5 configured to:perform a first boot routine when booting the master controller, the first boot routine being configured to verify all software components to be executed by the master controller before booting the master controller; and10perform a second boot routine when booting the at least one slave controller, the second boot routine comprising an authenticated boot and the second boot routine being configured to verify all software components to be executed by the at least one slave controller after booting the at least one slave controller.

152. The control system of claim 1, comprising a control unit that comprises the master controller LO and the at least one slave controller.CM3. The control system of any preceding claim, wherein the first boot routine comprises a secure boot.T"“ 4. The control system of any preceding claim, configured to complete the first boot routine beforecommencing the second boot routine.25 5. The control system of any preceding claim, comprising multiple slave controllers that areoperable by the master controller.

6. The control system of claim 5, configured to perform the second boot routine when booting a first slave controller, and to perform a third boot routine when booting a second slave controller, 30 wherein the third boot routine is different to the second boot routine.

7. The control system of claim 6, wherein the third boot routine is configured to verify at leastsome software components to be executed by the second slave controller after booting the second slave controller.

358. A vehicle comprising the control system of any preceding claim.

9. A method for operating a vehicle control system comprising a master controller and at least one slave controller that is operable by the master controller, the method comprising:verifying all software components to be executed by the master controller before booting 5 the master controller; andverifying all software components to be executed by the at least one slave controller after booting the at least one slave controller, via an authenticated boot.10 10. Computer software that, when executed, is arranged to perform a method according to claim9.

11. A non-transitory, computer-readable storage medium storing instructions thereon that, when executed by one or more electronic processors, causes the one or more electronic processors 15 to carry out the method of claim 9.LD

Images