Electronic control unit

Abstract

An electronic control unit 200 of a vehicle comprising a first memory bank 204 and a second memory bank 208, wherein the electronic control unit is configurable to execute computer code stored in the first memory bank while the second memory bank is being reprogrammed, said computer code comprising a set of at least one software module executable to provide runtime functionality of the electronic control unit. The electronic control unit is configured to: receive an update mode signal indicative of an update mode of operation of the electronic control unit; if the update mode signal is indicative of a first mode of operation 304, the electronic control unit is configured to perform the reprogramming of the second memory bank whilst the set of at least one software module is enabled; and if the update mode signal is indicative of a second mode of operation 306, the electronic control unit is configured to perform the reprogramming of the second memory bank whilst at least a subset of the set of at least one of software module is inhibited.

Description

TECHNICAL FIELD The present disclosure relates to an electronic control unit of a vehicle. Aspects of the invention relate to an electronic control unit, a system for a vehicle, a vehicle, a method, and computer readable instructions. BACKGROUND It is known for a vehicle to comprise electronic control units to control various components and systems of the vehicle. New functionality is being added to modern electronic control units as automotive technologies develop. New functionality may be included in an electronic control unit by performing a software update. Some electronic control units are so-called dual banked electronic control units, which can operate by one of two memory banks being active and providing functionality, while the other of the two memory banks is inactive. The inactive memory bank may be used to receive a software update in the background, and the electronic control unit may operate according to the updated software later by switching the inactive bank to operating as an active bank, and vice versa. However, software updates provided in this way may take some time to fully download. 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 an electronic control unit, a system fora vehicle, a vehicle, a method, and computer readable instructions. According to an aspect of the present invention there is provided an electronic control unit comprising a first memory bank and a second memory bank, wherein the electronic control unit is configurable to execute computer code stored in the first memory bank during reprogramming of the second memory bank, said computer code configured to control operation of the electronic control unit; the electronic control unit configured to, when the vehicle is determined to be in a update mode, execute a subset of the computer code stored in the first memory bank during reprogramming of the second memory bank. Advantageously, the second memory bank can be reprogrammed when the vehicle is in an update mode, so that a subset of resources are allocated to providing the subset of computer code functionality while the remaining resources are allocated to updating software in the other memory bank. According to an aspect of the present invention there is provided an electronic control unit of a vehicle, the electronic control unit comprising a first memory bank and a second memory bank, wherein the electronic control unit is configurable to execute computer code stored in the first memory bank while the second memory bank is being reprogrammed, said computer code comprising a set of at least one software module executable to provide runtime functionality of the electronic control unit; the electronic control unit configured to, whilst executing the computer code stored in the first memory bank: receive an update mode signal indicative of an update mode of operation of the electronic control unit; wherein: if the update mode signal is indicative of a first mode of operation, the electronic control unit is configured to operate in a first update mode in which the electronic control unit is configured to perform the reprogramming of the second memory bank whilst the set of at least one software module is enabled; and if the update mode signal is indicative of a second mode of operation, the electronic control unit is configured to operate in a second update mode in which the electronic control unit is configured to perform the reprogramming of the second memory bank whilst at least a subset of the set of at least one software module is inhibited. By inhibiting at least some of the runtime functionality of the electronic control unit through inhibiting a subset of the set of at least one software module, processing resources are freed up in order to allow the software update (reprogramming of the memory bank not providing the subset of functionality) to be performed more quickly. It may be that the electronic control unit function software which is used to operate the vehicle (or at least a component of the vehicle controlled by the electronic control unit) cannot run during the updating process. The first mode of operation may be considered to be a “background” programming mode whereby, for example, as the first memory bank is used to provide the runtime functionality of the enabled set of at least one software module, the second memory bank is used to receive and install the software update. The second mode of operation may be considered to be a “pseudo-foreground” programming mode whereby, for example, as the first memory bank is used to provide only a subset of the full runtime functionality of the set of at least one software module, while the remainder of the set of at least one software module is inhibited, the second memory bank is used to receive and install the software update. The second memory bank has an increased available processor power and bandwidth for receiving software update as software-over-the-air (SOTA) than if the first memory bank was running the set of software to provide runtime functionality, because this would use processor power and bandwidth. By only running a subset of software, in the second mode of operation, the software update may be performed more quickly than in the first mode of operation. In the second mode of operation, the electronic control unit may be configured to execute non-inhibited computer code of the set of at least one software module whilst the second memory bank is being reprogrammed. The non-inhibited computer code of the set of at least one software module executed in the second mode of operation may comprise reprogramming software configured to reprogram software in the electronic control unit. The non-inhibited computer code of the set of at least one software module executed in the second mode of operation may comprise essential software configured to provide essential functionality by the electronic control unit, for example, to meet regulation. Advantageously, software updating may still be performed much more quickly by the electronic control unit operating in this way and certain software may still be able to run to provide some level of functionality while the functioning of other software (outside the subset) is inhibited from running while software updating is performed. In dependence on receipt of the update mode signal indicative of the first mode of operation, the electronic control unit may be configured to control network communication bandwidth available between the electronic control unit and an external communication device to allocate a first level of network communication bandwidth to receive the software update by the electronic control unit. In dependence on receipt of the update mode signal indicative of the second mode of operation, the electronic control unit may be configured to control network communication bandwidth available between the electronic control unit and an external communication device to allocate a second level of network communication bandwidth to receive the software update by the electronic control unit. The second level of network communication bandwidth is greater than the first level of network communication bandwidth. Advantageously, once the second mode of operation is indicated, the electronic control unit can be controlled to allocate more communication bandwidth to the software update process, to allow for quicker software updating, compared with not allocating more bandwidth to the software updating process. The communications bandwidth is not needed for software operation in the second mode as much as in the first mode since only a subset of software modules, which may make use of communications bandwidth, are enabled in the second mode. In the second mode of operation, a portion of available network communication bandwidth may be reserved for use by the electronic control unit for reprogramming software configured to reprogram software in the electronic control unit. In the second mode of operation, a portion of available network communication bandwidth may be reserved for use by the electronic control unit for essential software configured to provide essential functionality by the electronic control unit, for example, to meet regulations. The electronic control unit may be configured to, when operating in the second update mode, and following reprogramming of the second memory bank, cause the reprogrammed software of the second memory bank to be written to the first memory bank. The reprogrammed software of the second memory bank may be written to the first memory bank without first performing a run test of the reprogrammed software. Advantageously, once the reprogramming has been performed in one memory bank, when operating in the second update mode, no run test is carried out and the reprogrammed software is written to the other memory bank (thereby allowing the software update to be performed, and written to both memory banks, more quickly than if a run test is carried out). This may take place, for example, if the software update takes place while the vehicle is proximal to a user who is able to manually perform a software rollback in the event of an error in software updating, or if the software update is flagged as having a low importance to justify omitting the time taken to perform the run test. The electronic control unit may be configured to, when operating in the second update mode: perform a run test of the software update installed in the electronic control unit; in dependence on receiving a pass indicator indicative of the software update executing correctly in the run test, cause the reprogrammed software of the second memory bank to be written to the first memory bank; and in dependence on receiving a fail indicator indicative of the computer code executing incorrectly in the run test, cause the software stored in the first memory bank to be written to the second memory bank. Advantageously, in the second update mode, once the reprogramming has been performed in one memory bank, a test of the reprogrammed software may be carried out to ensure it runs as expected, before the updated software is committed to the other memory bank. This may take place, for example, if the software update takes place while the vehicle is remote from a user who is able to manually perform a software rollback in the event of an error in software updating, or if the software update is flagged as having a high importance to justify the time taken to perform the run test. The software update can be committed to the first memory bank once it has been verified that it has downloaded correctly and that is it valid by way of performing the run test (i.e. the software runs as intended alone and in combination with other software running on the electronic control unit). The electronic control unit may be configured to, when operating in the first update mode: perform a run test of the software update installed in the electronic control unit; in dependence on receiving a pass indicator indicative of the software update executing correctly in the run test, cause the reprogrammed software of the second memory bank to be written to the first memory bank; and in dependence on receiving a fail indicator indicative of the computer code executing incorrectly in the run test, cause the software stored in the first memory bank to be written to the second memory bank. Advantageously, a check may be made that the software update operates as expected before committing the software update to the other memory bank. The electronic control unit may be configured to, in response to receiving the update mode signal indicative of an update mode of operation of the electronic control unit, and prior to reprogramming of the second memory bank, store a log of the current software running on the electronic control unit and a current context of the electronic control unit. Advantageously, a log of software updates can be recorded to keep a check of what software and which versions of the software have been used, and when, e.g. for diagnostic purposes. The electronic control unit may be configured to operate in the second mode in response to a determination that the vehicle is in the manufacturing line. In the manufacturing line, a software update may be received in an uninterrupted transmission (that is, the electronic control unit will not be switched off or required for operation out of the second mode during software receipt) and so the software update can take place with the electronic control unit operating in the second mode. Reprogramming of the second memory bank may comprise downloading the software update to the second memory bank; verifying that the software update has completed downloading; and checking the validity of the downloaded software update. Advantageously, the software update may be performed without storing a previous version of the software in the same memory bank as that being updated, because the “back up” previous software version is stored in the other (first) memory bank. The electronic control unit may be configured to, following reprogramming of the second memory bank, execute the computer code stored in the second memory bank. Advantageously, the updated software be used to operate the ECU. Furtherto the first mode of operation and the second mode of operation, if the update mode signal is indicative of a further mode of operation, the electronic control unit may be configured to operate in a further update mode in which the electronic control unit is configured to perform a reprogramming of the second memory bank whilst at least a further subset of the set of at least one software module is inhibited, wherein the further subset of the set of at least one software module is different to the subset of the set of at least one software module inhibited in the second operation mode. Advantageously, there may be more than one mode for software reprogramming while a subset of software modules are inhibited. The electronic control unit may be configured to perform a precondition test to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank of the electronic control unit in the second mode of operation; and receive the update mode signal indicative of the update mode of operation of the electronic control unit in dependence on the vehicle passing the precondition test. Advantageously, the software update takes place once one or more preconditions are met, to help ensure the vehicle is in an appropriate state of operation prior to performing the software update in the second mode. According to an aspect of the present invention there is provided a system for a vehicle, the system comprising: any electronic control unit disclosed herein, and a vehicle module configured to be controlled by the set of at least one software module executed by the electronic control unit. The electronic control unit is for controlling a module of the vehicle in an improved way as discussed herein. According to an aspect of the present invention there is provided a vehicle comprising any system disclosed herein or any electronic control unit disclosed herein. A vehicle may thus be provided with an improved way of updating electronic control unit software. According to an aspect of the present invention there is provided a method of operation of an electronic control unit of a vehicle comprising a first memory bank and a second memory bank, wherein the electronic control unit is configurable to execute computer code stored in the first memory bank while the second memory bank is being reprogrammed, said computer code comprising a set of at least one software module executable to provide runtime functionality of the electronic control unit; the method comprising: receiving an update mode signal indicative of an update mode of operation of the electronic control unit; wherein: if the update mode signal indicative of a first mode of operation, the electronic control unit operates in a first update mode in which the electronic control unit is configured to perform reprogramming of the second memory bank whilst the set of at least one software module is enabled; and if the update mode signal indicative of a second mode of operation, the electronic control unit operates in a second update mode in which the electronic control unit is configured to perform reprogramming of the second memory bank whilst at least a subset of the set of at least one software module is inhibited. Advantageously, by inhibiting some of the runtime functionality of the electronic control unit, processing resources are freed up for the software update. The second memory bank may therefore have increased computing resources available for software updates and the software update may take place more quickly than in the first mode of operation. The method may comprise receiving the update mode signal indicative of the second mode of operation of the electronic control unit; and executing non-inhibited computer code of the set of at least one software module by the first memory bank whilst reprogramming the second memory bank. Advantageously, some functionality is still provided during reprogramming in the second mode of operation. The method may comprise performing a precondition test to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank in the second mode of operation; and receiving the update mode signal indicative of the update mode of operation of the electronic control unit in dependence on the vehicle passing the precondition test. Advantageously a check can be first made that the vehicle is in a suitable operational state to reprogram the second memory bank in the second mode of operation prior to switching to operation in this mode. In an aspect there is provided computer readable instructions which, when executed by an electronic control unit as disclosed herein, are arranged to perform any method disclosed herein. In an aspect there is provided a non-transitory, computer-readable storage medium storing instructions thereon that, when executed by an electronic control unit as disclosed herein, causes the electronic control unit to carry out any method disclosed herein. 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 anyway 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 an example vehicle comprising an electronic control unit (ECU) according to examples disclosed herein; Figure 2 shows an example ECU according to examples disclosed herein; Figure 3 shows an example method of operation of an ECU according to examples disclosed herein; Figures 4A to 4D show an example method of operation of an ECU according to examples disclosed herein; and Figure 5 illustrates a system for a vehicle according to examples disclosed herein. DETAILED DESCRIPTION As automotive technology develops and changes, and users expect more functionality from their vehicles, new functionalities are added to electronic control units (ECUs). As a consequence, modern embedded ECUs are hosting increasingly complex software. As the technology is evolving, and as new software components are being added to ECUs, there remain some legacy platform software components in the embedded ECUs, which may be redundant. If these redundant platform software components can be removed from the ECUs, then not only can the ECU software complexity be reduced, but also the engineering effort and associated operational costs forthe redundant software components may also be reduced. Dual banked embedded ECUs were introduced in the automotive domain to deliver software over the air capability, to reduce customer inconvenience due to vehicle downtime in installing software updates. However, dual banked ECUs continue to host some legacy platform software components for server programming, which remain present from their use in earlier single bank ECUs. Examples disclosed herein provide new dual banked ECUs which can operate with removed platform software components for server programming. In this way, ECU software complexity can be reduced without affecting ECU performance. Conventional boot software, also known as boot loader, in an embedded ECU, consists of two components. Firstly, the boot manager component is the component of the boot software which is responsible for ECU boot up. Secondly, the server programming component is a component of the boot software which is responsible fordownloading external application software and application data to the ECU. Dual banked ECUs were introduced in the automotive domain to minimise customer inconvenience caused by downtime of the ECU associated with foreground software programming. Dual banked ECUs typically support both foreground, and background, software programming. Examples disclosed herein propose removal of the server programming component of the boot loader for the dual banked ECUs, to support only background programming. This means that there will be no impact of the change on all software over the air (SOTA) use cases. Use cases where foreground software programming is used are addressed by the use of scenario specific modes for background software programming. In an example, in the manufacturing line, where quicker ECU programming is desirable, a new background software programming mode is proposed, which does not need the foreground programming mode to be available, but does satisfy system constraints such as a short download time. Conventional single bank ECUs support only server programming in the foreground. When a single banked ECU undergoes foreground programming, the ECU executes the boot software from the programming session. In the programming session the normal functionalities of the ECU are typically switched off, unless they are mandated to be active e.g. by regulation. Therefore, when such single banked ECUs become a target for a software over the air (SOTA) update, this results in inconvenience for a user, because all the functionality offered by the ECU is not available during the software programming process. Dual banked ECUs were introduced in the automotive domain to minimise such user inconvenience caused by the ECU downtime associated with foreground software programming. Dual banked ECUs typically support both foreground and background software programming. Foreground software programming fora dual banked ECU is the same as that for a single banked ECU. Background software programming is a capability offered by dual banked ECUs. In the background programming mode, the dual banked ECU continues to offer all the ECU functionality from the active bank while the software programming takes place in the inactive bank. After the software programming is complete in the inactive bank, the memory banks are switched to conduct a first run test to check the compatibility of the recently downloaded software components with the rest of the ECU software. Depending on the outcome of the first run test, the recently downloaded software image is either committed or rolled back to the previous software image. A successful first run test results in the recently downloaded software being committed, and launched in the next power-up cycle. A failed first run test, on the other hand, results in rollback, and the previously active software prior to the background update will be launched in the next power-up cycle. Comparing the performance of foreground and background software programming modes, it can be seen that the overall programming time is much higher for the background programming mode when compared to the foreground programming mode. This is primarily for the following two reasons: 1. As the background programming is running in the background while the user is using the vehicle, the process is subject to the driving pattern of the user. If the drive cycle is very short, then the background programming process is paused at the end of the drive cycle and resumed in the next driving cycle. However, when the foreground programming is taking place, the process is undisturbed, because the complete vehicle is taken into a specific programming mode and the target ECU is programmed without being interrupted. 2. If background programming is taking place in the inactive bank, the dual bank ECU is offering the full ECU functionality from the active bank. Therefore, most of the ECU processing power is prioritised towards offering ECU functionality and user usage. As a result, a much smaller portion of ECU processing power is available for the background software programming process. Comparing this to foreground programming, which, when this takes place, no ECU functionality is offered unless required e.g. by regulation, the software updating is much slower because in the foreground programming mode no ECU functionality is provided. Examples disclosed herein propose removal of the (legacy) server programming component of the boot software for dual banked ECUs. In this way, the dual banked ECUs will support background programming modes but not foreground programming. Foreground software programming is typically used in controlled time critical environments such as the manufacturing line. There will be no impact on software over the air (SOTA) use cases in which software is downloaded and installed as in traditional background programming. Examples disclosed herein propose to introduce a new mode for background programming, where the background update process runs for example, with the following preconditions and system constraints: the vehicle is stationary, safe and secure; background programming, once started, will not be interrupted inbetween programming; no ECU functionality is offered from the active bank, other than any essential functionality such as that required by regulation. In some examples, bank switching may be done without first conducting a first run test. Such a mode may be considered to be a pseudo-foreground programming mode. These preconditions and system constraints are acceptable, because this “pseudo-foreground” programming mode for background programming may be tailored forthe software updates under certain conditions, such as in the manufacturing line, where the vehicle environment and operation can be controlled. In some examples, such as when an operator is proximal to the vehicle and available to perform manual intervention in the event of a software update error, there may be no need to do the first run test prior to the launch. Another example in which a run test may be omitted may be in the manufacturing line, because the compatibility of the software components are checked later in the manufacturing end-of-line tests. Other use cases other than the manufacturing line use case can be envisaged, where ECU programming may be supported in a time critical scenario, in which case an assessment may be made whether the manufacturing “pseudo-foreground” programming mode may be used, or whether a different scenario-specific mode for background software programming may be provided for the specific scenario. By allowing for software over the air (SOTA) updates to take place in the proposed new background mode, advantages arise including: simplified software component production from the ECU, which leads to reduced complexity; a software part number reduction; software release management complexity reduction; ECU memory saving; overall engineering required is reduced, because one less software component needs to be developed and maintained over the life cycle of the ECU; cost reduction; test effort reduction; and part maintenance reduction. A vehicle 10 in accordance with an embodiment of the present invention is described herein with reference to the accompanying Figure 1. Figure 1 illustrates a vehicle 10 comprising an ECU 200 comprising a first memory bank and a second memory bank as discussed below. Figure 2 illustrates an ECU 200 according to examples disclosed herein. The ECU 200 comprises a boot manager 202 which is a “transient” piece of code which is run on start-up of the ECU 200 to boot up the ECU 200. A transient piece of code may be considered to be code which is temporary; that is, the code is temporarily available for at least the duration of that code being run or required, and otherwise, may not be stored or available. The boot manager 202 is responsible for launching the software component which provides ECU 200 functionality. The ECU 200 does not comprise a boot loader which may typically be found in other dual banked ECU 200s. A boot loader in other examples is used for performing download and installation of a software update to provide ECU 200 functionality. The boot loader is not needed in this example ECU 200 because the job of the boot loader is instead performed by the ECU 200 by operating in the pseudo-foreground programming mode. The boot loader may be considered to be a legacy piece of software which is no longer required when operating the ECU 200 as disclosed herein. The ECU 200 comprises a first memory bank 204 and a second memory bank 208. At any time, when one of the memory banks 204, 208 is “active”, the other of the memory banks 204, 208 is “inactive”. “Active” means that application software running in that memory bank is providing the functionality of the ECU 200. “Inactive” means that there is no application software running in that memory bank to provide the functionality of the ECU 200 although the inactive memory bank may still perform other tasks, such as receiving a software update. ECU 200 functionalities are offered by the applications running from either the first memory bank 204 or the second memory bank 208. If the first memory bank 204 is the so-called active bank, the applications run from the first memory bank 204 and functionality is provided by the applications running in the first memory bank 204. If the second memory bank 208 is the so-called active bank, the applications run from the second memory bank 208 and functionality is provided by the applications running in the second memory bank 208. While one memory bank is “active” the other memory bank is “inactive”. That is, the ECU 200 comprises a first memory bank 204 and a second memory bank 208, wherein the ECU 200 is configurable to execute computer code stored in the first memory bank 204 while the second memory bank 208 is being reprogrammed. Similarly, the ECU 200 is configurable to execute computer code stored in the second memory bank 208 while the first memory bank 204 is being reprogrammed. Said computer code comprises a set of at least one software module executable to provide runtime functionality of the ECU 200. Figure 2 shows that, in this example, the first memory bank 204 comprises a first background updater 206, and that the second memory bank 208 comprises a second background updater 210. Each background updater 206, 210 is configured to perform download and installation of a software update when the associated memory bank is inactive, the software update being to provide ECU 200 functionality of the associated memory bank. That is, when the other memory bank is the “active” memory bank running software to provide ECU 200 functionality, the memory bank is considered to be “inactive” and can receive and install a software update but is not running software to provide ECU 200 functionality. Thus, if the first memory bank 204 is active, and running software to provide ECU 200 functionality, a software update may be downloaded and installed in the second memory bank 208 managed by the first background updater 206 of the first memory bank 204. Further, if the second memory bank 208 is active, and running software to provide ECU 200 functionality, a software update may be downloaded and installed in the first memory bank 204 managed by the second background updater 210 of the second memory bank 208. That is, the background updaters 206, 210, are responsible to perform download and installation of a software update in the other memory bank 204, 208 operating in an inactive state, wherein the software update comprises code to provide ECU functionality. Each background updater 206, 210, when its corresponding memory bank 204, 208 is operating in the active state, may in part be responsible for providing software functionality of the other memory bank 204, 208 when that memory bank 204, 208 is operating in an inactive state. The ECU 200 is configured to receive an update mode signal indicative of an update mode of operation of the ECU 200. If an update mode signal indicative of a first mode of operation is received, the ECU 200 is configured to operate in a first update mode in which the ECU 200 is configured to perform reprogramming of the second memory bank 208 whilst the set of at least one software module is enabled. This first mode of operation may be called a background programming mode, because the software update is performed in the background on the so-called inactive memory bank while ECU 200 functionality is provided by software running by the so-called active memory bank. If an update mode signal indicative of a second mode of operation is received, the ECU 200 is configured to operate in a second update mode in which the ECU 200 is configured to perform reprogramming of the second memory bank 208 whilst at least a subset of the set of at least one software module is inhibited. This second mode of operation may be called a pseudo-foreground programming mode, because the software update is performed in a similar way to software provided in a foreground programming mode, in which there is no software running on the ECU 200 providing ECU 200 functionality (because there is only limited software running on the ECU 200 and other software is inhibited). However, there is a subset of software being provided rather than no software as in foreground programming. Also there is no boot loader present to perform foreground programming as used in foreground programming. Thus the term “pseudo-foreground” may be used to describe the second mode of operation, because an important difference between traditional foreground and background programming is that in foreground programming, software updating is the dominant software process taking place, whereas in background programming, ECU 200 functionality is the dominant software process taking place and software updating occurs with limited resources in the background. In this new “pseudo-foreground” second mode of operation, resources are available to the ECU 200 to perform software updating as a dominant software process taking place (or at least with more resources provided for software updating than in background programming) because only a subset of software is being executed to provide ECU 200 functionality while another subset of software is inhibited from running. The effect of performing software updating in this way is that the software update is performing with comparable ECU 200 resources (e.g. processor power, data bandwidth) as traditional foreground processing, but there is no separate boot loader software required to manage the software update. The memory bank performing the software update is the so-called “active” memory bank and performs the software update on the so-called “inactive” memory bank. Any functionality provided by the ECU 200 during software updating is provided by the “active” memory bank which is not receiving and installing the software update, but is (since it is “active” and thus able to provide some functionality) managing the software update in the “inactive memory” bank. By inhibiting at least some of the runtime functionality of the ECU 200 through inhibiting a subset of the set of at least one software module, processing resources are freed up in order to allow the software update (reprogramming of the memory bank not providing the subset of functionality) to be performed more quickly. Because a subset of ECU 200 functionality is inhibited during operation in the second mode of operation, the ECU 200 function software to operate the vehicle in a normal mode of use cannot run during software updating (a normal mode of use may be while being driven by an end user, for example, when full ECU functionality should be available for use). Thus in the second mode of operation (the “pseudo-foreground” mode), if the first memory bank 204 is configured to execute computer code while the second memory bank 208 is being reprogrammed, the first memory bank 204 is configured to execute non-inhibited computer code of the set of at least one software module whilst the second memory bank 208 is being reprogrammed. If the second memory bank 208 is configured to execute computer code while the first memory bank 204 is being reprogrammed, the second memory bank 208 is configured to execute non-inhibited computer code of the set of at least one software module whilst the first memory bank 204 is being reprogrammed. By continuing to execute program code from one memory bank while functionality is provided by the other memory bank, the software update can take place in the background while a non-inhibited subset of the set of at least one software module is running. Non-inhibited computer code of the set of at least one software module executed in the second mode of operation may comprise reprogramming software configured to reprogram software in the ECU 200. The non inhibited computer code may comprise essential software configured to provide essential functionality by the ECU 200, for example to meet regulatory requirements. In the first mode of operation (the “background” mode), if the first memory bank 204 is configured to execute computer code while the second memory bank 208 is being reprogrammed, the first memory bank 204 may be configured to execute computer code of the set of at least one software module whilst the second memory bank 208 is being reprogrammed; and if the second memory bank 208 is configured to execute computer code while the first memory bank 204 is being reprogrammed, the second memory bank 208 may be configured to execute computer code of the set of at least one software module whilst the first memory bank 204 is being reprogrammed. Thus in the first mode of operation (background mode) the ECU 200 can provide full functionality while a software update is performed by reprogramming of the memory bank not providing the full functionality. In dependence on receipt of the update mode signal indicative of a first mode of operation, the ECU 200 may be configured to operate in the first update mode to perform the software update whilst the set of at least one software module is enabled. In dependence on receipt of the update mode signal indicative of a second mode of operation, the ECU 200 may be configured to operate in the second update mode to perform the software update whilst the at least a subset of the set of at least one software module is inhibited. Thus receipt of the update mode signal switches the operation mode of the ECU 200 to perform the software update according to the indicated mode. The update mode signal may be provided, for example, to indicate the vehicle is in the manufacturing line and thus in a suitable state for a software update to take place in the pseudo-foreground programming mode (an example of the second mode), because in the manufacturing line, only a small subset of possible functionality is required since the vehicle is not being driven. Figure 3 illustrates a method of operation 300 of an ECU 200 comprising a first memory bank 204 and a second memory bank 208 as in Figure 2. The first memory bank 204 is configured to execute computer code while the second memory bank 208 is being reprogrammed, and the second memory bank 208 is configured to execute computer code while the first memory bank 204 is being reprogrammed. The computer code comprises a set of at least one software module executable to provide runtime functionality of the ECU 200. The method 300 comprises receiving an update mode signal 302. The update mode signal is indicative of an update mode of operation of the ECU; for example, because a software update is to be received and installed by the ECU 200. An update mode signal indicative of a first mode of operation causes the ECU 200 to operate in a first update mode 304 in which the ECU 200 is configured to perform the reprogramming of the second memory bank whilst the set of at least one software module is enabled. This may be considered a background programming mode as above. An update mode signal indicative of a second mode of operation causes the ECU 200 to operate in a second update mode 306 in which the ECU 200 is configured to perform the reprogramming of the second memory bank whilst at least a subset of the set of at least one software module is inhibited. This may be considered to be the pseudo-foreground programming mode. In some examples, the method 300 may comprise receiving the update mode signal 302 indicative of the second mode of operation of the ECU; and executing non-inhibited computer code 308a of the set of at least one software module by the first memory bank 204 whilst reprogramming 308b the second memory bank 208, and vice versa. That is, on receiving an update mode signal indicative of the second mode of operation 306 of the ECU 200, if the first memory bank 204 is configured to execute computer code 308a while the second memory bank 208 is being reprogrammed 308b, the method comprises executing 308a non-inhibited computer code of the set of at least one software module by the first memory bank 204 whilst the second memory bank 208 is being reprogrammed 308b. If the second memory bank 208 is configured to execute computer code 310b while the first memory bank 204 is being reprogrammed 310a, the method 300 comprises executing 310b non-inhibited computer code of the set of at least one software module by the second memory bank 208 whilst the first memory bank 204 is being reprogrammed 310a. In some examples, the method 300 may comprise performing a precondition test 312 to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank in the second mode of operation; and receiving the update mode signal 302 indicative of the update mode of operation of the ECU 200 in dependence on the vehicle passing the precondition test. In some examples, in dependence on receipt of the update mode signal indicative of the first mode of operation 304, the ECU 200 is configured to control network communication bandwidth available between the ECU 200 and an external communication device to allocate a first level of network communication bandwidth to receive the software update by the ECU 200. Similarly in dependence on receipt of the update mode signal indicative of the second mode of operation, the ECU 200 is configured to control network communication bandwidth available between ECU 200 and an external communication device to allocate a second level of network communication bandwidth to receive the software update by the ECU 200. The second level of network communication bandwidth is greater than the first level of network communication bandwidth. Thus, once the second mode of operation is indicated, the ECU 200 can be controlled to allocate more communication bandwidth to the software update process, to allow for quicker software updating. The communications bandwidth is not needed for software operation in the second mode as much as in the first mode since only a subset of software modules are enabled. For example, in the second mode of operation, a portion of available network communication bandwidth may be reserved for use by the ECU 200 for reprogramming software configured to reprogram software in the ECU 200, or for essential software configured to provide essential functionality by the ECU 200, for example to meet regulatory requirements. Following reprogramming of the second memory bank, the ECU 200 may be configured to execute the computer code stored in the second memory bank. In some examples, when operating in the second update mode, the ECU 200 may be configured to cause the reprogrammed software of the second memory bank to be written to the first memory bank following reprogramming of the second memory bank. This may be performed without necessarily performing a run test of the computer code including the software update installed in the ECU 200. In the second update mode, once the reprogramming has been performed in one memory bank, no run test may be needed, and the reprogrammed software can be written to the other memory bank. This process may take place when the second memory bank switches to become the “active” memory bank and the code in the second memory bank becomes active. This can be advantageous because the software update can be performed, and written to both memory banks, more quickly than if a run test is carried out. This may take place, for example, if the vehicle is in the manufacturing line, if the software update takes place while the vehicle is proximal to a user who is able to manually perform a software rollback in the event of an error in software updating, or if the software update is flagged as having a low importance to justify omitting the time taken to perform the run test. In some examples, when operating in the first update mode, the ECU 200 may be configured to perform a run test of the software update installed in the ECU 200. Following a run test of the software update installed in the ECU 200, and in dependence on receiving a pass indicator indicative of the software update executing correctly in the run test, the ECU 200 may cause the reprogrammed software of the second memory bank to be written to the first memory bank. In dependence on receiving a fail indicator indicative of the computer code executing incorrectly in the run test, the ECU 200 may cause the software stored in the first memory bank to be written to the second memory bank. This process may take place when the code in the first memory bank becomes active. Therefore, the software update which has not executed correctly is removed. Thus once the reprogramming has been performed in one memory bank, a test of the reprogrammed software can be made to ensure it runs as expected, before the updated software is committed to the other memory bank. This may be advantageous to ensure it runs as expected, before the updated software is committed to the other memory bank. This may take place, for example, if the software update takes place while the vehicle is remote from a user who is able to manually perform a software rollback in the event of an error in software updating, or if the software update is flagged as having a high importance to justify the time taken to perform the run test. The software update can be committed to the first memory bank once it has been verified that it has downloaded and installed correctly. In some examples, if the first memory bank 204 is configured to execute computer code while the second memory bank 208 is being reprogrammed, following reprogramming of the second memory bank 208, the ECU 200 may cause the reprogrammed software of the second memory bank 208 to be written to the first memory bank 204. For example, the updated software may be written from the second memory bank in which the software was received and installed in the first memory bank 204 so that both memory banks have the latest software version for use regardless of which memory bank is the currently active memory bank providing software functionality to operate the ECU 200. Similarly, if the second memory bank 208 is configured to execute computer code while the first memory bank 204 is being reprogrammed, following reprogramming of the first memory bank 204; the ECU 200 may cause the reprogrammed software of the first memory bank 204 to be written to the second memory bank 208. Thus once the reprogramming has been performed in one memory bank, the updated software can be committed to the other memory bank for use by either memory bank. Generally, software synchronisation may be performed whether a run test is performed or not. Once a software update is committed, rolled back or even cancelled by the active memory bank, the software in that memory bank may be copied to the inactive bank. This is useful to keep both memory banks of the ECU 200 with valid software. If the software in the active memory bank is corrupted for any reason, then the software from the inactive bank can be used. In this case, the active bank becomes inactive and the inactive bank becomes active, hence the software from the newly active memory bank will be executed. This helps to avoid ECU 200 failure and keep the vehicle running. The intention is to eventually execute the software update, so after committing the software update to the first memory bank it is copied to the second memory bank, and the active memory bank (first memory bank) which received the software update is switched to being the inactive bank and the inactive memory bank (second memory bank) is switched to being the active bank. By doing this, the freshly reprogrammed code (software update) become active and old copy becomes inactive. If a run test is performed and the test fails (i.e. the software update does not operate correctly), and if communication with the memory bank is possible, then a rollback may be performed to revert to a previous operational version of the software in that memory bank. If communication with the memory bank is not possible (for example due to the software update preventing communication) this may be taken as a determination that the software update is not operating correctly and a reset may be performed to rollback the software to revert to a previous operational version of the software in that memory bank. In this way a previous version of the operational software in the memory bank remains in use, and the freshly programmed software update which is not correct is not activated further. If the run test is performed and the software update operates correctly, or in the second operational mode where no run test is performed, a synchronisation step is performed where attempted updates to the software in the inactive memory bank are removed to keep the software in this memory bank synchronized with the software update in the active bank software. In some examples, in response to receiving the update mode signal indicative of an update mode of operation of the ECU 200, and prior to reprogramming of the second memory bank; a log of the current software running on the ECU 200 may be stored, and a current context of the ECU 200 may be stored. In this way, a log of software updates can be recorded to keep a check of what software has been used, and when, e.g. for diagnostic purposes. In some examples the ECU 200 (and vehicle) may be in the manufacturing line, and the ECU 200 may be configured to receive an update mode signal indicative of an update mode of operation of the ECU 200 which is the second mode of operation because the ECU 200 is in the manufacturing line. In the manufacturing line, the ECU 200 is able to operate using the uninhibited software modules and does not need to use those software modules inhibited in the second mode of operation, so this situation is well suited to allowing for software updates to be performed in the second mode of operation. In the manufacturing line, there may be a determination that the software update can be received in an uninterrupted transmission (i.e. the ECU 200 will not be switched off or required for operation out of the second mode during software receipt) so the second mode of operation may be used to receive and install the software update since the vehicle will not be in a state in which the software update may be interrupted, e.g. in the field being driven by a user and the user completed a drive cycle and switches the engine (and ECU) off. In some examples, further to the first mode of operation and the second mode of operation; the ECU 200 may be configured to receive a update mode signal indicative of a further mode of operation, further to the first mode of operation and the second mode of operation. If the update mode signal is indicative of a further mode of operation, the ECU 200 is configured to operate in a further update mode in which the ECU 200 is configured to perform a reprogramming of the second memory bank whilst at least a further subset of the set of at least one software module is inhibited; wherein the further subset of the set of at least one software module is different to the subset of the set of at least one software module inhibited in the second operation mode. Thus, there may be more than one mode for software reprogramming while a subset of software modules are inhibited. A different subset of software modules may be inhibited in the different second and further modes. An example may be of a vehicle being diagnostically tested in a workshop or garage, whereby some ECU 200 functionality may be provided by a non-inhibited subset of software modules of the ECU 200, but that functionality may be different to software functionality provided when the vehicle is in the manufacturing line, for example. In some examples, the ECU 200 may be configured to perform a precondition test to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank of the ECU 200 in the second mode of operation. The ECU 200 may be configured to receive the update mode signal indicative of the update mode of operation of the ECU 200 in dependence on the vehicle passing the precondition test. For example, if the vehicle is determined to be in the manufacturing line as a result of the precondition test this determination is used to initiate operation of the ECU 200 in the second update mode. As another example, if the vehicle is determined to be stationary, with doors locked, and an indication that the vehicle will not change out of this state before a period of time passes during which the software update can be received by the ECU 200, this may be taken as a determination that the precondition test has been passed and the ECU 200 can operate in the second update mode. Figure 4 illustrates an example method 400 of performing a software update using an ECU 200 as disclosed herein. An arrow pointing from a first to a second step indicates the steps are performed in order of the first step followed by the second step. It will be appreciated that some of the steps and some groups of steps shown are optional. Steps on the left of the figure are related to steps performed by the diagnostic tester (e.g. a person such as a technician). Steps in the centre of the figure are related to steps performed by the software update manager software. Steps on the right of the figure are related to steps performed by the target ECU 200. In step 402, network communication with the vehicle is initialised. In step 404, a precondition check for the second update mode (“pseudo foreground” programming mode) is initiated. In step 406, a check is made that the precondition check is passed, for example that the vehicle is stationary, the park brake is on, and the doors are locked, or for example that the vehicle is in the manufacturing line. Step 408 determines whether these conditions are met. If no, the method moves to step 514 and the programming sequence ends. If yes, the method moves to step 410 where the system is prepared for context switching; i.e. it has been determined that the vehicle is in the appropriate state and the ECU 200 can operate in the second mode of operation and receive and install a software update in the second “pseudo-foreground” mode of operation. In step 412, a check is made that context switching has taken place correctly. If no, the method moves to step 514 and the programming sequence ends. In some examples the precondition steps 408 to 412 may be omitted. These steps 408 to 412 may generally be considered to be performing a precondition test to determine the vehicle is in an operating state suitable for ECU 200 reprogramming in the second update mode (pseudo-foreground mode) of operation. If the result of step 412 is yes, the method moves to step 414 where a request is made to the vehicle to transition to a second update mode programming session. In step 416, a broadcast is made to transition to the second update mode programming session. In step 418, the transition to the second update mode programming session takes place. These steps 414 to 418 may broadly be considered to describe causing the ECU 200 to operate in the second update mode state. In step 420, a broadcast is made to switch context. In step 422, the context of the processes currently running on the CPU is saved. In step 424, context switching is performed. In step 426, a broadcast is made to suspend ECU applications (i.e. at least those applications which are to be inhibited). In step 428, those ECU applications to be inhibited are suspended. In step 430, a check is made that application suspension I inhibition has been successful. If no, then in step 432, the second update mode programming session is terminated, and in step 434, a message is transmitted to the tester to notify them that the second update mode programming session transition has failed, with a reason for failure. The method then moves to step 514 and the programming sequence ends. If in step 430, application suspension I inhibition is successful, the method moves to step 436. These steps 420 to 434 may broadly be considered to describe causing the ECU 200 to operate in the second update mode, and verifying that the ECU 200 is operating in the second update mode. In step 436, network communication is stopped, and the full (or at least an increased amount of) network bandwidth is made available for programming in the second update mode. In step 438, a broadcast is made of the suspension of transmission of functional network signals and services. In step 440, transmission of network signals and services is suspended. In step 442, a check is made whether the network transmission suspension has been successful. If no, then the method moves to step 444, wherein the second update mode programming session is terminated. Then in step 446, the tester is notified that there is a failure in the second update mode programming session transition, with a reason for the failure. The method then moves to step 514 and the programming sequence ends. If the result of step 442 is yes, then in step 448 the tester is notified that the second update mode programming session transition has been successful. Then in step 450, a request is made to the vehicle to start the second update mode programming. These steps 436 to 446 may broadly be considered to describe causing the ECU 200 to cease network transmission in preparation for a software update in the second update mode. In step 452, a broadcast is made to erase the memory of the memory bank which is to receive the software update. In step 454, the flash memory is erased on this memory bank. In step 456, a broadcast is made to download data. In step 458, the data blocks are downloaded to the newly erased memory bank. In step 460, a check is made whether the data blocks have completed downloading. If no, then the method returns to step 458. These steps 452 to 458 may broadly be considered to describe deleting data in the memory of the ECU 200 inactive bank and downloading a software update to the inactive bank. If the result of step 460 is yes, and the data blocks have thus completed downloading, the method moves to step 461 where a broadcast is made to check the validity of the application. In step 462, checking the validity of the application is initiated. In step 463 a check is made whether the application validation has been successful. If no, the message moves to step 466 where a broadcast is made to perform synchronisation. In step 468, synchronisation with the software image from the non-erased memory bank is performed. The method then returns to step 470 where the tester is notified that second update mode programming has failed, with a reason for the failure. The method then moves to step 514 where the programming sequence ends. If the result of the check of application validity in step 463 is that the application validation has been successful, then the method moves to step 464 where the tester is notified that the application validity on the newly updated memory bank has been successful. These steps 461 to 464 may broadly be considered to describe checking that the downloaded data is valid. The method then moves to step 465 where a request is made to the vehicle to switch memory banks. In step 472 a broadcast is made to switch memory banks. In step 474 the bank switch is initiated. In step 476 a check is made whether the banks have been switched successfully. If no, the method returns to step 474 to switch the banks. If yes, then the method moves to step 478 where the tester is notified that bank switching has been completed. Then the method moves to step 480, where a request is made to the vehicle to exit the second update mode. These steps 465 to 480 may broadly be considered to describe switching memory banks to change the active bank to be the inactive bank and change the inactive bank to be the active bank following software updating. In step 482, network communications are resumed, and the full network bandwidth is made available for the application. In step 483, a check is made whether the software update is being performed in a “remote” scenario, for example receiving software over-the-air, or whether the software update is being performed in a “proximity” scenario, whereby a user such as a technician is with the vehicle. If the update is remote, the method moves to step 484 as a trial run may provide increased robustness in the absence of a user with the vehicle in the event of an error in updating the software. In step 484, a broadcast is made to transition to the trial run mode. In step 486, the transition to the trial run mode is performed. In step 488, a broadcast is made to execute the trial run. In step 490, the trial run is initiated, and the application test and diagnostic part number checks initiated. In step 492, a check is made whether the trial run has been successful. If yes, then in step 494 the tester is notified that the trial run has been successful, and the method moves to step 496. If the update is performed with a proximal user located with the vehicle, the trial run steps may be omitted since, in the event of an error, the user is with the vehicle for a manual system recovery, and the process moves to step 496. In step 496, a request to commit the updated software is made. In step 498 a broadcast is made to request the software be committed and in step 502 the software is committed. If no, then in step 504 the tester is notified that the trial run has failed, and in step 506 a request to rollback the software to the earlier version is made. In step 508 a broadcast is made to “sync” (synchronise) the software and in step 510 a sync is performed with the software image from the non-updated bank to rollback the software to the version in effect before the attempt to update. In step 512 following either committing the new software to memory or rollback to the previous software before the attempted update, a broadcast is made to reset the ECU 200 and transition to the default operation mode, then in step 514 the programming sequence ends. These steps 482 to 512 may broadly be considered to describe software rollback if the trial run fails and committing the software if the trial run is successful. Of course in other examples there may be different criteria according to which a run test is performed, or not, as discussed above. Any method disclosed herein may be performed by computer readable instructions which, when executed by 5 an electronic control unit as disclosed herein, are arranged to perform the method. There may be a non-transitory, computer-readable storage medium storing instructions thereon that, when executed by an electronic control unit disclosed herein, causes the electronic control unit to carry out any method disclosed herein. 10 In some examples as shown in Figure 5, there is provided a system 500 for a vehicle as in Figure 1, comprising any ECU 200 described herein, and a vehicle module 502 configured to be controlled by the set of at least one software module executed by the ECU 200. The ECU 200 can control the vehicle module 502 and is able to receive and install software updates in an improved way as described above. 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. An electronic control unit of a vehicle, the electronic control unit comprising a first memory bank and a second memory bank, wherein the electronic control unit is configurable to execute computer code stored in the first memory bank while the second memory bank is being reprogrammed, said computer code comprising a set of at least one software module executable to provide runtime functionality of the electronic control unit;the electronic control unit configured to, whilst executing the computer code stored in the first memory bank:receive an update mode signal indicative of an update mode of operation of the electronic control unit; wherein:if the update mode signal is indicative of a first mode of operation, the electronic control unit is configured to operate in a first update mode in which the electronic control unit is configured to perform the reprogramming of the second memory bank whilst the set of at least one software module is enabled; andif the update mode signal is indicative of a second mode of operation, the electronic control unit is configured to operate in a second update mode in which the electronic control unit is configured to perform the reprogramming of the second memory bank whilst at least a subset of the set of at least one software module is inhibited.

2. The electronic control unit of claim 1, wherein, in the second mode of operation, the electronic control unit is configured to execute non-inhibited computer code of the set of at least one software module whilst the second memory bank is being reprogrammed.

3. The electronic control unit of any preceding claim, configured to:in dependence on receipt of the update mode signal indicative of the first mode of operation, control network communication bandwidth available between the electronic control unit and an external communication device to allocate a first level of network communication bandwidth to receive the software update by the electronic control unit; andin dependence on receipt of the update mode signal indicative of the second mode of operation, control network communication bandwidth available between the electronic control unit and an external communication device to allocate a second level of network communication bandwidth to receive the software update by the electronic control unit;wherein the second level of network communication bandwidth is greater than the first level of network communication bandwidth.

4. The electronic control unit of any preceding claim, configured to, when operating in the second update mode:following reprogramming of the second memory bank; cause the reprogrammed software of the second memory bank to be written to the first memory bank.

5. The electronic control unit of any preceding claim, configured to:when operating in the second update mode:perform a run test of the software update installed in the electronic control unit;in dependence on receiving a pass indicator indicative of the software update executing correctly in the run test, cause the reprogrammed software of the second memory bank to be written to the first memory bank; andin dependence on receiving a fail indicator indicative of the computer code executing incorrectly in the run test, cause the software stored in the first memory bank to be written to the second memory bank.

6. The electronic control unit of any preceding claim, configured to:in response to receiving the update mode signal indicative of an update mode of operation of the electronic control unit, and prior to reprogramming of the second memory bank;store a log of the current software running on the electronic control unit and a current context of the electronic control unit.

7. The electronic control unit of any preceding claim, configured to, following reprogramming of the second memory bank, execute the computer code stored in the second memory bank.

8. The electronic control unit of any preceding claim, wherein, further to the first mode of operation and the second mode of operation;if the update mode signal is indicative of a further mode of operation, the electronic control unit is configured to operate in a further update mode in which the electronic control unit is configured to perform a reprogramming of the second memory bank whilst at least a further subset of the set of at least one software module is inhibited;wherein the further subset of the set of at least one software module is different to the subset of the set of at least one software module inhibited in the second operation mode.

9. The electronic control unit of any preceding claim, configured to:perform a precondition test to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank of the electronic control unit in the second mode of operation; andreceive the update mode signal indicative of the update mode of operation of the electronic control unit in dependence on the vehicle passing the precondition test.

10. A system for a vehicle comprising:the electronic control unit of any of claims 1 to 9; anda vehicle module configured to be controlled by the set of at least one software module executed by the electronic control unit.

11. A vehicle comprising the system of claim 10, or the electronic control unit of any of claims 1 to 9.

12. A method of operation of an electronic control unit of a vehicle comprising a first memory bank anda second memory bank, wherein the electronic control unit is configurable to execute computer code stored inthe first memory bank while the second memory bank is being reprogrammed, said computer code comprising a set of at least one software module executable to provide runtime functionality of the electronic control unit;the method comprising:receiving an update mode signal indicative of an update mode of operation of the electronic control unit; wherein:if the update mode signal indicative of a first mode of operation, the electronic control unit operates in a first update mode in which the electronic control unit is configured to perform reprogramming of the second memory bank whilst the set of at least one software module is enabled; andif the update mode signal indicative of a second mode of operation, the electronic control unit operates in a second update mode in which the electronic control unit is configured to perform reprogramming of the second memory bank whilst at least a subset of the set of at least one software module is inhibited.

13. The method of claim 12, comprising:receiving the update mode signal indicative of the second mode of operation of the electronic control unit; andexecuting non-inhibited computer code of the set of at least one software module by the first memory bank whilst reprogramming the second memory bank.

14. The method of claim 12 or claim 13, comprising:performing a precondition test to determine an operating state of the vehicle is suitable for reprogramming of the second memory bank in the second mode of operation; andreceiving the update mode signal indicative of the update mode of operation of the electronic control unit in dependence on the vehicle passing the precondition test.

15. Computer readable instructions which,when executed by an electronic control unit according to any of claims 1 to 10, are arranged to perform a method according to any of claims 12 to 14.

Images