Control system with a distributed service-oriented architecture

Abstract

A control system (10) having a distributed hierarchical architecture, the control system (10) being configured to control a vehicle and comprising: a plurality of nodes (12), each node (12) hosting one or more services (18) and a respective node agent (22); a communication bus providing communication between nodes (12); and a system agent (24) hosted on one of the plurality of nodes (12), the system agent (24) configured to monitor a lifecycle state of the system (10); each node agent (22) configured to transmit data associated with a state of its respective node (12) and a respective state of the or each service (18) hosted on its respective node (12) to the system agent (24), whereby the system agent (24) can monitor the lifecycle state of the system (10); and each node (12) relating to a respective subsystem of the vehicle (46).

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a control system with a distributed service-oriented architecture. In particular, but not exclusively, the disclosure relates to a distributed service-oriented architecture for optimized runtime lifecycle management for a vehicle control system. Aspects of the invention relate to a control system, a non-transitory computer-readable storage medium, and a vehicle. STATE OF THE ART

[0002] Service-oriented architectures (SOA) are commonly used in a variety of environments, especially in business workflow management through large, distributed IT structures. Cloud-based web service environments are also typically based on SOA principles.

[0003] An SOA facilitates the interaction of software elements in a manner known as "loosely coupled," where software elements can be managed, installed, updated, and evolved independently. This approach offers several advantages: • the ability to update systems in real time without stopping any essential application; • the ability to manage software procurement in an independent and competitive manner; • improved cost-effectiveness for integration and testing; • the ability to create new functionality by combining the functions of existing software elements; and • reduced complexity of system management due to the ability to treat software elements as well-defined units with limited dependencies.

[0004] In this context, a general goal is to apply SOA principles to the field of embedded systems, and in particular to automotive control systems. Currently, such systems comprise multiple processing units known as ECUs (electronic control units), interconnected by various network technologies, for example, using the CAN bus protocol. The integration of such systems is achieved by defining messages in the networks between the ECUs.

[0005] In a vehicle environment, ECUs are designed to control various subsystems of the vehicle. Subsystems including, for example, a vehicle engine, a transmission, a cruise control system, an anti-lock braking system (ABS), and many others typically each have dedicated nodes. A modern vehicle may have 70 or more such nodes; and this number continues to rise in conjunction with a trend toward vehicle electrification.

[0006] This approach is now reaching the limits of its ability to handle new software-based functions targeted at modern vehicles. The automotive industry, in particular, faces similar integration and complexity challenges to those that led to the development of the SOA approach in the IT industry; hence the interest in applying SOA to this embedded domain.

[0007] When applying SOA, individual vehicle functions are coded as services and integrated with appropriate SOA middleware. For example, the ABS control could be coded as a service and executed in the SOA with high security and priority. This way, the ABS could be individually monitored, updated, or tested. The expert reader will understand that this approach is difficult to implement in current automotive architecture.

[0008] One reason for this is the need for very precise, real-time control of the processing state across automotive systems. This is necessary for real-time and safety aspects of the vehicle system and also enables control of total energy consumption at every single point in time. The latter is particularly important for electric and hybrid vehicles, but is also relevant for vehicles with internal combustion engines.

[0009] Currently, in an automotive context, each subsystem of a vehicle control system is developed independently and on different timeframes. Thus, runtime lifecycle management, in historical terms, involves the implementation of a set of global rules that define how the system components behave and interact with each other at a fairly simple and coarse-grained level. Within this system, the way each individual node is configured and implemented into the system varies considerably. For example, it is not uncommon for a node to have its external visibility restricted to the extent that only the state of the node as a whole is available; information about the states of internal elements of the hosted software is not available at the system level. This limits the degree of external control that can be applied to the node.

[0010] While the historical approach ensures the correct functionality of the entire control system because the interaction between system components is inflexible and tightly bounded, the level of control that can be applied to the system as a whole is limited. This can increase the burden on developers when debugging the system, as each node must be individually debugged. Subsequently, during runtime, a lack of external visibility into the states of components within each node can create inefficiencies within the system and also impact the way errors are detected and handled.

[0011] US 2012 / 0 246 517 A1 discloses a first virtual I / O server (VIOS) providing a cluster-aware operating system (CA-OS) executing on a processor resource of the first VIOS to register the first VIOS within a VIOS cluster.

[0012] US 2013 / 0 211 546 A1 provides a cloud-enabled smart device that facilitates the automatic configuration and integration of the device into an automation system. Once installed in the automation system, the smart device determines its geographic location, identifies other devices in the system, and determines its role within the system.

[0013] US 2016 / 0 085 606 A1 discloses one or more techniques and / or systems provided for the replication of cluster configuration information, the management of cluster-wide service agents and / or for cluster-wide failure detection.

[0014] The embodiments of the present invention aim to overcome at least some of the disadvantages associated with the prior art. SUMMARY OF THE INVENTION

[0015] Aspects and embodiments of the invention provide a control system, a non-transitory computer-readable storage medium, and a vehicle according to the appended claims.

[0016] The above-mentioned disadvantages are at least partially solved by a control system according to claim 1, a vehicle according to claim 13 and / or a non-transitory computer-readable storage medium according to claim 14.

[0017] According to one aspect of the present invention, a control system having a distributed hierarchical architecture is provided. The system comprises a plurality of nodes, each node hosting one or more services and a respective node agent. The system further comprises a communication bus providing communication between the nodes and a system agent hosted on one of the plurality of nodes, the system agent configured to monitor a lifecycle state of the system. Each node agent is configured to transmit data to the system agent related to a state of its respective node and a respective state of the or each service hosted on its respective node, thereby enabling the system agent to monitor the lifecycle state of the system.

[0018] By receiving data indicating the state of each node and each service hosted on the node, the system agent maintains an overview of the lifecycle state of the system as a whole. This allows the system to consider the lifecycle state before issuing control commands such as state change requests, providing a coherent system in which the operation of individual software components can be controlled in accordance with the states of other components elsewhere within the system. For example, non-essential or inactive software components residing on one node can be hibernated to allow components on other nodes to reallocate resources for more efficient operation.

[0019] Each node agent can be configured to propagate control commands received from the system agent to services hosted on its respective node, thus maintaining the hierarchical nature of the system architecture.

[0020] In some embodiments, each node hosts one or more partitions, where each partition may host one or more services and a corresponding partition agent. In such embodiments, each partition agent may be configured to transmit data related to a state of its respective partition and a state of each service hosted on its respective partition to its respective node agent. Each partition agent may also be configured to propagate control commands received from its respective node agent to services hosted on its respective node.

[0021] When using partitions, configuring partition agents to report their states to their respective node agents enables the integration of the partitions into the system architecture hierarchy in a way that allows the system agent to maintain complete knowledge of the system state.

[0022] The system agent may include the node agent of the node hosting the system agent. For example, a single deployment on a node may include the functionality of both the system agent and the node agent.

[0023] The control system may include at least one authorized agent configured to issue control commands to one or more of the services hosted on the plurality of nodes. In such embodiments, the or each authorized agent is configured to issue control commands depending on the data collected by the system agent from the node agents. The at least one authorized agent may include one or more of the following groups: a user; a watchdog; and a policy handler. The inclusion of authorized agents increases the flexibility in controlling the system, for example, to enable user interaction and control.

[0024] The control system may have a service-oriented architecture, which, as noted above, provides several advantages, including real-time updating, reduced system complexity, and the ability to independently procure, develop, and test software components.

[0025] In some embodiments, for example, when a state machine is used to control the system, the control commands include state change requests.

[0026] The control system may be configured to control a vehicle, in which case each node may refer to a respective subsystem of the vehicle.

[0027] According to another aspect of the invention, a vehicle is provided comprising the control system of the preceding aspect.

[0028] According to a further aspect of the invention, a non-transitory computer-readable storage medium is provided storing executable computer program instructions arranged to implement the control system as described above.

[0029] Within the scope of this application, it is expressly intended that the various aspects, embodiments, examples, and alternatives presented in the preceding paragraphs, in the claims, and / or in the following description and drawings, and in particular their individual features, may be considered independently of one another or in any combination. This means that all embodiments and / or features of any embodiment may be combined in any manner and / or combination, provided these features are not incompatible.The applicant reserves the right to amend any originally filed claim or to file any new claim accordingly, including the right to amend any originally filed claim to depend on and / or incorporate any feature of any other claim even though it has not been so claimed before.

[0030] For the purposes of this disclosure, it is understood that the control system described herein may each comprise a control unit or a computing device having one or more electronic processors. A vehicle and / or a system thereof may comprise a single control unit or electronic controller, or alternatively, different functions of the controller(s) may be implemented or hosted in different control units or controllers. As used in this document, the term "control unit" is to be understood to include both a single control unit or controller and a plurality of control units or controllers that cooperate to provide the required control functionality.The term "module" is intended to include either a single computational module performing a single or multiple functions, or a plurality of computational modules performing separable functions. A set of instructions could be provided which, when executed, causes the controller(s) or control unit(s) or module(s) to perform the control techniques described herein (including the method(s) described below). The instruction set may be embedded in one or more electronic processors, or alternatively, the instruction set could be provided as software to be executed by one or more electronic processors.For example, a first control device may be implemented in software executing on one or more electronic processors, and one or more other control devices may also be implemented in software executing on one or more electronic processors, optionally the same processor(s) as the first control device. However, it should be understood that other arrangements are equally useful, and accordingly, the present invention is not intended to be limited to any particular arrangement. In any event, the instruction set described above may be embedded in a computer-readable storage medium (e.g., a non-volatile storage medium) that may include a mechanism for storing information in a form readable by a machine or electronic processor / computing device, including, but not limited to: a magnetic storage medium (e.g.,floppy disk); 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 and EEPROM); flash memory; or electrical or other types of media for storing such information / instructions. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Fig. 1 is a schematic diagram of a service-oriented architecture according to an embodiment of the invention; Fig. 2 a schematic diagram showing a hierarchy between components of the service-oriented architecture of Fig. 1 shows; Fig. 3 a flowchart showing a sequence of states used by a service of the service-oriented architecture of Fig. 1 be accepted; and Fig. 4 is a schematic diagram showing a vehicle implementing a control system with the service-oriented architecture of Fig. 1 includes. DETAILED DESCRIPTION

[0032] Fig. 1 shows in schematic form an instance of a distributed service-oriented high-level architecture for a vehicle control system 10 according to an embodiment of the invention.

[0033] The Fig. The system 10 shown in Figure 1 includes two nodes 12, each of which corresponds to an individual ECU controlling a respective vehicle subsystem. For simplicity, only two nodes 12 are shown; however, it should be understood that in practice, a vehicle control system typically includes many more nodes 12, for example, 70 or more, as mentioned above.

[0034] Each node 12 has two or more partitions 14, where a partition 14 is a subdivision of the available runtime memory space of a node 12 in a manner that prevents unwanted or dangerous interference between the partitions 14 at runtime. Within the approach described below, each partition 14 is managed by a respective partition agent 16. Each partition 14 hosts one or more services 18, where each service 18 is configured to perform a function relevant to vehicle behavior.

[0035] The partition agents 16 manage the lifecycle of software running within their respective partitions 14. For example, the partition agents 16 monitor active processes in their respective partitions 14, and in particular, monitor the state of each service 18 hosted on the partition. Note that monitoring the states of each service 18 involves receiving an update from the service 18 itself. The final knowledge of the state of a service 18 rests with the service 18 itself and is not determined indirectly to avoid errors.

[0036] Each partition agent 16 also implements control of the services 18 hosted on its partition 14, for example, to issue a state change request to change the state of a service 18 in response to a command issued by other system components.

[0037] For the sake of completeness, it should be noted that the SOA infrastructure enables each service 18 to communicate with other services 18, wherever they are located within the system 10. This infrastructure is in Fig. 1 is represented by a communication bus 20.

[0038] Each node 12 also includes a node agent 22, which is a software component arranged to manage the lifecycle of its respective node 12 and is hosted in one of the node's partitions 14. Each node agent 22 is configured to interface with the partition agents 16 so that it can: (i) track the state of the partitions 14; and (ii) issue state change requests to the partition agents 16.

[0039] Within the system 10, a node agent 22 is designated as system agent 24. The system agent 24 manages the overall lifecycle of the entire system 10 by interfacing with the other node agents 22 to: (i) track the states of the nodes 12; and (ii) issue state change requests to the nodes 12. The system agent 24 is also responsible for the node 12 on which it is hosted and, in this regard, provides the functionality of a node agent 22 by managing the lifecycle of that node 12 in the same manner as the other node agents 22 manage their respective nodes 12.

[0040] In practice, the functionality of both the system agent 24 and the node agent 22 may comprise a single deployment on the respective node 12, or separate deployments may be used to individually deploy the node agent functionality and the system agent functionality. In either case, constructs representing a node agent 22 and a system agent 24 on the relevant node 12 will be visible to other software components for interfacing purposes.

[0041] It is obvious at this stage that the architecture of this embodiment defines a hierarchy between the components of the vehicle control system 10. This hierarchy is shown in Fig. 2, where it can be seen that the hierarchy is defined in ascending order as follows: Services 18; Partition Agents 16; Node Agents 22; System Agent 24. With respect to parent-child relationships between entities, the services 18 act as child-to-parent partition agents 16, which in turn act as child-to-parent node agents 22, which in turn act as child-to-parent system agents 24.

[0042] As a result, services 18 only have access to their own states, while partition agents 16 have access to the state of each service 18 hosted on a specific partition 14. Node agents 22 monitor the states of partitions 14 and also the state of the hardware associated with node 12. At the top of the hierarchy, system agent 24 has access to the states of all system components.

[0043] The hierarchical structure of the control system architecture provides complete visibility into all components of system 10 in a modular and therefore relatively easy-to-manage manner. The modular structure also facilitates the integration of additional nodes 12 into system 10, since the new node 12 only needs to take the same form as the others, including the incorporation of a node agent 22, and can integrate seamlessly into system 10. This is in stark contrast to known systems in which many system components are not visible at the system level and therefore cannot be managed at that level, and in which adding new components is complex.

[0044] The system 10 includes components that are authorized agents capable of requesting state changes or state updates for a service 18, a partition 14, a node 12, or the system 10 as a whole. Authorized agents may include, for example: users, i.e., employees operating the system 10; watchdogs; and policy handlers. The system agent is also an authorized agent. All requests generated by such authorized agents are sent directly to the relevant component of the system 10, as described above. The authorized agents have access to knowledge of the system state and consider this information when generating requests. This ensures that such requests are handled in accordance with the rest of the system 10 and that all requests can be standardized throughout the system 10.

[0045] As is common with lifecycle management in the computer industry, explicit state machines are provided to provide the necessary control logic in this environment.

[0046] Each element of system 10 goes through a series of "states," namely, a sequence of operating modes. For example, a typical sequence of states for a service 18 might include: Initializing; Ready; Starting; Active; Stopping; Ready; Shutting down; Inactive. Each state defines specific semantics that indicate what the service 18 does in that state and the possible transitions to other states. This approach also applies to the partitions 14, the nodes 12, and the system 10.

[0047] Following the hierarchy described above, it should be noted that the states of the partitions 14, the nodes 12, and the system 10 are largely determined by the states of elements located lower in the hierarchy. For example, the state of a partition 14 is largely determined by the states of the services 18 within that partition. Therefore, it can be assumed that the logic of the state machines closely follows the logic of the control hierarchy provided by the agents.

[0048] By standardizing the system 10 in this way, it facilitates the control of the overall state of the vehicle and the monitoring of activities and energy consumption at any given time. Furthermore, the ability to focus on individual elements or collections of elements in a standardized manner facilitates the development, integration, and testing of the vehicle.

[0049] Fig. Figure 3 is a state machine diagram illustrating runtime lifecycle states for the vehicle control system 10 at a system level. Note that transitions between states are triggered by state change requests, generally generated by the system agent 24 or other authorized agents, as mentioned above. For each state transition, changes are propagated from child to parent according to the hierarchy described above.

[0050] In summary, the following sequence would result in the case of starting a system 10: 1. The system agent 24 initiates a boot process by sending an appropriate message to each node agent 22. 2. Each node agent 22 causes the partition agents 16 to start up for each of the partitions 14 that are required to start on its node 12. 3. Each partition agent 16 starts the services 18 required to start within the partition 14 it controls. 4. Each service 18 notifies the partition agent 16 of a successful start upon startup. 5. Each partition agent 16 notifies its node agent 22 of the successful start-up of all required services 18 on its respective partition. 6. Each node agent 22 notifies the system agent 24 when all of its partitions 14 have informed it of a successful startup.

[0051] This sequence is described in more detail below.

[0052] In an initial state 30, which is on the far left in Fig. As shown in Figure 3, all system components, including all nodes 12 and partitions 14, are inactive. A state change request to initialize the system 10 triggers a state change that places the system 10 in the "initialize" state 32. Typically, such a state change request is generated for a vehicle control system 10 upon engine start.

[0053] If any required components cannot be initialized, for example, a partition 14 of one of the nodes 12 with essential functionality, an error is generated and forwarded to a relevant system component, which executes the action defined by a system integrator. For example, if the error is severe, the system integrator may cause the system 10 to shut down. The system agent 24 accomplishes this by generating a state change request to transition the system 10 to a "shutdown" state 34, which completes once all components are inactive. These actions are monitored by the system agent 24 via the relevant node agent 22 and the partition agent 16 to maintain a real-time overview of the state of the system 10.

[0054] As an alternative to shutting down the entire system 10, the system agent 24 may be configured to move the system 10 into a preconfigured backup state for certain conditions when certain lifecycle failures occur. In particular, this refers to a "limp-run" mode in which the system 10 must be shut down due to a fault condition, but the system 10 has the option to work around the fault condition by managing system resources to ensure that essential services 18 remain available at the expense of non-essential services 18.This is one area where the architecture of this embodiment offers a significant improvement over known vehicle control systems, as the ability to centrally control any component of system 10 allows for the temporary shutdown of non-essential services 18, thereby freeing system resources for essential services 18 until system 10 is successfully shut down. In known systems, limp-home modes are much more difficult to manage.

[0055] Back to the state machine diagram of Fig. 3: If no error occurs during initialization, the system agent 24 generates another state change request after initialization is complete to transition the system components to the "Ready" state 36, which indicates that the system 10 has initialized and is waiting for further instructions. From this state, the system 10 can enter either an activity cycle or the shutdown state 34.

[0056] It should be noted that the system control is designed at a granular level, and each component can transition to its "ready" state 36 individually and as needed, and not necessarily at the same time. It should also be noted that one or more "ready" states 36 are defined at a system level. For each of these, a specific set of system components is initialized while others remain inactive. For example, in one configuration, the "ready" state 36 can be defined as two nodes 12 being initialized while another remains inactive. A successful transition to the "ready" state 36 for this example therefore only requires initializing the two nodes 12 required for this configuration.

[0057] Typically, the system 10 enters an activity cycle so that some or all of the services 18 of the system 10 can become active to affect the control of the vehicle hardware. This causes the system 10 to enter a "start" state 38, during which the required services 18 are started. If all of the required services 18 start successfully, the system 10 enters an "active" state 40. If only some of the required services 18 start successfully, the system 10 enters a "partially active" state 42, in which those services 18 that were successfully started can be executed while fault diagnostics are performed to determine which services 18 did not start and the course of action to be taken. Once all services 18 are loaded, the system 10 enters the "active" state 40 and continues.

[0058] When the services 18 are no longer required, for example, when the vehicle is turned off, the system 10 enters a "stopping" state 44, in which all services 18 are stopped. Once this is completed, the system 10 returns to the "ready" state 36, from which the system 10 can either return to an activity cycle or, in the case of the vehicle being turned off, to the "shutting down" state 34 to render all services 18, partitions 14, and nodes 12 inactive.

[0059] It should be noted that the above-mentioned state machine refers only to core functions of the vehicle control system 10. Some nodes 12 control hardware that is used intermittently, for example, a cruise control system, and thus these nodes 12 are individually controlled outside, but in accordance with the Fig. 3, the system agent 24 is activated and deactivated under the control of the relevant authorized agents through the control hierarchy and taking into account the real-time system state. The system agent 24 therefore enables coherent overall control of the system 10 at all times. This coherent system approach has the advantage that all components of the system 10 are controlled using standardized semantics and can recognize similar states.

[0060] The state machine diagram of Fig. 3 therefore provides an overview of the system life cycle and includes two of the most difficult operations to manage in known systems: starting or “booting” the system; and shutting down. As in Fig. As illustrated in Figure 3, the architecture of this embodiment ensures that all system components remain synchronized, thus avoiding some components being in conflicting states with others. This improves the management and control of boot and shutdown sequences, increasing the robustness of system 10, enabling more efficient management of system resources, and improving the system 10's ability to detect and handle faults.

[0061] Several specific areas in which the architecture described above offers advantages will now be described to assist in understanding the functionality of System 10.

[0062] A first example of the benefits of the increased control flexibility offered by the architecture of this embodiment is the management of energy consumption throughout the system 10. The system agent 24 can monitor energy consumption by the various system components and initiate energy management actions in situations where energy consumption needs to be reduced. Such situations may include, for example, the system 10 demanding too much energy from a source relative to the capacity of the energy source, or there is a risk of damage or overheating to system components.

[0063] When the hierarchical life cycle is implemented, the system agent 24 can manipulate energy consumption either at a coarse level, e.g., by shutting down an entire node 12, or at a fine level, e.g., by stopping a service 18 or a set of services 18. In this way, essential services 18 continue to run while non-essential services 18 are stopped, without affecting the performance of the system 10.

[0064] A second advantageous area concerns fault tolerance, where the ability to replace a faulty function with an alternative function is often desirable. In known systems, alternative functions are provided using parallel dual nodes 12, thereby generating redundancy in the system. While such solutions are likely to remain necessary for critical real-time functions, for other functions the present architecture provides the ability to (i) stop and restart a faulty function; or (ii) start a replacement function, optionally on a different node 12, without having to restart the entire system 10 or even a node 12.This is because, by monitoring the status of all system components, the system agent 24 provides information that precisely identifies the type of problems occurring within the system 10 and also enables coordination between system components to provide a targeted response. These alternative solutions therefore offer the possibility of reducing the hardware requirements for certain functions.

[0065] The hierarchical lifecycle described above enables this type of error correction to be achieved with fine resolution, resulting in reduced disruption to the overall system 10 while such operations are performed. This ensures that systems according to embodiments of the invention have increased resilience and fault tolerance compared to known systems.

[0066] As a final example, it is noted that there is a growing demand for systems that can be remotely updated and diagnosed; for example, for large system deployments or for systems that are difficult to access. The hierarchical lifecycle architecture supports an important improvement over current solutions for this requirement. In particular, the ability to disable targeted system components independently of the rest of the system 10 allows a subset of system features to continue functioning while another subset is being diagnosed or updated.

[0067] How Fig. 4, the invention also extends to a vehicle 46 comprising the control system 10 described above.

[0068] Numerous modifications may be made to the foregoing examples without departing from the scope of the present invention as defined in the appended claims. For example, while embodiments of the control systems have been described above in the context of an automotive environment, control systems of other embodiments may be applicable to many other types of environments, and in particular to applications where power management is important, such as aerospace or defense applications where battery-powered systems operate in harsh environments, or to applications where high reliability and stability are advantageous.

Claims

A control system (10) having a distributed hierarchical architecture, the control system (10) being configured to control a vehicle and comprising: a plurality of nodes (12), each node (12) hosting one or more services (18) and a respective node agent (22); a communication bus providing communication between nodes (12); and a system agent (24) hosted on one of the plurality of nodes (12), the system agent (24) being configured to monitor a lifecycle state of the system (10); each node agent (22) being configured to transmit data related to a state of its respective node (12) and a respective state of the or each service (18) hosted on its respective node (12) to the system agent (24), whereby the system agent (24) can monitor the lifecycle state of the system (10).and wherein each node (12) relates to a respective subsystem of the vehicle (46); Control system (10) according to claim 1, wherein each node (12) hosts one or more partitions (14). The control system (10) of claim 2, wherein each partition (14) hosts one or more services (18) and a respective partition agent (16); wherein, optionally, each partition agent (16) is configured to transmit data relating to a state of its respective partition (14) and a state of each service (18) hosted on its respective partition (14) to its respective node agent (22); wherein, further optionally, each partition agent (16) is configured to transmit control commands received from its respective node agent (22) to services (18) hosted on its respective node (12). Control system (10) according to one of the preceding claims, wherein the system agent (24) comprises the node agent (22) of the node (12) on which the system agent (24) is hosted. A control system (10) according to any one of the preceding claims, comprising at least one authorized agent configured to issue control commands to one or more of the services (18) hosted on the plurality of nodes (12), wherein the or each authorized agent is configured to issue control commands in dependence on the data acquired by the system agent (24) from the node agents (22). Control system (10) according to one of the preceding claims, wherein the at least one authorized agent comprises one or more elements of the group comprising: a user; a watchdog; and a policy handler. Control system (10) according to one of the preceding claims, which has a service-oriented architecture. A control system (10) according to any one of the preceding claims, wherein each node agent (22) is configured to propagate control commands received from the system agent (24) to services (18) hosted on its respective node (12). A control system (10) according to any one of the preceding claims, wherein each node agent (22) is configured to transmit energy consumption data and wherein the system (10) is arranged to control the state of the vehicle (46) and monitor activities and energy consumption. Control system (10) according to one of the preceding claims, wherein the plurality of nodes (12), services (18) and node agents (22) comprise components of the system (10) and wherein - if a component cannot be initialized - the system agent (24) is arranged to generate a state change request to transfer the system (10) to a switched off state. Control system (10) according to one of claims 1 to 9, wherein the plurality of nodes (12), services (18) and node agents (22) comprise components of the system (10) and wherein - if a component cannot be initialized - the system agent (24) is arranged to transfer the system (10) to a preconfigured backup state. Control system (10) according to one of the preceding claims, wherein the plurality of nodes (12), services (18) and node agents (22) comprise components of the system (10) and the system agent (24) is arranged to monitor the status of all system components so that in the event of a fault, the system (10) is arranged to either stop and restart a faulty function or to start a replacement function, optionally on another node (12). Vehicle (46) comprising the control system (10) according to any one of the preceding claims. A non-transient computer-readable storage medium storing executable computer program instructions for implementing the control system (10) of any one of claims 1 to 12.

Images