DE102021125749A1 - Device, method and computer program for monitoring security of computing function blocks in a vehicle - Google Patents

Abstract

The present invention relates to a device, a method and a computer program for monitoring the security of computing function blocks in a vehicle, and to a corresponding vehicle. The device includes one or more interfaces for communicating with one or more computing resources of the vehicle. The device includes one or more processors designed to determine the computing function blocks of the vehicle. The one or more processors are designed to check whether operation of the arithmetic function blocks satisfies a security requirement. The one or more processors are configured to adjust operation of a computational function block if the operation of the computational function block fails to verify.

Description

The present invention relates to a device, a method and a computer program for monitoring the security of computing function blocks in a vehicle, and to a corresponding vehicle.

In modern vehicles, an ever-increasing number of functions are provided by software. These functions are usually implemented by services that are executed on the vehicle's computing units. These functions can be implemented, for example, as computational function blocks that are executed in vehicle runtime environments.

Vehicles usually have a long service life during which the hardware used remains unchanged. For example, a car developed in 2020 could be sold by 2030 and operated for 15 years. In this context it is a challenge to keep the software of the calculation function blocks usable and attractive. This challenge is increasing with the introduction of specifications for the software operational safety of vehicles, for example according to UNECE (United Nations Economic Counsel for Europe, Economic Commission for Europe of the United Nations) WP.29 and ISO/SAE (International Standardization Organization/Society of Automotive Engineers , International Standardization Organizations/Society of Vehicle Engineers) 21434.

The vehicle software can be updated in the dealership, in a workshop or over the air (OTA, "Over-the-Air"). However, there is no standardized method for hardware replacements. Software updates are also only possible to a limited extent, depending on the vehicle's computing capacity and whether the interfaces used meet modern requirements.

In many cases, buyers of a vehicle add functions afterwards by installing additional accessories in the vehicle, such as navigation devices, smartphones with navigation software and music streaming or so-called dashcams. Such accessories can be installed independently of the vehicle and provide functions independently of the vehicle.

However, accessories typically offer minimal integration with the vehicle (e.g. via an audio cable or Bluetooth) without access to vehicle data.

Out of U.S. 2013/0031604 A1 a method for remote authentication is known. This covers updating applications that run on the driver's mobile device and require communication with the vehicle.

There is a need to provide an improved concept for the safe operation of software components in vehicles.

This need is met by the subject matter of the independent claims.

The present invention is based on the knowledge that a basis for safe long-term operation of software-based vehicle functionality is to determine which functionality can be operated safely in the current state and which vehicle functionality cannot be operated safely. If the latter is determined, measures are taken to make the operation of the vehicle functionality safe. Various measures are conceivable, from updating the computing function block that provides the vehicle functionality, to measures to limit the functionality of the computing function block (e.g. by restricting the communication capabilities), to replacing the hardware and operating the existing computing function blocks in a virtual environment. This allows safe long-term operation of the vehicle functionality.

Some aspects of the present disclosure relate to an apparatus for monitoring security of computational functional blocks in a vehicle. The device includes one or more interfaces for communicating with one or more computing resources of the vehicle. The device includes one or more processors designed to determine the computing function blocks of the vehicle. The one or more processors are designed to check whether operation of the arithmetic function blocks satisfies a security requirement. The one or more processors are configured to adjust operation of a computational function block if the operation of the computational function block fails to verify. A need for action can be determined by checking whether the operation of the arithmetic function blocks corresponds to the safety target. Adjusting the operation of the arithmetic function block can in turn ensure that all arithmetic function blocks are operated according to the safety target.

For example, the test can fail if the operation of the arithmetic function b locks does not meet the security requirements and an update, at least using the available computing resources, is impossible. If an update is necessary but not possible, it may not be possible to ensure sufficiently reliable operation of the arithmetic function block.

Now there are several ways to ensure the operational safety of the vehicle.

For example, adjusting the operation of the computational function block may include removing or permanently disabling the computational function block. This can prevent arithmetic function blocks from being operated that do not comply with the safety specification.

Alternatively, adjusting operation of the computational function block may include blocking communication of the computational function block. This isolates the arithmetic function block from the other vehicle components, which in many cases allows safe operation of the arithmetic function block, but sometimes with functional restrictions.

For example, adjusting operation of the computing function block may include blocking communication of the computing function block with one or more other computing function blocks of the vehicle. This can prevent the one or more other function blocks from being adversely affected by the arithmetic function block. Additionally or alternatively, adjusting operation of the computing function block may include blocking communication of the computing function block with a remote peer. This can prevent remote actuators from gaining access to the vehicle.

In some examples, adjusting the operation of the computational function block includes removing a coupling of the computational function block to a remote peer. As a result, the arithmetic function block and the remote partner can lose the possibility of mutual communication and influencing. For example, the pairing can be removed by removing one or more cryptographic certificates. If these certificates are no longer available, the computing function block and the remote peer can refuse to communicate with the respective peer.

In general, vehicles have only a limited amount of computing resources. However, the demand for computing resources of the individual computing function blocks can increase over time. Therefore, a decision can now be made as to which arithmetic function blocks will continue to operate and which can be deactivated. Accordingly, adjusting the operation of the computational function block may depend on whether operation of the computational function block is necessary or optional. This can be used as a criterion for which arithmetic function block is to be deactivated and which can continue to be operated after updating.

For example, adjusting operation of the computational functional block may include removing or permanently disabling another computational functional block to free up additional computational resources for continued operation of the computational functional block. Adjusting the operation of the computational functional block may further include updating the computational functional block using the additional computational resources. Thus, by deactivating an optional arithmetic function block, additional arithmetic resources can be created for the operation of the necessary arithmetic function block.

This is also relevant in particular when the arithmetic function blocks are implemented at least partially by means of reconfigurable hardware, such as so-called field-programmable gate arrays (field-programmable arithmetic gate array, FPGA). For example, the vehicle's one or more computing resources may include at least one reconfigurable hardware component. Adjusting the operation of the computational function block may include removing or permanently disabling the other computational function block to free computational gates of the reconfigurable hardware component for continued operation of the computational function block.

There are various criteria and implementations for testing whether a computational function block satisfies the security target. For example, checking whether operation of the computing function blocks satisfies a security requirement can be based on at least one of a period of time since the respective computing function blocks were last updated, a validity of a cryptographic certificate for the respective computing function blocks, and a set of rules from a remote peer . The first two options enable a time-based, automatic determination that the respective computing function block can no longer be operated securely (whereby the cryptographic certificate can be renewed to ensure the continued operation of the computing function block if this seems justifiable). The rules of the remote opponents can be used because the remote remote station can collect information for a fleet of vehicles about which computing function blocks can be operated safely and with which update status.

Some aspects of the present disclosure relate to a vehicle having an apparatus as previously presented and the one or more computing resources.

Some aspects of the present disclosure relate to a method for monitoring security of computational functional blocks in a vehicle. The method includes determining the computational functional blocks of the vehicle. The method further includes checking whether operation of the computing function blocks satisfies a security target. The method further includes adjusting the operation of a computational function block if the verification of the operation of the computational function block fails.

This method can be implemented as a computer program, for example. Therefore, some aspects of the present disclosure relate to a program with program code for performing the method when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

In some cases, however, the procedure can also be carried out using a computer program. This can be the case if the computing resources used are exchanged within the framework of the vehicle. Thus, adapting the operation may include transferring the computing function blocks to a virtual execution environment, replacing at least one computing resource of the vehicle with a new computing resource, and executing the virtual execution environment with the computing function blocks on the new computing resource. By exchanging the computing resource, a computing resource with an increased computing capacity or storage capacity can be incorporated into the vehicle, as a result of which the computing function blocks can be updated for a longer period of time.

• 1a zeigt ein schematisches Diagramm eines Beispiels einer Vorrichtung für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug;
• 1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit einer Vorrichtung für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug; und
• 2a und 2b zeigen Flussdiagramme von Beispielen eines Verfahrens für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug.

Some examples of devices and/or methods are explained in more detail below with reference to the accompanying figures, merely by way of example. Show it:

• 1a Fig. 12 shows a schematic diagram of an example of an apparatus for monitoring security of computational functional blocks in a vehicle;
• 1b Figure 12 shows a schematic diagram of an example of a vehicle with an apparatus for monitoring security of computational functional blocks in a vehicle; and
• 2a and 2 B Figure 12 shows flowcharts of examples of a method for monitoring security of computing function blocks in a vehicle.

Some examples will now be described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these detailed described embodiments. These may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe particular examples is not intended to be limiting of other possible examples.

Throughout the description of the figures, the same or similar reference symbols refer to the same or similar elements or features, which can each be implemented identically or in a modified form, while providing the same or a similar function. Also, in the figures, the thicknesses of lines, layers, and/or areas may be exaggerated for clarity.

When two elements A and B are combined using an "or", it is to be understood that all possible combinations are disclosed, i. H. only A, only B and A and B, unless expressly defined otherwise in individual cases. "At least one of A and B" or "A and/or B" can be used as alternative wording for the same combinations. The equivalent applies to combinations of more than two elements.

If a singular form, e.g. For example, where "a, an" and "the" are used and the use of a single element is not explicitly or implicitly required, other examples may use multiple elements to implement the same function. Where a function is described below as being implemented using multiple elements, other examples may implement the same function using a single element or processing entity. It is further understood that the terms "comprises,""comprising,""comprises," and/or "having," when used, imply the presence of the specified feature, integer, step, operation, process, element, component, and/or group of the same describe, but not the presence or addition of a or exclude multiple other characteristics, integers, steps, operations, processes, elements, components and/or a group thereof.

As mentioned earlier, vehicle development cycles and service life create challenges related to the maintenance of vehicle software. Software that is developed in 2020 can be found in vehicles that are still being sold 10 years later. These vehicles can in turn be operated for 15 years (or longer), so that the software must theoretically be maintained from 2020 to 2045. The challenges only get bigger in classic cars, because new risks may arise here that were not yet relevant when the classic car was developed, but will occur in the next 30 years or so. In principle, it is possible to keep the vehicle as up-to-date as possible, or to remove the functionality as part of maintenance.

Keeping the software compatible and updated 30 years on is a challenge. To address this challenge, one of the following strategies can be employed.

On the one hand, the software can be updated over a very long period of time. Even 30-year-old hardware can be constantly updated. Although this is theoretically possible, it leads to very high costs and is also very unusual in industry.

On the other hand, can. if the software is outdated - and thus the hardware in the vehicle can no longer be supported, the hardware is replaced with modern hardware with the latest software in order to keep the vehicle "fresh". Therefore, the customer or the manufacturer can replace the hardware and take care of the cost. Basically, two groups of customers can be distinguished - customers who want to update existing vehicles (e.g. against payment) and customers who are not interested in doing so. In the latter case, security should still be guaranteed. A distinction can now be made between safety-relevant interfaces, the status of which can be frozen, or the functionality of which can be separated or switched off, and user-relevant interfaces, for which different approaches can be selected.

Alternatively, new hardware capable of running the new software that has evolved over the past 30 years can be added. However, it is a challenge to get users enthusiastic about the new hardware.

In some cases, reconfigurable hardware can also be used to support new software functions. This allows specialized functions to be implemented that can enable new software applications.

The disadvantage of this approach is the development costs for a very limited number of customers. Because not many car owners own 15-year-old cars and are willing to pay to upgrade, the low sample rates result in expensive replacement costs and reduce the number of customers buying even more.

The third, and possibly preferred, option is to separate the software into statutory and non-statutory software. Some functionalities of the vehicle are required by law (such as eCall or reports for authorities). This software must be maintained over the entire life cycle of the vehicle. Other functionality may be restricted, for example switched off.

The device introduced below, the method introduced below and the corresponding computer program can now be used to support or provide the previously mentioned options for safe operation of the software functions of the vehicle.

1a 12 shows a schematic diagram of an example of a device 10 for monitoring security of computing functional blocks 20 in a vehicle 100. The device 10 comprises one or more interfaces 12 for communication with one or more computing resources 30 of the vehicle. The device 10 also includes one or more processors 14. Optionally, the device 10 also includes one or more storage devices 16. In principle, the functionality of the device 10 can be provided by the one or more processors 14 with the aid of the one or more interfaces 12 (e.g Exchanging information, such as communicating with the one or more computing resources or communicating with a remote peer) and/or using the one or more storage devices 16 (for storing and retrieving information). The one or more processors 14 are designed to determine the computing function blocks of the vehicle. The one or more processors 14 are designed to check whether operation of the arithmetic function blocks satisfies a security requirement. The one or more processors 14 are configured to adjust operation of a computational function block if the operation of the computational function block fails to verify.

The device 10 and the one or more computing resources 30 are part of a vehicle 100, which is 1b is shown. 1b 10 shows a schematic diagram of an example of the vehicle 100 with the apparatus 10 for monitoring security of computing functional blocks in a vehicle. The vehicle 100 also includes the one or more computing resources 30. The one or more computing resources are in turn designed to execute the computing function blocks. Within the vehicle, the computing resources 30 may be configured to communicate with other components of the vehicle, such as the device 10, via an in-vehicle network.

The calculation function blocks are logical units that provide software-based vehicle functionalities. A technology can be used in which services that provide software functionalities of the vehicle are packaged in the computing function blocks. These arithmetic function blocks can in turn be implemented by so-called software containers or correspond to them. One or more services can be encapsulated with all their dependencies in a software container. These containers are known in particular for use on servers and developer devices. For example, such containers can be provided by different container engines (Docker, Podman, Crio, ...). The present disclosure provides for use of such containers in a vehicle. The computing resources, which can correspond to computing units/control units of the vehicle, can be designed to provide a runtime environment for the computing function blocks/containers.

The basis of the security check is the determination of the computing function blocks of the vehicle. Different vehicles of the same type can have different computing function blocks, for example, due to different hardware components (does the vehicle have a reversing camera, ultrasonic sensors, radar/lidar, a navigation device, etc.), due to different update statuses, or due to this that a user of the vehicle has installed a vehicle function, and therefore also a corresponding computing function block, via a vehicle application portal. Therefore, in a first step, an inventory is made of the vehicle's computing function blocks. The result of determining the vehicle's computational function blocks may be a list or data structure of computational function blocks currently in operation. Inactive arithmetic function blocks can, in some examples, be ignored.

The proposed concept uses a detection mechanism to check whether the functions can still be operated safely. Therefore, a check is made as to whether the operation of the arithmetic function blocks satisfies the security target. The check as to whether the operation of the arithmetic function blocks satisfies the security specification can include a detection of outdated or security-endangering functionality. This can be done using different mechanisms. For example, checking whether an operation of the computing function blocks satisfies a security target can be based on a period of time since the respective computing function blocks were last updated. If the length of time since the last update exceeds a threshold value, it can be assumed that the (unrestricted) operation of the respective arithmetic function block no longer corresponds to the security requirement.

This length of time can also be based on cryptographic certificates. For example, checking whether operation of the computing function blocks satisfies a security requirement can be based on the validity of a cryptographic certificate for the respective computing function blocks. In this case, the length of time is controlled by the cryptographic certificate, which in turn can be specified by the issuer of the certificate. A prediction can be made about the period of validity of the certificate as to how long the manufacturer or the creator of the certificate considers the safe operation of the respective computing function block to be possible. The certificates can be used to track update behavior. If there are no updates within a certain time frame, the software can be deactivated by the backend or by the device in order to secure the rest of the vehicle.

As a third option, a set of rules can be used that comes from/is retrieved from a remote partner (e.g. the vehicle manufacturer). Checking whether operation of the arithmetic function blocks satisfies a security requirement can thus be based on the set of rules of the remote partner. For example, the set of rules can specify whether the operation of a computing function block with a given update status corresponds to the security target. The set of rules can also specify which measures can be taken to ensure the safe operation of the arithmetic function block, or whether it is necessary to switch off the respective arithmetic function block.

Now the operation of those arithmetic function blocks, their operation in the current state does not meet the security requirements.

As already explained, various measures are possible here, namely the deactivation of outdated functionality, the encapsulation of insecure software, the hardware upgrade via reconfigurable hardware devices or the hardware upgrade with new hardware and virtualization of the old platform. The latter possibility is related to 2 B introduced.

In principle, the first and simplest option can be to update the arithmetic function block. In the present examples, it is assumed that such an operation, at least in the simplest case, does not lead to an adaptation of the operation of the calculation function block. In this case, the test can also be positive, since a possible breach of the security requirement can be remedied with simple means. For example, the check can be negative if the operation of the computing function block does not meet the security requirement and an update, at least using the available computing resources, is impossible. If the operation of the arithmetic function block does not meet the security target, but an update is possible, the test can be positive and the update can be carried out without adapting the operation of the arithmetic function block.

However, if this is not easily possible, one of the following measures can be taken.

Obsolete functionalities can be disabled (e.g. access to a calculation function block of a company that has gone bankrupt). In other words, adjusting the operation of the computational functional block may include removing or permanently disabling the computational functional block.

Other "legacy" functionalities can be encapsulated to limit the damage they can do (e.g. by no longer offering them network connectivity).

For example, adjusting operation of the computational function block may include blocking communication of the computational function block. A distinction can be made between communication in the vehicle and communication with external remote stations. For example, adjusting operation of the computing function block may include blocking communication of the computing function block with one or more other computing function blocks of the vehicle. Alternatively or additionally, adjusting operation of the computing function block may include blocking communication of the computing function block with a remote peer. This can happen, for example, by instructing a transfer point (gateway) between the arithmetic function blocks and other arithmetic function units to block the communication of the arithmetic function block. Alternatively or additionally, a software-based network can be adapted in such a way that the communication of the computing function block is blocked.

Many arithmetic function blocks are based in part on a concept called the "automotive edge". The computing function blocks are executed, for example as containers, on the vehicle's computing resources, but are closely linked to a backend server that manages the life cycle of the computing function blocks and grants access to the network of the vehicle manufacturer. In order to deactivate an arithmetic function block, the arithmetic function blocks (also called "end points") that are executed in the vehicle can be deleted or the entire "Automotive Edge" can be logged off. In order to only block communication, the information channels from the automotive edge to the backend can be capped. Accordingly, adjusting the operation of the computational functional block may include removing a coupling of the computational functional block to a remote peer (i.e., the backend server). Security connections to keys or, if possible, the key itself can also be deleted. For example, the pairing can be removed by removing one or more cryptographic certificates. As a result, possible connections to secure partners cannot be established

In addition, the automotive edge can be designed in such a way that only the automotive edge can start the conversation with the backend. So when the Automotive Edge is disabled (and potentially vulnerable to attacks from outside the vehicle), it is not possible to reach the Edge from the outside.

These actions may be taken in addition to removing or permanently disabling the arithmetic function block. In addition, warnings can be issued if the user wants to install new software (which is no longer supported by the system) or the installation can be made impossible.

As previously stated, when customizing the operation of arithmetic function blocks, A distinction can be made as to whether the operation of a computing function block is necessary (e.g. required by law or absolutely necessary for operating the vehicle), or whether the operation of the computing function block is optional, for example because the computing function block relates to functionality, the comfort functions provide to the user of the vehicle. Accordingly, adjusting the operation of the computational function block may be contingent upon, or made contingent upon, whether operation of the computational function block is necessary or optional.

Thereby, based on whether operation of the arithmetic function block is necessary or optional, the communication of the arithmetic function block can be blocked if the operation of the arithmetic function block is necessary, and the arithmetic function block can be removed or deactivated if the operation of the arithmetic function blocks is not necessary but optional.

For example, optional computational function blocks (such as optional computational function blocks that have never or rarely been used by the user of the vehicle) may be removed or disabled to free up computational capacity (or memory capacity) for a computational function block that is required to operate. Therefore, adjusting the operation of the compute function block may include removing or permanently disabling another compute function block to free up additional compute resources (i.e., additional compute capacity or memory capacity) for continued operation of the compute function block. Adjusting the operation of the computational functional block may further include updating the computational functional block using the additional computational resources. Here, the other arithmetic function block can be an arithmetic function block whose operation is optional. Also, there may be insufficient compute resources/capacity to update the compute function block unless the other compute function block is removed or disabled.

In one aspect, the one or more computing resources may also include a reconfigurable hardware component (e.g., an FPGA) that can be reprogrammed to support new software features that may provide a limited set of specialized features that the new software -Enable applications. In other words, the one or more computing resources of the vehicle may include at least one reconfigurable hardware component. The more complex the functionality becomes, the more gates of the reconfigurable hardware component are usually required. Therefore, a smaller number of (more complex) functions can be supported over time. Adjusting the operation of the computing function block can include removing or permanently disabling the other computing function block in order to free computing gates of the reconfigurable hardware component for further operation of the computing function block.

The at least one interface 12 may correspond, for example, to one or more inputs and/or one or more outputs for receiving and/or transmitting information, such as in digital bit values, based on a code, within a module, between modules, or between modules of different entities .

In examples, the one or more processors 14 may correspond to any controller or processor or programmable hardware component. For example, the functionality of the one or more processors 14 can also be implemented as software that is programmed for a corresponding hardware component. In this respect, the one or more processors 14 can be implemented as programmable hardware with correspondingly adapted software. Any processors, such as digital signal processors (DSPs) can be used. Exemplary embodiments are not limited to a specific type of processor. Any processors or even multiple processors are conceivable for the implementation.

The one or more storage devices 16 can be, for example, at least one element from the group of computer-readable storage medium, magnetic storage medium, optical storage medium, hard drive, flash memory, floppy disk, random access memory (also engl. Random Access Memory), programmable read only memory (PROM), erasable include programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), and network storage.

The vehicle 100 may correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, an all-terrain vehicle, a motor vehicle, or a truck.

More details and aspects of the device and the vehicle are mentioned in connection with the concept or examples given before or after (e.g 2a until 2 B ) to be discribed. The device and vehicle may include one or more additional optional features that improve one or more aspects of the foregoing proposed concept or the examples described, as previously or hereafter described.

A corresponding method for monitoring the security of computing function blocks in a vehicle is presented below, to which the functionality of the device 10 of FIG 1a and 1b underlying. Characteristics of the device, and in particular the one or more processors of the device, can therefore also be incorporated into the corresponding method 2a and 2 B be taken over.

2a and 2 B Figure 12 shows flowcharts of examples of a method for monitoring security of computing function blocks in a vehicle. The method includes determining 210 the computing function blocks of the vehicle. The method further includes checking 220 whether operation of the computing function blocks satisfies a security target. The method further includes adjusting 230 the operation of a computational function block if the verification of the operation of the computational function block fails.

A previously mentioned method steps were already in the context of the corresponding device 1a and 1b presented. This method can also be implemented as a computer program.

In some cases, however, the method can include at least one method step that is not controlled by a computer program or the device 1a and 1b can be executed. For example, all hardware or a major unit of hardware (ie, one or more computing resources) may be upgraded. The old vehicle software environment can be run in virtualization on the new hardware. Thus, adapting the operation may include transferring 232 the computing function blocks to a virtual execution environment, replacing 234 at least one computing resource of the vehicle with a new computing resource, and executing 236 the virtual execution environment with the computing function blocks on the new computing resource. Of these steps, steps 232 and 236 can be performed by the apparatus of FIG 1a and/or 1b and the computer program are executed. The new computing resource can have a higher computing capacity and/or storage capacity than the computing resource that was exchanged.

More details and aspects of the procedure are given in connection with the concept or examples given before or after (e.g 1a until 1b ) to be discribed. The method may include one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as previously or hereinafter described.

The aspects and features described in connection with a certain of the previous examples can also be combined with one or more of the further examples in order to replace an identical or similar feature of this further example or to additionally introduce the feature into the further example .

Examples may further include or relate to a (computer) program having program code for performing one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations, or processes of various methods described above may also be performed by programmed computers, processors, or other programmable hardware components. Examples may also include program storage devices, e.g. digital data storage media, which is machine, processor or computer readable and which encodes or incorporates machine executable, processor executable or computer executable programs and instructions. The program storage devices may e.g. B. include or be digital storage, magnetic storage media such as magnetic disks and magnetic tapes, hard drives or optically readable digital data storage media. Further examples can also be computers, processors, control units, (field-programmable logic arrays ((F)PLAs = (Field) Programmable Logic Arrays), (field)programmable gate arrays ((F)PGA = (Field) Programmable Gate Arrays ), graphics processors (GPU = graphics processor unit), application-specific integrated circuits (ASIC = application-specific integrated circuit), integrated circuits (IC = integrated circuit) or single-chip systems (SoC = system-on-a-chip). programmed to perform the steps of the procedures described above.

It is further understood that disclosure of a plurality of steps, processes, operations, or functions disclosed in the specification or claims should not be construed as necessarily being in the order described, unless expressly stated in an individual case or is compellingly necessary for technical reasons . Therefore, the foregoing description does not dictate the performance of multiple steps or functions in any particular order limited. Further, in other examples, a single step, function, process, or operation may include and/or be broken into multiple sub-steps, functions, processes, or operations.

If some aspects have been described in the preceding paragraphs in the context of a device or a system, these aspects are also to be understood as a description of the corresponding method. For example, a block, a device or a functional aspect of the device or the system can correspond to a feature, such as a method step, of the corresponding method. Correspondingly, aspects described in connection with a method are also to be understood as a description of a corresponding block, element, property or functional feature of a corresponding device or system.

The following claims are hereby incorporated into the Detailed Description, with each claim being able to stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject-matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in individual cases that a specific combination is not intended. Furthermore, features of a claim are also intended to be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Reference List

10

control device

12

interface

14

processor

16

storage device

20

arithmetic function block

30

unit of account

100

vehicle

210

Determination of the calculation function blocks of the vehicle

220

Check whether operation of the arithmetic function blocks satisfies a safety requirement

230

Customize the operation of a math function block

232

Transferring the computational function blocks to a virtual execution environment

234

Exchanging at least one computing resource

236

Running the virtual execution environment

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• US20130031604A1 [0007]

Claims (15)

Device (10) for monitoring a security of computing function blocks (20) in a vehicle (100), the device comprising: One or more interfaces (12) for communicating with one or more computing resources (30) of the vehicle; One or more processors (14) configured to: Determination of the calculation function blocks of the vehicle, Check whether operation of the arithmetic function blocks satisfies a safety requirement, and Adjusting the operation of a math function block if the test of the operation of the math function block fails. The device according to claim 1 , the check being negative if the operation of the computing function block does not meet the security target and an update, at least using the available computing resources, is excluded. The device according to one of Claims 1 or 2 , wherein adjusting the operation of the computational functional block comprises removing or permanently disabling the computational functional block. The device according to one of Claims 1 or 2 , wherein the adjusting the operation of the computational function block comprises blocking a communication of the computational function block. The device according to claim 4 , wherein adjusting operation of the computing function block comprises blocking communication of the computing function block with one or more other computing function blocks of the vehicle, and/or wherein adjusting operation of the computing function block includes blocking communication of the computing function block with a distant remote station. The device according to one of Claims 1 or 2 wherein adjusting the operation of the computational function block comprises removing a coupling of the computational function block to a remote peer. The device according to claim 6 , wherein the pairing is removed by removing one or more cryptographic certificates. The device according to one of Claims 1 until 7 wherein the adjusting operation of the computational function block is dependent on whether operation of the computational function block is necessary or optional. The device according to claim 8 , wherein adjusting the operation of the computing functional block comprises removing or permanently disabling another computing functional block to free up additional computing resources for continued operation of the computing functional block, and updating the computing functional block using the additional computing resources. The device according to claim 9 , wherein the one or more computing resources of the vehicle comprise at least one reconfigurable hardware component, wherein adjusting the operation of the computing function block comprises removing or permanently disabling the other computing function block in order to use computing gates of the reconfigurable hardware component for the continued operation of the release arithmetic function blocks. The device according to one of Claims 1 until 10 , wherein checking whether operation of the computing function blocks satisfies a security requirement is based on at least one of a period of time since the respective computing function blocks were last updated, a validity of a cryptographic certificate for the respective computing function blocks, and a set of rules from a remote peer . A vehicle (100) with a device according to one of Claims 1 until 11 and the one or more computing resources (30). A method for monitoring security of computing function blocks in a vehicle, the method comprising: determining (210) the computing functional blocks of the vehicle; checking (220) whether operation of the computational function blocks satisfies a security target; adjusting (230) the operation of a computational function block if the verification of the operation of the computational function block fails. The procedure according to Claim 13 , wherein adapting the operation includes transferring (232) the computing function blocks into a virtual execution environment, exchanging (234) at least one computing resource of the vehicle with a new computing resource, and executing (236) the virtual execution environment with the computing function blocks on the new Computing resource included. Program with a program code for performing the method according to Claim 13 , when the program code is executed on a computer, processor, control module or programmable hardware component.

Images