Detection / assessment of intrusion into electronic data system of vehicle
Patent Information
- Application Number
- JP2022075715
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-05-03
- Filing Date
- 2022-05-02
- Publication Date
- 2025-05-14
- Estimated Expiration
- 2042-05-02
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Background Art
[0001] For example, electromechanical technology systems such as vehicles often have one or more electronic data systems. For example, an electromechanical technology system may include a number of (electronic) control devices that can interact within at least one electronic data system, such as at least one bus system. The functions of such technology systems usually depend greatly on this interaction. For example, even in a non-autonomous vehicle, there may be more than 100 (electronic) control devices, such as an engine control unit, a transmission control unit, an anti-lock braking system / traction control unit, an airbag, a body control unit, a driving assistance system, a car alarm system, etc. More than 100 (electronic) control devices may be network-connected to each other via at least one electronic data system as nodes. As the digitalization, automation, and network connection of technology systems increase, the electronic data system may grow (i.e., the number of nodes increases), or multiple electronic data systems may be combined (e.g., via a gateway).
[0002] A Controller Area Network (CAN), in which technology systems, particularly vehicle control devices, are connected via a CAN bus and can communicate with each other according to the CAN protocol, is a known standardized serial bus system according to the multi-master principle, where all control devices within the CAN are equal. For example, CAN and / or CAN-derived developments (now in various versions) can be used in all kinds of electromechanical technology systems (e.g., in the automotive industry, automation technology, lift systems, medical technology, aviation and spaceflight technology, railway vehicle construction, shipbuilding,...). In the prior art, alternative communication systems and / or communication protocols for CAN and / or CAN-derived developments (abbreviated as CAN etc.) are particularly known for vehicles.
[0003] Electronic data systems, particularly CAN, have been developed and continue to be developed so that data transmission via the CAN bus is as independent as possible from external random interference, for example, from the perspective of electromagnetic compatibility (EMC). For example, the CAN bus is implemented using two stranded wires (CAN_HIGH, CAN_LOW), thereby achieving symmetrical signal transmission. As a result, CAN has been demonstrated particularly in safety-related fields where high data security is important (e.g., in vehicles). For example, electronic data systems such as CAN are relatively simple, robust, and fast (for example, by not using encryption), but on the other hand, they can be susceptible to intentional attacks and / or manipulation from external sources (for example, due to the multi-master principle and / or lack of encryption).
[0004] Generally, such intrusions into electronic data systems, particularly bus systems, may involve, for example, sending messages (also called frames) from additional, unintended nodes in the electronic data system, or from an intended but compromised node in the electronic data system. Such messages can disrupt communications at the intended nodes of the electronic data system. In particular, in this case, false messages may be sent by intentional deception (for example, by setting a recognition code / identifier for the intended node), and these messages may adversely affect the operation of the electronic data system and / or related technical systems, especially vehicles. With the increasing digitalization of technical systems (an increase in interfaces, e.g., the now common in-vehicle multimedia interfaces), as well as the process of automation and network connectivity, the attack surface in which intrusions can occur is expanding more and more. Therefore, it is important to protect electronic systems from intrusions.
[0005] Conventional intrusion detection systems (IDS) are already known, configured to detect intrusions into electronic data systems at a low level of integration (e.g., at the level of the electronic data system itself). Examples of such intrusion detection systems include ETAS / ESCRYPT's CycluIDS, ARGUS's In-vehicle Network Protection, or ARILOU's Sentinel-CAN. When an intrusion into an electronic data system is detected by an intrusion detection system, a log can be recorded, for example, at a node, for documentation and subsequent analysis. Alternatively or additionally, information can be provided to the user of the technical system (e.g., a vehicle) (e.g., driver or occupant) or another service point via a user interface. In addition to or alternative to these passive responses, active and as immediate as possible responses may be desired, particularly to prevent (timely) the operation of the electronic data system and / or related technical systems. In a bus system, for example, error messages (also called error frames) can be sent to the bus and, by extension, to all nodes in the bus system. [Overview of the project] [Means for solving the problem]
[0006] A first general aspect of this disclosure relates to a computer implementation method for detecting and / or evaluating intrusion into a vehicle's electronic data system. The method includes receiving data for each node in a set of nodes of the vehicle's electronic data system. The method further includes calculating a vehicle state based on the data. The method may further include detecting an intrusion into the vehicle's electronic data system, at least based on the vehicle state. Alternatively or additionally, the method may include evaluating an intrusion into the vehicle's electronic data system, at least based on the vehicle state.
[0007] A second general aspect of the present disclosure relates to a server in a network configured to implement a computer implementation method for detecting and / or evaluating intrusion into a vehicle's electronic data system, as described in the first general aspect (or one embodiment thereof), wherein the electronic data system of a vehicle, and optionally, each electronic data system of each further vehicle in a further collection of vehicles, are connected to the server in the network.
[0008] A third general aspect of this disclosure relates to a vehicle including an electronic data system protected in accordance with a computer implementation method for detecting and / or evaluating intrusion into the vehicle's electronic data system, as described in the first general aspect (or one embodiment thereof).
[0009] As already described in the prior art section, (timely) detection of intrusions into a vehicle's electronic data systems is crucial to ensuring the safe operation of the vehicle, and potentially its users (e.g., the driver and / or passengers), as well as its surroundings (e.g., other road users). Even if attempts can be made to prevent intrusions into a vehicle's electronic data systems in principle, history shows that even (well) protected electronic data systems will eventually be compromised. This may be because, for example, technological systems, especially vehicles, are designed for a certain operating lifespan (e.g., 10 to 20 years), creating a constant competition between technologies for protection and technologies for intrusion and / or circumvention. Furthermore, the increasing digitalization of technological systems (e.g., the increase in interfaces, e.g., the now common in-vehicle multimedia interfaces), as well as the process of automation and network connectivity, can be seen as increasing the attack surface for potential intrusions and / or circumvention of protections. Therefore, it is important to have at least one (in-vehicle or external) intrusion detection system for the vehicle, configured to detect intrusions into the vehicle's electronic systems. To prevent harmful interference caused by intrusion, it is desirable that intrusion detection systems be able to intervene and / or warn as quickly as possible.
[0010] However, intrusion detection can sometimes be erroneous. This can be due to the fact that technical systems, such as vehicles and electronic data systems, are typically highly complex and can be subject to open context, for example, in the case of autonomous driving. In addition to the possibility of an actual intrusion not being detected (which can be called a false positive), it is even more possible to misidentify a non-intrusion as an intrusion (which can be called a false negative). While undetected intrusions (false positive cases) may indicate a malfunction of the intrusion detection system and are therefore undesirable, detected suspected intrusions (false positive cases) can even disrupt the functionality of technical systems, especially vehicles, even under normal circumstances (i.e., without an actual intrusion). For example, it would be unacceptable if a suspected intrusion into the vehicle were detected every time a vehicle user's digital smart device connected to the vehicle's electronic data system via a multimedia interface, and the user was subsequently requested to visit a service. Therefore, it is sometimes important to be able to evaluate, and in some cases verify, events (also called situations) that have been determined to be intrusions by (in-vehicle and / or external) intrusion detection systems.
[0011] Therefore, as proposed in computer implementation methods (or in their embodiments), it can be advantageous to consider the vehicle's state when detecting and / or evaluating intrusions. This allows for a broader context in which events / situations can be considered and, consequently, better evaluated. As known in the prior art, a single control unit of a vehicle's electronic data system can have an intrusion detection system, whereas, in particular, control units are usually developed and distributed independently of the technical systems that integrate them, resulting in a low level of integration and making it virtually impossible to consider a more comprehensive vehicle state. Indeed, for example, the same control unit may be conceived for use in various vehicles, in various vehicle projects, and / or for different vehicle manufacturers (also known as original equipment manufacturers, or OEMs). Furthermore, it can be advantageous to integrate insights from additional control units into intrusion detection and / or evaluation. This, likewise, increases the context and allows for more reliable detection and / or evaluation of intrusions.
[0012] As further proposed in the computer implementation method (or in its embodiments), it may be advantageous to extend the context to a group of vehicles, which may include, for example, a vehicle manufacturer, a vehicle project, and / or a defined vehicle project state (particularly a defined software state). In this case, a server in a network (as described in the second general embodiment) may prove particularly useful because the data and evaluations of the large number of vehicles can be aggregated via a server. On the other hand, a server in a network may already be advantageous for a single vehicle. For example, the computing power and / or storage capacity within a vehicle may be limited, for example, for cost reasons. In contrast, a server may also be provided with (dedicated) hardware necessary for reliable detection and / or evaluation based on data and / or vehicle state.
[0013] Intrusions detected and / or confirmed by the server (and, for example, proposed countermeasures) can be transmitted to the vehicle and / or further vehicles in the vehicle group. Thus, the vehicle and / or further vehicles can respond to the intrusion in a timely manner.
[0014] Servers may have an additional advantage in that intrusion detection systems present in vehicles are often static. Indeed, in intrusion detection systems, for example, for robustness and / or security reasons, static rules / algorithms / data for intrusion detection and / or evaluation are implemented ("hardcoded") at a specific point in development, and these should remain active for the entire operating time. Furthermore, software updates can be performed in-service. However, the race between protection and intrusion often progresses faster than such service intervals. Technically, it would be possible to update such rules / algorithms / data while the vehicle is running, for example, in so-called over-the-air software updates. However, this has not been used at all or very often in practice, particularly because it would create new attack surfaces. In contrast, servers can take new insights into the algorithms for intrusion detection and / or evaluation. [Brief explanation of the drawing]
[0015] [Figure 1] This figure shows an exemplary embodiment comprising at least one vehicle and a vehicle security incident and event management (VSIEM) system. [Figure 2] This diagram schematically illustrates a computer implementation method for detecting and / or evaluating intrusion into a vehicle's electronic data system. [Figure 3] This figure schematically illustrates an embodiment of a computer implementation method for detecting and / or evaluating intrusion into a vehicle's electronic data system. [Figure 4a]This diagram illustrates exemplary functional dependencies for detecting and / or evaluating intrusions into a vehicle's electronic data system. [Figure 4b] This diagram illustrates exemplary functional dependencies for detecting and / or evaluating intrusions into a vehicle's electronic data system. [Figure 4c] This diagram illustrates exemplary functional dependencies for detecting and / or evaluating intrusions into a vehicle's electronic data system. [Figure 4d] This diagram illustrates exemplary functional dependencies for detecting and / or evaluating intrusions into a vehicle's electronic data system. [Figure 4e] This diagram illustrates exemplary functional dependencies for detecting and / or evaluating intrusions into a vehicle's electronic data system. [Modes for carrying out the invention]
[0016] The computer implementation method 100 aims to detect and / or evaluate intrusions into the electronic data systems of a vehicle. This should enhance security or ensure security even as the attack surface expands. In its embodiments, method 100 can be generalized to one or more technical systems, each containing at least one electronic data system, although not necessarily a vehicle.
[0017] Figure 1 visualizes how the context for detecting and / or evaluating intrusions into an electronic data system can be extended from a vehicle's (here, vehicle 1) control unit (here, ECU1, vehicle 1) to further nodes / control units of further vehicles (here, ECU2, ..., vehicle 1) and nodes / control units (here, ECU1, ECU2, ..., vehicle 2, ...). For example, the (further) data can be transmitted from all these nodes / control units to a Vehicle Security Incident and Event Management (VSIEM) system which may be configured to implement computer implementation method 100 (or one embodiment thereof) via optionally one (further) digital twin each (here, digital twin 1, digital twin 2, ...). The VSIEM system may be implemented on server 200.
[0018] Each vehicle and / or each further vehicle may have an intrusion detection system (IDS) within the vehicle, which may be configured to (provisionally) assess the intrusion. For example, each may identify (further) abnormal conditions and transmit them to the VSIEM system.
[0019] Disclosed is a computer-implemented method 100 for detecting and / or evaluating an intrusion into an electronic data system of a vehicle. That is, method 100 may be a method for detecting an intrusion into an electronic data system of a vehicle. Alternatively or additionally, method 100 may be a method for evaluating an intrusion into an electronic data system of a vehicle. This method may include receiving 110 data for each node of a set of nodes of the electronic data system of the vehicle. Method 100 may further include calculating 120 a vehicle state based on the data. The method may further include detecting 130a and / or evaluating 130b an intrusion into the electronic data system of the vehicle based at least on the vehicle state. FIG. 2 schematically shows a computer-implemented method for detecting and / or evaluating an intrusion into an electronic data system of a vehicle. Various embodiments of the computer-implemented method are schematically shown and summarized in FIG. 3.
[0020] The detection of an intrusion into the electronic data system may be based on at least one predetermined detection criterion. The at least one predetermined detection criterion may include a predetermined (static) rule. Alternatively or additionally, the detection of the intrusion may be based on a classification algorithm (e.g., a trained machine learning algorithm such as a support vector machine or an artificial neural network) and / or a regression algorithm (e.g., a trained machine learning algorithm such as an artificial neural network). The detection of an intrusion into the electronic data system may include checking whether there is an abnormality / inconsistency in the data of at least one node of the set of nodes based on at least one predetermined detection criterion. Such a check can be performed at each point in time (e.g., at each interrupt) during the operation of the vehicle (although not necessarily inside the vehicle).
[0021] The evaluation of an intrusion into an electronic data system may be based on at least one predetermined evaluation criterion (and / or at least one predetermined detection criterion). The at least one predetermined evaluation criterion may include a predetermined (static) rule. Alternatively or additionally, the evaluation of the intrusion may be based on a classification algorithm (e.g., a trained machine learning algorithm such as a support vector machine or an artificial neural network) and / or a regression algorithm (e.g., a trained machine learning algorithm such as an artificial neural network). The evaluation of an intrusion into an electronic data system may include examining whether the discovered anomalies / inconsistencies can be confirmed based on data. Such an examination can be performed at each point in time (e.g., at each interrupt) during the operation of the vehicle (although not necessarily inside the vehicle).
[0022] The at least one evaluation criterion may be at least one predetermined detection criterion. The detection of an intrusion may already implicitly include the evaluation of the intrusion.
[0023] The set of nodes of the electronic data system of the vehicle may be a set of control devices of the vehicle that may be network-connected to each other via the electronic data system of the vehicle. Thus, one / each node may be a control device. Alternatively, (at least) one node may be an electronic device that is not necessarily a control device. Thus, such an electronic device does not necessarily need to control a technical (sub)system of the vehicle. The electronic data system may be, for example, a CAN having a CAN bus or may include a CAN bus. The electronic data system may also be a network of electronic data systems. For example, a plurality of CANs etc. can be interconnected via a gateway respectively.
[0024] The data for each node, i.e., for each control unit, may include one or more time records (e.g., time series) that characterize the technical system, in particular the vehicle, and / or its surroundings. One or more time records may, for example, describe information about the behavior of the vehicle and / or its surroundings (e.g., further road users). The time record may, for example, be vehicle speed. Vehicle speed can be used, for example, to assess whether the vehicle is moving or stopped. Further data for each node, see below, may be of the same type as the data, but with the condition that it relates to further vehicles. In Figures 4a to 4e, the data for the first control unit E1 is D1, ... the mth control unit E m Data D m Let's assume that.
[0025] Vehicle status may include information related to intrusion detection and / or evaluation. This information may depend on the vehicle architecture, in addition to information that is universally applicable to the vehicle (e.g., vehicle speed). Furthermore, this information (or parts thereof) may depend on the (specific) vehicle (e.g., the state of software installed in the vehicle). Vehicle status may include driving status. For example, the information may also include the state of one or more nodes (control devices) of an electronic data system. Vehicle status may be a data structure that encodes the information. Alternatively or additionally, vehicle status may include numerical objects such as numbers, vectors, matrices, or tensors. Vehicle status may be encoded as a byte sequence or a bit signal sequence. Vehicle (v) or the first vehicle (v1), ..., nth vehicle (v) in a number of vehicles. n The vehicle status of ) is the mathematical object S v or
number
number
[0026] The detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system may yield results containing information regarding the detection and / or evaluation of intrusion. For example, the results may include an intrusion / non-intrusion bit. Alternatively or additionally, the results may include a (quasi)continuous number (e.g., within the interval [0, 1]) correlated with the probability of intrusion (e.g., 0 for probability 0, or 1 for probability 1). Alternatively or additionally, the results may include an intrusion confirmed / non-intrusion bit. Alternatively or additionally, the results may include, for example, a routine numerical encoding process. The results may be a data structure encoding the information. Alternatively or additionally, the results may include numerical objects such as, for example, numbers, vectors, matrices, or tensors. The results may be encoded as bytes or bit signal sequences.
[0027] The detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system is based at least on the vehicle state, and the result is based at least on the vehicle state S v It can be expressed as the value of a function f that depends on: f(S v ) Method 100 may further include receiving additional data 111 for each further vehicle in a further set of vehicles, and for each node in a set of nodes of the electronic data system of the further vehicles.
[0028] Method 100 may further include calculating a further vehicle state 121 for each further vehicle in the set of further vehicles based on further data of the further vehicle. Detecting 130a and / or evaluating 130b an intrusion into the vehicle's electronic data system may further be based on at least one further vehicle state. The set of further vehicles may be a number of vehicles (except a single vehicle). Each further vehicle may be another vehicle from the set of further vehicles. The electronic data systems of each further vehicle may (but not necessarily) have the same structure with respect to their architecture and / or data (e.g., software state). The set of nodes may be a number of control devices. The set of nodes in the electronic data system of a further vehicle may (but not necessarily) correspond to the set of nodes in the electronic data system of a vehicle.
[0029] The detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system is based on at least one further vehicle state, in this case as well, at least the vehicle state
number
number
number
number
[0030] The vehicle's electronic data system may include (or may be) a control system. The control system may be, for example, CAN. At least one node in the set of nodes of the electronic data system may be an electronic control unit (ECU). The electronic control unit may be configured to control or contribute to the control of an engineering system, in particular the vehicle. The set of nodes of the vehicle's electronic data system may include at least two nodes (e.g., 2, 3, 4, 5, >5, >10, >20, >50, >100, >200). Similarly, the set of nodes of the electronic data system of (each) further vehicle may include at least two nodes (e.g., 2, 3, 4, 5, >5, >10, >20, >50, >100, >200). The set of further vehicles may include at least one further vehicle (e.g., 1, >1, >5, >10, >100, >1e3, >1e4, >1e5, >1e6).
[0031] Calculating the vehicle state based on the data 120 may include supplying data 122a to a digital twin of the vehicle, as schematically shown in Figure 3. Calculation 120 may further include the digital twin calculating the vehicle state 122b. Calculation 120 may further include storing the vehicle state in the digital twin 122c.
[0032] For each further vehicle in a further set of vehicles, calculating a further vehicle state based on further data 121 may include supplying data 123a to a further digital twin of the further vehicle, as schematically shown in Figure 3. For each further vehicle in a further set of vehicles, calculation 121 may further include calculating a further vehicle state 123b by the further digital twin. For each further vehicle in a further set of vehicles, calculation 121 may further include storing the further vehicle state 123c in the further digital twin.
[0033] A digital twin may be a digital representation of a vehicle. Similarly, each further digital twin may be a digital representation of its respective further vehicle. Each digital representation may include a simulation configured to represent its real-world counterpart (i.e., the vehicle or each further vehicle) as best as possible to the extent relevant to intrusion detection and / or evaluation based on (further) data. At each point in the (further) vehicle's operation, the simulation may be extended to that point and, if applicable, compared with (further) data. The advantage can be seen, for example, that an understanding of the (further) vehicle's operation is accumulated over a period of time. This allows for more reliable detection and / or evaluation of intrusions compared to a (real-time) intrusion detection system. As shown in Figure 1, the digital twin (here, digital twin 1) and / or each further digital twin (here, digital twin 2, ...) may (but may not) be implemented on the server 200. When (further) vehicle states are stored 122c, 123c, the (further) digital twins can function as buffers. Furthermore, each of these / further digital twins may be used to buffer one or more (further) evaluation results. For example, (further) relevant driving conditions may be stored and taken into consideration as a comparison in intrusion detection and / or evaluation. Alternatively, the (further) digital twin may also be implemented within the (further) vehicle.
[0034] The vehicle state calculation 120 and / or each further vehicle state calculation 121 can be represented by an inset l, as shown in Figures 4a to 4e. Such an inset may (but may not) include calculation rules from the digital twin and / or calculation rules from each further digital twin.
[0035] As schematically shown in Figure 3, method 100 may optionally include receiving 140 at least one previous vehicle state from a digital twin at a previous point in time. Here, the detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system may further be based on at least one (or more) previous vehicle states. The detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system is further based on at least one previous vehicle state, in this case as well, at least the vehicle state
number
number
number
[0036] If intrusion detection 130a and / or evaluation 130b is based on multiple previous vehicle states of the vehicle, the selection of these multiple previous vehicle states may be implemented by a filter function g, an object (with variations in notation).
number
number
number
[0037] As schematically shown in Figure 3, method 100 may optionally include receiving 141 at least one previous further vehicle state at a previous point in time from a further digital twin, where the detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system may further be based on at least one previous further vehicle state.
[0038] The detection 130a and / or evaluation 130b of intrusion into the vehicle's electronic data system is further based on at least one previous further vehicle state, in this case as well, at least the vehicle state
number
number
number
[0039] If intrusion detection 130a and / or evaluation 130b is based on multiple previous driving states of a further vehicle, the selection of these multiple previous driving states may be implemented by a (further) filter function g, and (variable notation) object
number
number
number
[0040] For an additional n-1 vehicles, if n-1 > 1, the following further dependencies may arise in the results:
number
[0041] As schematically shown in Figure 3, method 100 may include receiving an abnormal condition identified by the vehicle's electronic data system (for example, by an intrusion detection system within the vehicle) 150. Evaluating an intrusion into the vehicle's electronic data system 130b may then further include, and may include, at least an abnormal condition. If at least one predetermined evaluation criterion is met, it may include confirming the abnormal condition 131 and optionally confirming the intrusion. Evaluating an intrusion into the vehicle's electronic data system 130b may further include rejecting the abnormal condition and optionally rejecting the intrusion if at least one predetermined evaluation criterion is not met.
[0042] An abnormal state (or each further abnormal state, see below) may include information regarding intrusion detection and / or evaluation. An abnormal state (or each further abnormal state) may include (provisional) results of intrusion detection and / or evaluation, particularly the results of an intrusion detection system at a low level of integration. For example, an abnormal state (or each further abnormal state) may include an intrusion / non-intrusion bit. Alternatively or additionally, an abnormal state (or each further abnormal state) may include a (quasi)continuous number (e.g., within the interval of real numbers [0, 1]) correlated with the probability of intrusion (e.g., 0 for probability 0, or 1 for probability 1). Alternatively or additionally, an abnormal state (or each further abnormal state) may include an intrusion confirmation / non-intrusion confirmation bit. Alternatively or additionally, an abnormal state (or each further abnormal state) may include, for example, a routine numerical encoding action. An abnormal state (or each further abnormal state) may be a data structure that encodes information. Alternatively or additionally, an anomaly state (or each further anomaly state) may include numerical objects such as numbers, vectors, matrices, or tensors. An anomaly state (or each further anomaly state) may be encoded as a byte sequence or a bit signal sequence. An anomaly state (or each further anomaly state) may, for example, be an anomaly value, or a vector consisting of multiple anomalies and / or intermediate results of intrusion detection / evaluation, in which case the presence of an anomaly may depend on one or more anomalies (for example, anomaly value 0 means no anomaly, while anomaly value 1 is an anomaly, representing the average value from multiple anomalies).
[0043] The assessment 130b of intrusion into the vehicle's electronic data system is further based on at least one abnormal condition, and in this case as well, the result is at least the vehicle's vehicle state
number
number
number
number
[0044] As schematically shown in Figure 3, method 100 may further include receiving 151 further abnormal conditions identified by the electronic data system of each further vehicle in the (second) set of further vehicles (e.g., by an intrusion detection system within the further vehicle). Evaluating an intrusion into the vehicle's electronic data system 130b may further include confirming an abnormal condition 132, optionally confirming an intrusion, and / or confirming at least one further abnormal condition, even if based on at least one further abnormal condition and if at least one predetermined evaluation criterion is met. In this case, an intrusion into the vehicle's electronic data system does not necessarily have to exist. Instead, intrusions detected and confirmed in further vehicles may be processed in advance in the vehicle. For example, the vehicle user may be warned about a possible intrusion and / or asked to visit a service (e.g., for a software update). Evaluating an intrusion into the vehicle's electronic data system 130b may further include rejecting at least one further abnormal condition and optionally rejecting an intrusion, if at least one predetermined evaluation criterion is not met. The (second) set of further vehicles may be another set of further vehicles, but may not be.
[0045] The assessment 130b of the intrusion into the vehicle's electronic data system is further based on at least one additional abnormal condition, and in this case as well, the result is at least the vehicle's vehicle state
number
number
number
number
number
[0046] Detection of intrusion into the vehicle's electronic data system 130a may occur if at least one predetermined detection criterion is met. On the other hand, if at least one predetermined detection criterion is not met, non-intrusion may exist.
[0047] A detected intrusion 130a and / or a confirmed (131, 132) intrusion, and optionally a non-intrusion evaluated 130b, may be transmitted to the vehicle's electronic data system. In the case of a detected intrusion 130a and / or a confirmed (131, 132) intrusion, at least one node of the electronic data system, and optionally at least one control device, may notify the vehicle's user (e.g., driver and / or occupant) of the intrusion and / or initiate a driving operation corresponding to the intrusion (e.g., depending on the result).
[0048] As schematically shown in Figure 3, receiving 110 node-by-node data from a set of nodes in the vehicle's electronic data system may include receiving 112a and decompressing 112b compressed data from each node in the set of nodes in the vehicle's electronic data system. In this case, the data is compressed within the vehicle before transmission (to the server 200). The data compression may be lossless.
[0049] For at least one of the sets of further vehicles, or for each of the further vehicles, receiving 111 further data per node of the set of nodes of the further vehicle's electronic data system, as schematically shown in Figure 3, may include receiving 113a and decompressing 113b losslessly compressed further data per node of the set of nodes of the further vehicle's electronic data system. In this case, each further data is compressed within each further vehicle before transmission (to the server 200). The compression of the further data may also be lossless.
[0050] Data or further data compression can be represented by inset h, as shown in Figures 4a to 4e. The compressed data is D v (or
number
[0051] Basically, all data (e.g., results, abnormal conditions, etc.) can be transmitted in a compressed state between the vehicle and server 200, or between further vehicles and server 200. Typically, results and / or abnormal conditions do not require compression because they do not require a large data size compared to (further data).
[0052] Further disclosed is a server 200 in a network configured to implement a computer implementation method 100 for detecting and / or evaluating intrusions into a vehicle's electronic data system, the vehicle's electronic data system, and optionally, each electronic data system of each further vehicle in a further set of vehicles, connected to the network. In other words, the server can function as a link between vehicles. The network may be, for example, a wireless network, in particular 4G, 5G, 6G, ... Each vehicle and / or each further vehicle may include a communication interface configured to communicate with the server 200 in the network (for example, according to a predetermined protocol), thereby allowing it to transmit data or further data (for example, losslessly compressed) to the server 200. On the other hand, the server 200 may, for example, return the results of detecting and / or evaluating an intrusion into a vehicle (or further vehicle). The server 200 may be a cloud server. As shown in Figure 1, for example, a Vehicle Security Incident and Event Management (VSIEM) system may be implemented on the server 200. Furthermore, a digital twin of the vehicle (digital twin 1 in Figure 1), and optionally, further digital twins for each individual vehicle (for example, digital twin 2 in Figure 1), may be implemented on the server 200.
[0053] Server 200 can provide more reliable intrusion detection and / or assessment thanks to its greater computing and / or storage capacity. Furthermore, additional data (e.g., software update policies, system identifiers, etc., for preventative broadcasts of further vehicle issues) may be exchanged with the vehicle and / or (further) vehicles via Server 200. This additional data may be considered in the detection and / or assessment of intrusions into the vehicle's electronic data systems.
[0054] Further disclosed are vehicles (or each further vehicle) that include an electronic data system protected in accordance with a computer implementation method 100 for detecting and / or evaluating intrusion into the vehicle's electronic data system.
[0055] Disclosed is at least one computer program configured to implement a computer implementation method 100 for detecting and / or evaluating intrusion into a vehicle's electronic data system. The computer program may be, for example, in an interpretable form or in a compiled form. It may be loaded (partially) for implementation in the RAM of a control device or computer, for example, as a bit or byte sequence, and the computer may also function as a server 200.
[0056] Further disclosed are computer-readable media or signals that store and / or contain at least one computer program. The media may include, for example, RAM, ROM, EPROM, ... on which the signals are stored.
[0057] Further disclosed is a computer system configured to run a computer program. In particular, the computer system may include at least one processor and at least one main memory. Furthermore, the computer system may include memory. The computer system may extend to an entire system consisting of a vehicle, optionally further vehicles, and a server 200. [Explanation of Symbols]
[0058] 200 servers 100 Computer Implementation Methods, Methods 110 Received 111 Received 112a Received 112b Unzip 113a Received 113b Unzip 120 calculations 121 Calculation 123a supply 123b calculation 123c memory 130a detection 130b rating 131 Confirmation 132 Confirmation 140 received 141 Received 150 received 151 Received
Claims
1. 1. A computer-implemented method (100) for detecting and / or assessing an intrusion into an electronic data system of a vehicle, comprising: - receiving (110) data for each node of the set of nodes of the electronic data system of the vehicle; - calculating (120) a vehicle state based on said data; - detecting (130a) and / or assessing (130b) an intrusion into said electronic data system of said vehicle based at least on said vehicle state; A method (100).
2. - receiving (111) for each further vehicle of the set of further vehicles further data for each node of the set of nodes of the electronic data system of said further vehicles; - for each further vehicle of the set of further vehicles, calculating (121) a further vehicle state based on the further data of said further vehicles, The method (100) of claim 1 , wherein detecting (130a) and / or assessing (130b) the intrusion into the electronic data system of the vehicle is based on at least one further vehicle condition.
3. The method (100) of claim 1 , wherein the electronic data system of the vehicle includes a control system, and at least one node of the set of nodes of the electronic data system is an electronic control unit (ECU).
4. The method of claim 1 , wherein the set of nodes of the electronic data system of the vehicle includes at least two nodes.
5. The method (100) of claim 2, wherein the collection of additional vehicles includes at least one additional vehicle.
6. The step of calculating (120) the vehicle state based on the data comprises: - Providing (122a) said data to a digital twin of said vehicle; - calculating (122b) said vehicle state by means of said digital twin; Optionally, storing (122c) the vehicle state in the digital twin, 2. The method of claim 1 (100).
7. Calculating (121) for each further vehicle of the set of further vehicles, the further vehicle state based on the further data, - providing (123a) said data to a further digital twin of said further vehicle; - calculating (123b) said further vehicle state by means of said further digital twin; Optionally, storing (123c) said further vehicle state in said further digital twin, 3. The method (100) of claim 2.
8. - optionally receiving (140) from said digital twin at least one previous vehicle state at a previous time, Detecting (130a) and / or assessing (130b) the intrusion into the electronic data system of the vehicle is based at least on the at least one previous vehicle state.
7. The method (100) of claim 6.
9. - receiving (141) optionally from said further digital twin at least one previous further vehicle state at a previous time, Detecting (130a) and / or assessing (130b) the intrusion into the electronic data system of the vehicle may further comprise:
8. The method (100) of claim 7.
10. receiving (150) an abnormal condition identified by the electronic data system of the vehicle, evaluating (130b) the intrusion into the electronic data system of the vehicle further comprises at least the abnormal condition based on and including at least the abnormal condition; - confirming (131) said abnormal condition if at least one predetermined evaluation criterion is met, optionally confirming said intrusion, 2. The method of claim 1 (100).
11. Detecting (130a) the intrusion into the electronic data system of the vehicle occurs when at least one predetermined detection criterion is met.
2. The method of claim 1 (100).
12. 2. The method (100) of claim 1, wherein the detected (130a) and / or confirmed (131, 132) intrusions, and optionally the evaluated (130b) non-intrusions, are transmitted to the electronic data system of the vehicle.
13. 13. The method (100) according to claim 12, wherein in the event of a detected (130a) and / or confirmed (131, 132) intrusion, at least one node of the electronic data system, and optionally at least one control device, notifies a user of the vehicle about the intrusion and / or initiates a driving maneuver corresponding to the intrusion.
14. A server (200) in a network configured to implement a computer-implemented method (100) for detecting and / or assessing intrusions into the electronic data system of a vehicle as claimed in any one of claims 1 to 13, wherein the electronic data system of the vehicle and, optionally, each electronic data system for each further vehicle of a set of further vehicles are connected to the network.
15. The digital twin of the vehicle, and optionally each further digital twin for each further vehicle, is implemented on the server (200). The server (200) of claim 14.
16. A vehicle including an electronic data system protected according to a computer-implemented method (100) for detecting and / or assessing an intrusion into the electronic data system of the vehicle according to any one of claims 1 to 13.