Method and control device for providing a function in a vehicle

Abstract

Methods and control devices for providing functionality in a vehicle. The present invention relates to a method for providing functionality in a vehicle, particularly a software-defined vehicle (SDV), wherein at least two software modules, particularly two software agents, are executed on a control device, characterized in that the at least two software modules are distinct from each other, and each of the at least two software modules provides the functionality through a separate communication interface.

Description

Technical Field

[0001] The present invention relates to a method and control apparatus for providing functionality in a vehicle, particularly a software-defined vehicle (SDV). Background Technology

[0002] Modern vehicles, especially software-defined vehicles (SDVs), are characterized by increasingly interconnected and complex software. This presents new challenges to vehicle security as the attack surface of cyberattacks continues to expand. A promising vehicle security solution is Zero Trust Architecture (ZTA), based on the principle of "Never trust, always verify." With ZTA, any device, even those located within the network boundary, is considered potentially insecure, and every access request must be authenticated and authorized.

[0003] Traditional ZTA implementations in enterprise IT rely on massive redundancy to ensure service availability. The failure of a single server or virtual machine is compensated for by other identical systems. However, this approach is often unsuitable for safety-critical applications in vehicles due to limited resources (computing power, memory, energy) and the high costs associated with redundancy.

[0004] WO 2024 / 100007 A1 discloses a method for monitoring the interface between software applications and control devices in a vehicle. In this method, a central monitoring unit checks service requests and sets parameters according to rules, then forwards them to the appropriate control devices. This method primarily aims to improve security by blocking disallowed requests. It focuses on filtering communication flows and is based on a centralized architecture. Summary of the Invention

[0005] Against this backdrop, the methods described herein provide a way to deliver functionality in vehicles, particularly in software-defined vehicles (SDVs). SDVs are characterized by high connectivity and software-based functionality, which increases system complexity and associated security risks. This invention addresses these challenges through a novel approach based on the use of multiple software modules.

[0006] The core of this method lies in running at least two software modules on a control device. In this context, the term "software module" refers to a program component that performs a specific task. "Control device" refers to an electronic control unit in a vehicle responsible for a specific function. Alternatively, this application also uses the term "software agent" for software modules.

[0007] In the context of this invention, the software module should be understood as a security agent used within the framework of Zero Trust Architecture (ZTA). ZTA is a security concept based on the principle of "never trust, always verify." Unlike traditional security models based on trust relationships within the network boundary, ZTA assumes that every device, every user, and every application—even those located within the network—is potentially insecure. Therefore, any access to resources and services, regardless of the requester's location, must be explicitly authenticated and authorized. ZTA agents play a central role in implementing this principle. They act as local gatekeepers on the control device and monitor access to the corresponding functions. Access permissions are determined based on predefined rules and policies configured in the agent. These rules can be implemented, for example, based on whitelist / blacklist methods, role-based access control, or attribute-based access control. ZTA agents consistently adhere to the "never trust, always verify" principle, thus ensuring a high level of security even within the vehicle network.

[0008] The key is that at least two software modules must be distinct from each other. This distinction is crucial for the system's robustness. It reduces the risk of all modules being affected by the same error simultaneously.

[0009] Another important feature is that each software module is provided with functionality through a separate communication interface. This communication interface could be, for example, a network port, a memory region, or another communication channel. Using separate interfaces allows for additional isolation between modules.

[0010] Advantages of the present invention Compared to existing technologies, this method offers significant advantages. By running multiple different software modules, the system's fault tolerance is improved. If one module fails, the others can continue to provide the functionality. Using separate communication interfaces further enhances the system's robustness, as an error in a single interface will not harm other modules. Therefore, this invention enables reliable and safe functionality in vehicles, particularly in SDVs.

[0011] Other advantages are derived from the dependent claims.

[0012] In a preferred embodiment, the at least two software modules are distinguished by at least one implementation aspect in order to reduce the probability of all software modules failing simultaneously. An implementation aspect refers to the specific technical implementation of the software module. Examples of implementation aspects include: the programming language used (e.g., C++, Python, Java); the algorithm used (e.g., for data processing, communication, or decision-making); the data structure used (e.g., array, list, tree); or the module's architecture (e.g., monolithic architecture, modular architecture, distributed architecture).

[0013] By diversifying software modules in at least one implementation aspect, the robustness of the system against errors and security vulnerabilities is improved. If these modules differ in various ways, they are less likely to be affected by the same error or vulnerability. Therefore, if an error occurs in one module, another module, implemented differently, can continue to provide the functionality. This increases the system's fault tolerance and availability.

[0014] In another preferred embodiment, these software modules differ in that they use different programming languages, different algorithms, different data structures, and / or different communication protocols. Different programming languages, such as C++ and Python, use different syntax, semantics, and runtime environments. Different algorithms, even if they perform the same task, may have different computational paths and complexities. Different data structures, such as arrays and linked lists, organize and store data in different ways. Different communication protocols, such as TCP and UDP, control the data exchange between these software modules and other components in the vehicle.

[0015] Using different programming languages, algorithms, data structures, and / or communication protocols contributes to the diversity of software modules. This diversity improves the robustness of the system because it reduces the probability that all modules are affected by the same error or vulnerability. If a module fails due to a specific error in its programming language, algorithm, data structure, or communication protocol, other modules implemented differently can continue to provide that functionality.

[0016] In another preferred embodiment, two or more software modules are run. Instead of using only two software modules, three, four, or more modules can be used to provide the functionality. Each of these modules provides the functionality through a separate communication interface and differs from the other modules in at least one aspect of implementation.

[0017] Using two or more software modules increases system redundancy and thereby improves system fault tolerance. If one module fails, multiple alternative modules are available to take over the function. This reduces the probability of a complete system failure and increases the availability of the function.

[0018] In another preferred embodiment, it is specified that the state of at least one of the at least two software modules is monitored. Monitoring the state of a software module may include, for example, checking its functionality, performance, or security integrity. Specific examples of this monitoring include checking the module's CPU utilization, measuring response time to requests, or checking the integrity of the module's code. The state of a module can be monitored through various mechanisms, such as through module self-tests, queries through external monitoring systems, or analysis of log files.

[0019] By monitoring the status of software modules, potential problems can be identified early. This allows for targeted corrective actions to be taken before a module fails and consequently impairs its functionality. Therefore, status monitoring helps increase the reliability and stability of the system.

[0020] In another preferred embodiment, the method includes restarting a malfunctioning software module. If monitoring the status of a software module reveals that it is no longer functioning correctly, a restart can be performed. "No longer functioning correctly" can, for example, mean that the module is no longer responding to requests, providing incorrect results, or has a security vulnerability. The module can be restarted through various mechanisms, such as resetting the module, reloading the module code, or initializing the module's internal data structures.

[0021] Restarting a malfunctioning software module allows it to be restored to a working state and its functionality revived. This increases system availability and reliability. The restart can be triggered automatically by the monitoring system or performed manually by the operator.

[0022] In another preferred embodiment, the monitoring is performed by comparing the results of at least two software modules. In this case, these modules provide the same functionality, and their results are compared with each other. "Results" can be, for example, calculated values, control signals, or status information. If the results of these modules differ from each other, this may indicate an error in one of these modules. "Different results" could be, for example, values ​​exceeding tolerance limits or contradictory status information. In this case, optionally, as described above, a restart of the malfunctioning module can be triggered.

[0023] Comparing the results of software modules can improve the accuracy and reliability of the provided functionality. Different results indicate the presence of errors, allowing for early identification and correction. Selectively combining the restart of faulty modules with these errors increases the usability of the functionality.

[0024] In another preferred embodiment, the comparison of these results is performed by a control device that uses the results. This means that the control device, which uses the functionality provided by these software modules, is also responsible for comparing the results. The control device receives the results from each module and compares them with each other. If the results differ, the control device may, for example, initiate a restart of the module with the error or output an alarm message. The control device uses the results from the software modules to perform its own functions, such as controlling the engine or braking system. Therefore, the control device can evaluate the reasonableness of these results in conjunction with its own functionality.

[0025] The advantages offered by this implementation are that the comparison function is integrated into the control device, eliminating the need for a separate monitoring component. This simplifies the system architecture and reduces implementation costs. Furthermore, because the control device is aware of its own functions, it can better evaluate the reasonableness of the software module's results compared to general-purpose monitoring components.

[0026] In another preferred embodiment, the monitoring and / or restart is performed by a separate, additional software module on the control device, particularly by a watchdog. This means that a dedicated module is responsible for monitoring other software modules and, if necessary, monitoring their restart. This separate module, which may be called a "watchdog," runs in the background and continuously or periodically checks the status of other modules. This check can be performed, for example, by periodically querying the status of modules or by comparing the results of these modules. If the watchdog detects an error in a module, it can restart that module. The watchdog itself is a separate software module that operates independently of other modules. However, the watchdog resides on the same control device.

[0027] By using a dedicated watchdog timer, the complexity of individual software modules is reduced because these modules do not need to implement their own monitoring logic. The watchdog timer can also be specifically optimized for monitoring and restarting, which improves system efficiency and reliability. Running the watchdog timer on the same control device enables fast and efficient communication between the watchdog timer and the monitored modules.

[0028] In another preferred embodiment, the monitoring and / or restart is performed by a separate, additional software module (especially a watchdog timer), which runs on a separate control device or central unit (especially a gateway). Unlike the embodiments described above where the watchdog resides on the same control device, the watchdog here is spatially separated from the monitored software module. The watchdog communicates with these modules via the vehicle network. The gateway is the central communication interface in the vehicle network, enabling data exchange between different control devices and subnetworks. The advantage of running the watchdog on the gateway is that the watchdog can monitor the status of modules on different control devices.

[0029] This implementation offers greater fault tolerance and independence. Even if the control device on which the actual software module runs fails, the watchdog can continue to function normally on that separate control device or gateway, and take corrective measures as necessary, such as sending a restart command to the corresponding module or notifying the central diagnostic system. Spatial separation of the watchdog from the monitored module improves the robustness of the entire system.

[0030] The aforementioned advantages also apply correspondingly to control devices, particularly vehicle control devices, configured to perform the method according to any one of the above embodiments. The control device includes hardware and software components required to perform the steps of the method. The control device comprises at least two software modules that are distinct from each other and each provides the functionality through a separate communication interface. The control device may additionally include other components such as a processor, memory, communication interfaces, and one or more watchdog timestamps. The control device is configured, i.e., these hardware and software components are specifically selected and implemented, so that the control device can perform the steps of the claimed method.

[0031] This control device provides robust and fail-safe functionality in vehicles, particularly in SDVs. By running multiple different software modules on the control device, the availability of functionality is ensured even in the event of a module failure. Using separate communication interfaces further enhances system robustness. Configuring the control device to perform the required protection methods enables different monitoring and restart mechanisms to further increase system reliability.

[0032] The aforementioned advantages also apply correspondingly to control devices or central units configured to monitor and / or restart software modules via a separate, additional software module (especially a watchdog timer), which runs on another control device or central unit. This means that the monitored software module and the watchdog timer are spatially separated and communicate with each other via the vehicle network. The central unit, such as a gateway, serves as a central communication interface in the vehicle network. The control device or central unit running the watchdog timer includes the hardware and software components required for monitoring and restarting software modules on other control devices.

[0033] By separating the watchdog timer from the monitored modules, the system's fault tolerance and robustness are improved. Even if the control device running the actual software modules fails, the watchdog timer on the individual control device or the central unit can continue to function normally and take corrective measures. Centralizing the watchdog timer on the gateway also allows monitoring of modules on different control devices. This simplifies the system architecture and increases system flexibility.

[0034] The aforementioned advantages also apply to vehicles or external devices equipped with such control devices.

[0035] A computer program is provided, comprising instructions that, when executed by a computer or a control device, particularly a control device according to any one of the above embodiments, cause the computer / control device to perform the method according to any one of the above embodiments.

[0036] A computer-readable medium is provided on which a computer program according to any of the above embodiments is stored. This medium may exist in various forms, such as a hard disk, SSD, USB flash drive, SD card, CD-ROM, or as part of an integrated storage module within a control device or apparatus according to any one of the above embodiments. Storing the computer program on this medium facilitates the installation and updating of software required to perform the methods according to any one of the above embodiments. Attached Figure Description

[0037] Embodiments of the invention are schematically illustrated in the accompanying drawings and will be described in more detail in the following description. The same reference numerals are used for elements shown in different drawings that serve a similar function, wherein repeated descriptions of these elements are omitted.

[0038] in: Figure 1 A schematic diagram is shown of a method, control device, vehicle, computer program, and storage medium for providing functionality in a vehicle according to an embodiment; Figure 2 A schematic diagram of a system architecture for providing functionality in a vehicle, according to an embodiment, is shown; and Figure 3 The variety of software modules according to the embodiments is shown. Detailed Implementation

[0039] As described above, this invention describes a method and a control device that enable improved fail-safety and robustness when providing functionality in vehicles, particularly software-defined vehicles (SDVs). By running multiple, diverse software modules on the control device and providing the functionality via separate communication interfaces, the availability of the functionality is ensured even if individual modules fail or are compromised. The diversity of modules also enhances the system's resilience to various error types and attack vectors.

[0040] Figure 1 The left side shows a flowchart of a method 100 for providing functionality in vehicles, particularly software-defined vehicles. Figure 1 On the right side of the diagram, a control device 105, a vehicle 1, a storage medium 15, and a computer program 20 are schematically shown according to an embodiment. The control device 105 may be integrated or disposed in, or integrated or disposed on, the vehicle 1. The computer program 20, when executed by a computer or by the control device 105, may cause the computer / control device to perform the steps of the method 100 according to an embodiment of the invention.

[0041] The method 100 begins with the following steps: running 101 or more software modules on a control device 105. Alternatively, the software modules may also be referred to as software agents, which are program components that provide the required functionality. In this context, these software modules should be understood as security agents within a zero-trust architecture framework. The control device is an electronic control unit in vehicle 1, which can be responsible for performing various functions. It is specified that at least two software modules are run to increase the availability and robustness of the system. These at least two software modules are differentiated from each other. This differentiation occurs in at least one implementation aspect to reduce the probability of all software modules failing simultaneously. For example, the differentiation of these software modules may involve using different programming languages, such as C++ and Python; using different algorithms, such as deterministic hashing and cryptographic hashing; using different data structures, such as strings and JSON; and / or using different communication protocols, such as TCP and UDP. This diversification improves the system's robustness to various error types and attack vectors. In a preferred embodiment, more than two software modules are used to further increase redundancy. Optionally, for the requirements of this function, one of the at least two software modules can be selected, wherein the selection can be based on the state of these software modules. Optionally, the method 100 may further include: monitoring the state of at least one of the at least two software modules, for example by checking CPU utilization, response time, or code integrity. Optionally, based on the monitoring, a restart of the malfunctioning software module can be performed, for example by resetting the module, reloading the module code, or reinitializing it. Optionally, the monitoring can be performed by comparing the results of the at least two software modules, and the restart can be optionally triggered when the results differ. The monitoring and / or the restart can be performed by a separate, additional software module (especially a watchdog). The watchdog can run on the same control device 1, or on a separate control device, such as a gateway. The gateway is a central communication interface in the vehicle network that enables data exchange between different control devices and sub-networks. Running a watchdog on the gateway enables monitoring of software modules on multiple control devices.

[0042] In providing this functionality (step 102), each software module provides it through a separate communication interface. This communication interface could be, for example, a network port or other communication channel. Using separate interfaces increases module isolation and prevents errors in the interface from impairing the functionality of other modules.

[0043] Figure 2A schematic diagram of a system architecture for providing functionality in vehicle 11, particularly in a software-defined vehicle (SDV), is shown. The system includes: a client 201; two software agents 202 and 203; and functionality 204 provided by these agents 202 and 203. Client 201 represents any component in vehicle 11 that requires functionality 204. This could be, for example, another control device, sensor, actuator, or human-machine interface. Software agents 202 and 203 run on control device 205. Control device 205 is a dedicated hardware unit optimized for the operation of the agents. This control device could be, for example, a microcontroller, a dedicated processor, or a combination of both. Control device 205 is connected to other components in vehicle 11, such as client 201, via an internal vehicle network.

[0044] Each software agent 202, 203 provides functionality 204 through separate communication interfaces 207, 208. In this case, communication interfaces 207, 208 are represented as arrows pointing from agents 202, 203 to functionality 204. These interfaces 207, 208 may be, for example, network ports, shared memory segments, or dedicated hardware connections. Agent 202 communicates with functionality 204 through interface 207, and agent 203 communicates with the functionality through interface 208. Using separate interfaces 207, 208 ensures isolation between agents 202, 203 and improves system robustness. Errors or security vulnerabilities in agents 202, 203 or in interfaces 207, 208 will not impair the functionality of other agents 202, 203.

[0045] Diversify the software agents 202 and 203 to minimize the probability of simultaneous failures. This diversification can involve various implementation aspects, such as using different programming languages ​​(e.g., C++ for agent 202 and Python for agent 203), different algorithms (e.g., deterministic hashing for agent 202 and cryptographic hashing for agent 203), different data structures (e.g., arrays for agent 202 and linked lists for agent 203), and different communication protocols (e.g., TCP for agent 202 and UDP for agent 203).

[0046] Client 201 can select between agents 202 and 203 through a selection mechanism. This selection can be based, for example, on the status of agents 202 and 203, determined by periodic status reports from agents 202 and 203 to client 201 or to a central monitoring component. These status reports can include information about the agent's CPU utilization, response time, or memory usage. If an agent 202 or 203 fails or no longer functions correctly, client 201 can initiate a switch to another agent 202 or 203.

[0047] Figure 3 The diversity of software modules is illustrated with a specific example. The accompanying diagram shows two software modules, Software Agent 1 302 and Software Agent 2 303, which provide the same functionality but are implemented in different ways. In this example, the difference between agents 302 and 303 lies in the programming language used and the hash algorithm employed. Agent 1 302 is implemented in C++ and uses a deterministic hash algorithm 312. Agent 2 303 is implemented in Python and uses a cryptographic hash algorithm 313. Using different programming languages ​​and hash algorithms reduces the probability that both agents will be affected by the same error simultaneously. The programming languages ​​C++ and Python have different syntax, semantics, and runtime environments. Deterministic hash algorithms and cryptographic hash algorithms are based on different mathematical principles and have different characteristics in terms of collision resistance and computational workload.

[0048] The two agents 302 and 303 access a common key-value store 305. Key-value store 305 stores the data required by agents 302 and 303 to provide this functionality. Access to key-value store 305 is achieved through keys, which are hashed using appropriate hash algorithms 312 or 313. Using different hash algorithms will produce different hash values ​​for the same key, thereby reducing the probability of collisions when accessing key-value store 305.

[0049] Figure 3 The dashed line represents communication path 307 between agents 302 and 303 and key-value store 305. This communication can be carried out through different mechanisms, such as shared memory, message queues, or network connections.

Claims

1. A method (100) for providing functionality (204) in vehicles (1, 11), particularly software-defined vehicles (SDVs), wherein, At least two software modules (202, 203), and in particular two software agents (302, 303), are run on the control devices (105, 205). Its features are, The at least two software modules (202, 203) are distinct from each other, and each of the at least two software modules (202, 203) provides the function (204) of (102) through a separate communication interface (207, 208).

2. The method (100) according to claim 1, wherein, The at least two software modules (202, 203) are distinguished by at least one implementation aspect in order to reduce the probability that all software modules (202, 203) will fail simultaneously.

3. The method (100) according to claim 1 or 2, wherein, The software modules (202, 203) differ in that they use different programming languages, different algorithms, different data structures and / or different communication protocols.

4. The method (100) according to any one of claims 1 to 3, wherein, Run more than two software modules (202, 203).

5. The method (100) according to any one of claims 1 to 4, the method further comprising: Monitor the status of at least one of the at least two software modules (202, 203).

6. The method (100) according to claim 5, further comprising: Restart the software modules that are not working properly (202, 203).

7. The method (100) according to claim 5 or 6, wherein, The monitoring is performed by comparing the results of the at least two software modules (202, 203), and the restart is triggered when the results are different.

8. The method (100) according to claim 7, wherein, The comparison is performed by control devices (105, 205) that use the results.

9. The method (100) according to any one of claims 5 to 8, wherein, The monitoring and / or restart are performed by a separate, additional software module on the control devices (105, 205), particularly by a watchdog timer.

10. The method (100) according to any one of claims 5 to 8, wherein, The monitoring and / or the restart are performed by a separate, additional software module, in particular by a watchdog that runs on another control device (105) or central device, in particular a gateway.

11. A control device (105, 205), particularly a control device for a vehicle (1, 11), configured to perform the method (100) according to any one of claims 1 to 9.

12. A control device or central device, particularly a control device or central device for a vehicle (1, 11), said control device or central device being configured to perform the method (100) according to claim 10, wherein, The separate, additional software module runs on the control device or central unit.

13. A computer program (20) that, when executed on a computer or a control device (105, 205) according to claim 11 or 12, causes the computer or the control device according to claim 11 or 12 to perform the method (100) according to any one of claims 1 to 10.

14. A computer-readable storage medium (15) storing a computer program (20) according to claim 13.

Images