Method for handling data anomalies, particularly in motor vehicles

Abstract

A method for processing data anomalies, in particular in a motor vehicle, is proposed, wherein at least one sensor (24, 26, 28) for detecting anomalies acquires data (211), wherein the sensor (24, 26, 28) checks the acquired data (211) for the presence of anomalies, and upon detection of an anomaly an event (220, 221) is generated based on the associated data (211), wherein a random decision is made as to whether the event (220, 221) is to be further processed, in particular stored and / or at least partially further transmitted.

Description

Technical Field

[0001] The invention relates to a method for handling data anomalies, in particular in a motor vehicle. Background Art

[0002] DE 102018209407 A1 discloses a device and a method for processing anomalies in a communication network, in particular in a communication network of a motor vehicle. At least one detector analyzes a data stream in the communication network, wherein the at least one detector detects at least one anomaly by a rule-based anomaly detection method if at least one parameter of a data packet in the data stream deviates from a nominal value, wherein the at least one detector sends information about the at least one detected anomaly via the communication network.

[0003] In particular, the automatic creation of protocols, history records or reports (log records) when anomalies or events are identified should be carried out in the case of high event rates and / or long-term attacks without overloading and denying the corresponding services. The entries in the log records or corresponding event reports should be true, complete and available. If possible, a non-deterministic history record about the complete (long-lasting) attack should be created for the attacker. Manipulation and especially deletion by the attacker should be avoided. Outside the control device, the log record entries should be protected from unauthorized analysis. The log recorder should reliably send event reports, for example via an interface to an external node. After successful transmission to the external node, the event entry can be deleted locally, particularly preferably after the receiving instance has been confirmed, especially authenticated. In addition, the log recorder should send a so-called heartbeat signal, which shows the network connection. The accumulation of events should be feasible to reduce the number of log record entries to be processed.

[0004] Under normal operating conditions, events are not triggered or are triggered very rarely, for example in the order of one event per hour. In the worst case, an attacker can completely control an interface, in particular an Ethernet interface. At a full bandwidth of, for example, 100 Mbit, an attacker can send up to 128,000 UDP (User Datagram Protocol, a network protocol) frames per second. Each of these frames can trigger an event (anomaly detected in the data stream). It is assumed that such an attack occurs with a frequency of one attack during the life cycle of the vehicle. The permissible number of so-called write cycles of memories, in particular flash memories, is limited and must be taken into account. Likewise, the number of effective operating hours is also limited. Likewise, the availability of a superordinate external data logger is also limited. Therefore, the corresponding logging events or event reports must be buffered. All logging entries or event reports should be able to be transmitted to the superordinate data logger at least once a day.

[0005] For traditional IDS or IDPS systems (Intrusion Detection System, a system for automatically identifying attacks on computer networks or computer interfaces; or IDPS: Intrusion Detection Prevention System, which does not forward the corresponding data when an intrusion attempt is identified, thereby preventing the intrusion attempt), the deterministic behavior and limited resources of embedded systems are often problematic.

[0006] On the contrary, it is desirable to specify an improved method for detecting anomalies. This object is achieved by the features of the independent claims. Summary of the invention

[0007] This is achieved by a method according to the features of the independent claim.

[0008] By randomly deciding whether the event is to be processed further, in particular to be at least partially stored in a memory and / or in particular to be reduced, the processing of the event can be further hidden in a manner that cannot be understood by an attacker. The events are thus selected in a non-deterministic manner for the attacker. A reduction of events is thus performed. The further processing of the selected events is thus simplified.

[0009] In an expedient development, provision is made for the random decision to use random numbers and / or random number ranges, in particular vehicle-specific and / or control unit-specific random numbers. This ensures a non-deterministic anomaly reduction behavior. Even if the random numbers are public in one vehicle, the knowledge gained cannot be transferred to other vehicles. By using different random numbers in a convoy, it is ensured that different events are selected for each vehicle. In the event of a convoy attack, this increases the data diversity and enables a more extensive assessment or complete reconstruction of the attack.

[0010] In an expedient development, it is provided that the events to be further processed are at least partially stored in a memory, in particular a volatile memory or a buffer memory and / or a non-volatile memory. In the absence of a connection to a superordinate unit or in a change to another system state, the events can be saved locally. This can also be done via a permanent memory.

[0011] In a suitable extension, it is provided that the events to be further processed are selected according to the filling level of the memory. Thus, when the filling level of the memory is low, more events can be selected than when the filling level of the memory is high. Thus, memory overflow can be prevented. In addition, an overall understanding of the entire duration of the attack is ensured. Thus, system limitations or temporary limitations, such as limitations related to the connection or data rate of the superior instance, can be compensated. This is a self-regulating system. For example, if the filling level of the buffer decreases again, more events are selected again. For this purpose, it is particularly suitable to provide that the number or offset of events from which the events to be further processed are randomly selected depends on the filling level of the memory, in particular when the filling level of the memory is low, the events to be stored are selected from a small number of events. It is particularly suitable to provide that the memory includes at least two storage areas, each of which is assigned a different number or offset of events, and the events to be stored are randomly selected from these events.

[0012] In a suitable extension, it is provided that the event to be further processed is randomly selected according to the range of random numbers. Thus, random numbers can be used particularly effectively and for a long time by accessing different areas. The consumption of random number bits is low. The range to be considered of random numbers is directly related to the filling level of the buffer. A simpler, more effective and faster processing mechanism is obtained from this. It is particularly suitable to provide that a temporary range of random numbers is first selected, the random number based on the temporary range is compared with the associated offset, and if the random number based on the temporary range is greater than the offset, the temporary range is reduced by one section and used as the range of random numbers, in particular by omitting the high significant bit. This contributes to the optimal use of random numbers in a particularly simple manner. It is particularly suitable to provide that the section to which the temporary range is reduced is the next temporary range or a part of the next range.

[0013] In an expedient development, it is provided that the random number is regenerated periodically and / or as a function of certain system events, such as changes in system states, such as reset, startup, changeover to sleep mode, etc. This further increases the safety of the device.

[0014] In a suitable extension, it is provided that an event type is determined for an event, and for an event having an event type that has already occurred in a previous event, it is randomly decided whether the event is to be further processed. Thus, the event is selected in a non-deterministic manner for the attacker, but the first occurrence of the event is always reliably selected in advance.

[0015] In an expedient development, it is provided that a plurality of sensors are provided for detecting anomalies, each sensor receiving data from a different data source, in particular a communication system and / or a host or a microcontroller, wherein each sensor checks the received data for anomalies, generates an event based on the associated data when an anomaly is detected, and forwards the event to an event manager. As a result, the different data sources can be evaluated at a higher level and combined within the scope of an event report.

[0016] In particular, by randomly selecting the events to be further processed or to be selected, deterministic and therefore predictable behavior for an attacker is removed. Similarly, random preselection, for example, by randomly selecting the useful data area to be forwarded, also contributes to further security. It is also possible to always equip the data exchange for sending event reports with constantly changing variables, so that an attacker cannot infer the type of data transmitted, especially in the case of further encryption. It is precisely through the specific selection or priority setting of the events to be further processed that the overflow of the memory when a large number of events occur is prevented from causing the inability to record important events. This can be achieved in a particularly effective manner, in particular by selecting the events to be further processed according to the filling level of the memory. Particularly preferably, more events are selected when the filling level of the memory is low than when the filling level of the memory is high. Particularly preferably, at least one first event (about a specific event type) is selected, so that the occurrence of all event types can be overviewed. In addition, it is advantageous to set an event counter because additional information, such as the number of all occurring events and / or the number of corresponding different events, can be collected with little memory consumption. In addition, specific priority groups can be assigned to event types, so that events in higher priority groups are selected more frequently than events in lower priority groups. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Further advantageous embodiments emerge from the other dependent claims as well as from the following description and the drawings.

[0018] Figure 1 shows the schematic components of anomaly identification,

[0019] Figure 2 shows an exemplary structure or interaction of received data, an exemplary structure or interaction of events derived from said data, the structure of associated selected events, and event reports,

[0020] Figure 3 shows a more accurate structure of the event manager,

[0021] Figure 4 shows a flow chart for selecting events to be further processed,

[0022] Figure 5 A flowchart showing the counter incrementing,

[0023] Figure 6 A flowchart showing storage of non-volatile memory,

[0024] Figure 7 shows a schematic overview of randomly selecting events to be stored,

[0025] Figure 8 Shows Figure 7 The assignment of specific variables used in

[0026] Figure 9-14 Different communication flows between the event manager, the communication adapter, further IDS instances and the backend are shown. DETAILED DESCRIPTION

[0027] In conjunction with the aspects described below, deviations from normal behavior are referred to below as anomalies, which may occur in real operation for various reasons in data 211 of a networked system, such as data of a communication system or system data. The causes of this may be, for example, of the following type: defective or completely failed sensors provide erroneous data or no data at all, system components are damaged, the system is manipulated by external attacks, local attacks or physical attacks (such as hacker attacks).

[0028] Identifying anomalies in the data 211 is achieved with the aid of so-called intrusion detection systems IDS or IDPS. In the following, IDS refers to a system that monitors the anomalies of the data 211. The data can be, for example, data 211 during a data connection in a communication network, via which a control device 20 such as a gateway communicates on different communication channels (for example, via a bus system such as 25 or the Internet 27). However, other data 211, such as system data in a control device (or a host 29 or a microcontroller or a processor arranged in the control device or in a chip) should also be checked for anomalies by the IDS system. Detecting anomalies in the data 211 is performed by suitable sensors 24, 26, 28. The sensors 24, 26, 28 are adapted to the corresponding sources of the data 211 (in the embodiment, the bus systems 25, 27 or the host 29).

[0029] according to Figure 1, a control device such as a gateway 20 is arranged in a vehicle 18. The control device or gateway 20 includes (multiple) processors, memories, working memories (for example as a component of a host system 29) and interfaces for communicating via a communication network. The gateway 20 processes instructions for data connections, for example. Data 211 in the form of data packets is generated by this communication. Data 211, such as system data, is also generated during the operation of the host 29. In the normal state, the rated values ​​for the frequency of occurrence or frequency of the data 211 of a specific data packet, such as the recipient address and the destination address, whether the correct program flow (for example for the host 29), the time stamp, the data of the data packet are observed. The data 211 of the data packet is exchanged between other control devices or components not shown in detail in the vehicle 18 to complete specific tasks. The gateway 20 is used to couple multiple communication systems or interfaces such as a CAN bus 25, an Ethernet connection 27 and a data connection to the host system 29, which is a component of the control device 20 or the gateway. However, other communication systems (e.g., another wired bus system, such as LIN, CAN-FD, etc.) or wireless networks (e.g., WLAN or Bluetooth) can be coupled to each other via the gateway 20 for data exchange. Typically, intrusion identification IDS or anomaly identification is used in the control device to monitor whether all data 211 (data 211 received through the communication system and data 211 generated by the host 29 within the control device 20) have corresponding anomalies. In the embodiment, the IDS functional mechanism is described exemplarily for the gateway 20. However, in general, the functions of the described anomaly identification or intrusion identification IDS can be implemented in any control device or any electronic component. In particular, the use is not limited to the vehicle 18. On the contrary, any communication component, such as a communication module in the Internet (Internet of Things) or in a networked production system can be equipped with the described functions.

[0030] A communication component, such as a control device or a gateway 20, comprises at least one anomaly detection 22. Data 211 input via the interface of the corresponding communication system 25, 27, 29 are respectively guided via so-called sensors 24, 26, 28 for detecting anomalies or detecting intrusions (IDS sensors for short). Corresponding sensors 24, 26, 28 are thus arranged in the gateway 20. Such sensors 24, 26, 28 are used to detect whether the acquired data 211 show anomalies. For this purpose, corresponding filter algorithms or rule sets are stored in the sensors 24, 26, 28 for detecting and classifying anomalies. If the sensor 24, 26, 28 determines an anomaly, the corresponding data packet of the data 211 is classified as an event 220 (attempted intrusion). In general, depending on the source 25, 27, 29, the sensor 24, 26, 28 can classify different anomalies as events 220 (assign the corresponding event 220 to a specific event type 218) and recognize these anomalies. According to the corresponding event type 218 (different abnormality types in the data 211), the sensors 24, 26, 28 aggregate specific event-related metadata 216 into associated events 220. In addition, the event-related metadata 216 can also contain data or data components of the abnormal data 211. The events 220 generated in this way are forwarded to the event manager 30. The sensors 24, 26, 28 are usually designed to forward the associated data 211 of the communication system (for example, the bus system 25, 27) to the specified address in the absence of abnormalities. In the case of an abnormality, the sensors 24, 26, 28 can be designed not to forward the associated data 211 of the communication system (for example, the bus system 25, 27) to the specified address. Alternatively, the sensors 24, 26, 28 can also be used to reduce the events 220 (reduced events or pre-reduced events 221). The burden on the event manager 30 can be relieved by this reduction, for example, by only forwarding the data 211 containing the abnormality or a small part of the useful data of the data packet. This is particularly advantageous in the case of large amounts of data, as occurs in Ethernet connections.

[0031] Thus, for example, the IDS CAN sensor 24 is used to detect anomalies in the case of the CAN bus 25, the IDS Ethernet sensor 26 is used to detect anomalies in the case of the Ethernet system 27, and the IDS host sensor 28 is used to detect anomalies in the case of the host system 29. Depending on the different communication paths and communication protocols, further IDS sensors can also be provided, which are able to detect anomalies or sources of anomalies in the corresponding sources and classify them if necessary.

[0032] The IDS CAN sensor 24 detects events 220 associated with the associated event type 218, such as invalid CAN-ID, invalid message frequency, invalid message length, etc. The IDS Ethernet sensor 26 detects events 220 associated with the associated event type 218 for the Ethernet 27, such as invalid address or MAC address, invalid message frequency, invalid message length, etc. The IDS Host sensor 28 detects events 220 associated with the associated event type 218 for the host system 29, such as invalid code execution, program corruption, stack counter, etc. The respective event type 218 is usually provided with an event-specific event ID. There are a large number of predefined event types 218 for different data sources with associated unique event IDs.

[0033] The following additional anomalies can be considered as events 220 for additional event types 218. For example, these are events 220 or event types 218 that can be assigned to a firewall, such as frame loss due to buffer memory full, filter violation (stateless / stateful), transmission rate limit effective or invalid, monitoring mode activated or deactivated, context change. Additional anomalies involving the host system 29 can also be considered as events 220 with associated event types 218, such as CPU load too high, memory access violation, error in code execution, ECU reset detected, log entry in non-volatile memory corrupted, logging memory overflow, rejection of event, MAC address port change, etc.

[0034] The event manager 30 is used to further process the input events 220 or the event-related metadata 215 contained in the corresponding events 220. In particular, the event manager 30 is used to aggregate, format or prepare the events 220 and / or prioritize and / or reduce / select and / or store or retain or permanently store the selected and / or reduced events 220, 221. In particular, the event manager 30 determines which input events 220 should be further processed. The events selected from the input events 220 are called selected events 226. The corresponding selection should be carried out as non-deterministically as possible. In addition, the event manager 30 particularly preferably sets additional general metadata 217 for the input events 220 or the selected events 226. The events 220 transmitted by different sensors 24, 26, 28 can thus be observed at a higher level, for example, by adding the number of events that occur, the associated timestamp or time signal 224, etc. in the scope of the general metadata 217. Furthermore, it is ensured that even in the case of so-called event bursts, sufficiently many significant events 220 can be stored as selected events 226 .

[0035] The event manager 30 exchanges signals with a communication adapter 32 of intrusion recognition or anomaly recognition. The communication adapter 32 serves as a communication device for exchanging data between the event manager 30 and other components 34, 36 other than the anomaly recognition 22 of the control device or gateway 20. Specifically, the communication adapter 32 serves as an interface for exchanging data between the event manager 30 and another IDS instance 34 (preferably in the vehicle 18) and / or a backend 36 (preferably outside the vehicle 18). The other IDS instance 34 can only be provided optionally.

[0036] To increase security, the event manager 30 can perform random, non-deterministic and hidden reduction and prioritization of the events 220, 221. Thus, non-volatile storage of selected events 226 can be performed randomly, non-deterministically and hidden from an attacker. The selection of random control can be based on a random number 273 that is individual to a specific control device, for example. Similarly, the event manager 30 can also randomly store the counter reading 231 of the event counter 204. In addition to the event-related metadata 216, the event manager 30 also randomly stores the added general metadata 217 as the selected event 226.

[0037] In order to increase security, the communication adapter 32 can upload or send the event report 242 to other IDS instances 34 randomly, non-deterministically and hidden from attackers. The randomly controlled upload can be based on a random number 273 that is individual to a specific control device (or gateway 20), for example. Thus, specific events 220 can be transmitted periodically and encrypted within the scope of the event report 242. However, even if there are no new events 220, so-called virtual events can also be transmitted periodically and encrypted in the format of the event report 242. This is used to prevent the data exchange between the communication adapter 32 and another IDS instance 34 or the back end 36 from being eavesdropped or randomly hidden.

[0038] Combination Figure 2 It is shown by way of example how, in the event of a detected anomaly, data 211 are further processed by sensors 24 , 26 , 28 and sent to event manager 30 , until the latter sends an event report 242 via communication adapter 32 .

[0039] exist Figure 2 FIG. 1 shows a data packet of data 211, which may appear in a network frame (eg, CAN, Ethernet). Data 211 has a header 214 including, for example, a source address and a destination address (eg, MACa, MACb). In addition, data 211 includes useful data 213.

[0040] As described in more detail below, the sensor 24, 26, 28 may optionally randomly select a useful data area 219 to forward to the event manager 30. The sensor 24, 26, 28 has determined that this is an anomaly according to a specific event type 218 (event ID, ID). Therefore, the sensor 24, 26, 28 generates a message such as Figure 2 b. Depending on the event type 218 (or ID), different information about the anomaly can be stored in the event-related metadata 216. In an embodiment, the event-related metadata 216 includes, in particular, the source address and the destination address (MACa, MACb), the event type 218 and the selected useful data area 219.

[0041] Alternatively, event-related useful data 213 may also be forwarded in their entirety to event manager 30 within the scope of event 220 .

[0042] Alternatively, the event 220 may also not include event-related useful data 213, for example when the host 29 is used as the source. This may be an event type 218, such as information about lost data frames due to a full buffer, activation or deactivation of an observation mode, too high a load on the CPU, a corrupted entry in the non-volatile memory 208, an overflow of the logging buffer, event reduction being active, etc.

[0043] In addition, for different event types 218, additional event-related information within the scope of event-related metadata 216 may be a component of event 220. In the case of event type 218 "context change", event-related metadata 216 may, for example, include a context, such as a 32-bit context. In the case of event type 218 "memory access violation" or "violation when executing code", event-related metadata 216 may, for example, include an access address (e.g., 32 bits), a program counter (e.g., 32 bits), a task ID (e.g., 8 bits). In the case of event type 218 "control device reset detected", event-related metadata 216 may, for example, include a reason for the reset (e.g., 8 bits), such as POR (point of return), software reset, exception, etc.

[0044] The following Ethernet-related events 220 may be recorded as event-related metadata 216, such as static / state-related filter violations (specific rule ID or ID of specific event type 218, e.g. 16 bits), ID of the filter rule that caused the event 220 (if available), physical port address, physical port ID via which the frame was obtained, source address (e.g. MAC address, e.g. 48 bits), destination address (e.g. MAC address, e.g. 48 bits), possible IP address of the source or destination, designation of the UDP / TCP port (e.g. 16 bits, if present in the frame, optional). Alternatively, static / state-related filter violations may also be recorded together, such as rule ID, physical port, frame (number of bytes), specific number of bytes in which the received frame is stored, selected useful data area 219 (specific number of bytes), bytes of the selected useful data area 219 of the original frame, useful data area 219-index (e.g. 16 bits), start byte of the selected useful data area 219 in the original frame. Additional Ethernet related events may also be included in the event 220 transmitted to the event manager 30, such as for event type 218 "Transmission rate limited (valid / invalid)" the rule ID with the associated ID of the filter rule that caused the event 220, for event type 218 "Change context" the context (e.g. 32 bits), for event type 218 "Address hop" or "MAC hop" the old port (physical port ID originally assigned to the address), the new port (physical port ID where the address was most recently observed), the address (preferably the MAC address). However, event types 218 without metadata 216 may also appear, such as "Frame lost due to buffer full", etc.

[0045] The forwarding of event-related useful data 213 thus depends in particular on the origin of data 211 with associated event type 218. Metadata 216 are transmitted to event manager 30 as events 220 or reduced events 221 (due to random selection or reduction of useful data areas 219 to be transmitted in sensors 24, 26, 28).

[0046] If the event manager 30 selects the event 220, 221 for further processing (selected event 226), as explained in more detail below, the general metadata 217 is also added to the event-related metadata 216, thereby generating Figure 2c. The general metadata 217 is usually generated in the event manager 30. This is, for example, the output signal of the event counter 204, that is, the current counter reading 231, how many global events 220 there are or how many events of the current event 220 have a specific event type 218. In addition, the general metadata 217 may include, for example, a time signal 224 about when the event 220 occurred. In addition, the metadata 217 may include the length 232 (the size of the data) of the event-related metadata 216 or the complete metadata 215. This is beneficial for the memory management of the buffer memory 206 later.

[0047] The following general metadata 217 is proposed by way of example. This can be, for example, an event type 218 in the range of an event ID (e.g., 8 bits). This event ID of the event type 218 is unique and can, for example, include a TLV-based encoding (TLV: Type-Length-Value). The general metadata 217 includes a length 232, for example, a size between 8 and 16 bits. The size of the data (metadata 215) follows the length field in bytes, up to 255 bytes. TLV-based encoding can again be provided. A time signal 224, i.e., a timestamp (e.g., 64 bits), is also included. For example, the time 224 is indicated in the form of an absolute time value (in milliseconds) that has passed since a reference time point such as January 1, 1970, in order to indicate a unique timestamp. Furthermore, the general metadata 217 may include a counter reading 231 or output value 231 (e.g. 32 bits) of an event type counter 204 and / or a counter reading 231 (e.g. 32 bits) of a global (event) counter 204 , the sum of all counter readings 231 of the event counter 204 for each event type 218 .

[0048] The event-related metadata 216 are taken over in the form in which the corresponding sensors 24, 26, 28 generate them. This event 220 with the corresponding metadata 215 generated both by the sensors 24, 26, 28 and by the event manager 30 is stored in the buffer memory 206 of the event manager 30. In a similar manner, further events 226 (in the case of the event manager 30 selected or reduced according to the event manager 30) are stored in the buffer memory 206 of the event manager 30. Figure 2 d (in the exemplary embodiment of FIG. 4 ) are exemplarily indicated as 215_1 , 215_8 , 215_190 ) in the buffer memory 206 , as will be explained in more detail below.

[0049] Selected events 226 (in accordance with Figure 2d in the embodiment of the present invention, exemplarily represented as 215_1, 215_8, 215_190 (metadata 215 event number 1, metadata 215 event number 8, metadata 215 event number 190) as examples of selected events 226, an event report 242 is now generated. The event report includes the selected events 226 (in this example, 215_1, 215_8, 215_190) stored in the buffer memory 206. These selected events 226 were previously variables 254 (such as random numbers, times or counters, etc.) that have changed with respect to each event report 242. In addition, the event report 242 also includes authentication information 256. This authentication information can be used to authenticate between the communication adapter 32 or the event manager 30 and the unit (IDS instance 34, backend 36, etc.) that receives the event report 242. The event report 242 includes a fixed length 258. In order to achieve this fixed length 258, the data 254, 215_1, 215_8, 215_190, 256 are still filled with so-called filling data 255. These filling data 255 do not contain any information related to the event. Figure 2 d, prior to transmission, the data shown in event report 242 is provided with encryption 258. Event report 242 encrypted in this manner by encryption 258 is sent by communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36, as described.

[0050] The IDS sensors 24, 26, 28 forward the events 220 or the reduced events 221 to the event manager 30. Especially in Ethernet networks, in the case of an attack attempt, when there are a large number of events 220 to be forwarded with a large data volume or event-related metadata 216, the memory 206, in particular the volatile memory or the buffer memory 206, may quickly no longer be able to accommodate all the events 220. This is due to the high data transmission rate or the large amount of data that can be transmitted. Therefore, it makes sense that one or more IDS sensors 24, 26, 28 have preselected the events to be forwarded 220 and / or the data reduction (reduced events 221) according to specific criteria. These criteria should be characterized by low predictability.

[0051] In the case of IDS sensors 24, 26, 28, in particular in the case of IDS Ethernet sensors 26, it is preferred to select specific events 220 to be forwarded and / or reduce the events to reduced events 221 in a randomly controlled manner in order to increase security. The random or arbitrary selection or reduction of specific events 220 or data blocks of Ethernet frames is non-deterministic and hidden for an attacker. The randomly controlled selection or reduction can be based on a random number 273 that is individual to a specific control device, for example. In the simplest case, the same random number 273 can also be used for other random-based scenarios, as a reference in the event manager 30 for the reduction or prioritization of all events 220, the random storage of events 220, etc. Alternatively, the corresponding random number can also be regenerated in the control device.

[0052] The incoming message or data 211 usually has corresponding header information 214 (e.g. specific address data) and subsequent useful data 213. Usually, a lot of header information is contained that is not absolutely necessary for the anomaly assessment. According to the present invention, only the absolutely necessary specific address parts are forwarded as components of the reduced event 221 within the scope of the event-related metadata 216, such as the address of the source (e.g. MAC address, e.g. 48 bits), the address of the target (e.g. MAC address, e.g. 48 bits) and the ID number that caused the anomaly (event type 218). Other information - such as the physical port or port ID at which the frame was received, the IP address of the source or target, the information about the UDP / TCP port of the source or target (if such information is contained in the frame) - does not need to be or need not be transmitted in full in the event 220.

[0053] However, the useful data area 219 to be forwarded or selected is randomly selected from the useful data 213 of the input data 211, such as the one already combined with the Figure 2a and 2b explained. Thus, for example, the number of the start data (the beginning of the storage area to be transmitted of the useful data, such as the byte number xyz) can be randomly set (for example, the data area whose initial value is randomly determined is transmitted, such as the useful data byte number 538 for this event 220). The offset of the selected useful data area 219 (the number of data transmitted, such as 10 bytes) can be fixedly selected. Thus, in addition to the minimum address information (source address, target address), the useful data bytes numbered 538-547 are forwarded to the event manager 30 as the selected useful data area 219 in the scope of the event 221 reduced in this way. Alternatively, the offset of the selected useful data area 219 (the number of useful data transmitted) can also be changed, preferably randomly. Preferably, the starting area or end area of ​​the selected useful data area 219, in particular the selected useful data area 219, depends on the random number 273. The random number 273 is particularly preferably dependent on the control device or the gateway 20. Particularly preferably, the random number 273 is unique, that is, it is only given once for this special control device.

[0054] However, the random number 273 can also be updated optionally. This results in the following advantages. By updating the random number, different events 220 are recorded or selected in the case of identical attack sequences (sequences of events 220). This is also the case when the attack is directed only at a single control device / vehicle 18 and not at the entire fleet. The following assumptions / examples:

[0055] 1. Repeating the same attack sequence multiple times (Event 220 sequence)

[0056] 2. Update the random number 273 between attack sequences

[0057] 3. Not all events 220 can be recorded or selected within the scope of an attack sequence (event burst). This is followed by event reduction for event reporting 242

[0058] 4. The event report 242 with the reduced events 221 is completely forwarded between two attack sequences to the superordinate instance 34, 36. As a result, after multiple repetitions of the same attack sequence, the complete attack sequence can be reconstructed via the event report 242.

[0059] The sensor 26 can preferably adapt the selection of the random number 273 or the different regions of the random number 273 to the size of the input data 211, in particular to the size of the input useful data 213. If the useful data 213 has a small data area, the random number 273 must be selected so that the selection of a specific reduced useful data area 219 also only falls within this small data area of ​​the useful data 213. Therefore, the random number 273 or the region of the random number 273 considered must be correspondingly small. However, if the input useful data 213 has a very large data area, the random number 273 or the region of the random number 273 considered must be selected so large that the selection of a specific reduced useful data area 219 can also cover this large data area of ​​the useful data 213. Therefore, the random number 273 is correspondingly large.

[0060] By uniquely assigning random number 273 to the respective control device 20, it is possible to combine a complete message with a complete data area (which also reaches the other control device and is also detected and forwarded in a reduced manner by the correspondingly equipped sensor 26 there) by combining a number of reduced events 221 from a plurality of control devices when further control devices are present during the analysis in the backend 36. This is because, as described, the other control devices with the same sensor functionality now also randomly select other useful data areas 219 (with other randomly selected start or end addresses), which, after combining a number of reduced events 221, can cover a large part of (useful) data area 213 or the entire data area of ​​useful data 213 based on subareas or selected useful data areas 219 of different control devices. Thus, the events 220 can be reconstructed from the reduced events 221 or selected useful data areas 219 by different control devices, for example, by providing sub-data areas 538-547 (of a selected useful data area 219) from one control device, sub-data areas 548-557 (of a further selected useful data area 219) from another control device, and sub-data areas 558-567 (of a further selected useful data area 219) from another control device, and by combining the respective selected useful data areas 219 again to form the complete (useful) data area 213, for example in a higher-level control device or in the backend 36. This is particularly the case in so-called broadcast attacks on the entire fleet or so-called multicast attacks on parts of the fleet.

[0061] The start and / or end of the forwarded or selected useful data area 219 is preferably randomly determined again after certain events (periodically, start of the control device, reset of the control device, etc.). For this purpose, for example, the random number 273 can be regenerated. Alternatively, other ranges of the random number 273 can be used to generate the start and / or end of the data area to be forwarded or the selected useful data area 219.

[0062] The processed reduced events 221 are forwarded from the sensor 26 to the event manager 30. Therefore, the event manager 30 does not receive the complete data stream of these network frames from this sensor 26, but only the reduced events 221 with a reduced data size. The reduction of the events 221 to be forwarded is described by way of example based on the IDS Ethernet sensor 26. However, in principle this can also be implemented in other IDS sensors 24, 26, 28. However, due to the high information content in the Ethernet frames with a high transmission rate, it is precisely such events 220 that will quickly lead to an overflow of the buffer memory 206. In the case of the IDS CAN sensor 24, the corresponding data 211 anyway appear at a lower data rate and a smaller data volume, so that the nearly complete events 220 can be forwarded and stored here. However, in principle, the data can also be reduced there, as described accordingly.

[0063] Therefore, in principle, the following steps are performed to reduce the events 220 in the sensors 24, 26, 28. Data 211 is received from the sensors 24, 26, 28 and / or the data 211 is evaluated to determine whether an anomaly exists. If an anomaly exists, the data 211 is reduced. The reduction is performed by reducing the address area or header 214 and / or the data area or useful data 213. The reduction of the address area 214 can be performed by selecting the target address and / or the source address. The reduction of the useful data 213 is performed randomly. The useful data 213 is randomly reduced by randomly selecting the start value and / or the end value of the sub-area of ​​the useful data 213. The offset of the data area (the amount of data transmitted) is set to a specific value. The reduced events 221 are transmitted to the event manager 30. The reduced events 221 contain the reduced address data and / or the reduced or selected useful data 219. The updating of the random number 273 is performed according to a specific system state (periodically, startup, reset, etc.). Alternatively, the updating of the random number 273 can be performed randomly and / or time-controlled. The random number 273 or the range of the random number 273 for specifying the start region or the end region of the selected useful data region 219 may depend on the size of the useful region 213 of the received data 211 .

[0064] according to Figure 3, shows the structure of the event manager 30 in more detail. The event manager 30 has a plurality of functional blocks that interact with each other. Each event 220 or reduced event 221 detected by the sensor 24, 26, 28 arrives at a block 202. The block 202 is used to select the incoming event 220 or reduced event 221 that should be further processed. In particular, the block 202 is used to prioritize and reduce the events 220, 221.

[0065] Each event 220 or each decreasing event 221 also arrives at block 204, which serves as a counter 204 for events 220, 221. When an event 220, 221 occurs, the corresponding counter is incremented, in particular a global event counter 205. The counter 204 particularly preferably has different counters Z1, Z2, ... Zn for different event types 218 (ID1, ID2, ... IDn), as described in detail above in conjunction with the corresponding sensors 24, 26, 28. The global event counter 205 in turn represents the sum of all counter readings of the counters Z1, Z2, ... Zn for the different event types 218 (ID1, ID2, ... IDn). The output signal 231 of the block 204 or the counter contains the counter readings of all events 220, 221, i.e. the counter readings of the corresponding event-related counters Z1, Z2, ... Zn and the global event counter 205. The corresponding output signal 231 of the block 204 is supplied to the block 210 for transmitting the event 220. Block 204 is arranged to receive a reset signal 222, which indicates a reset request for one or more counters or event counters 204, 205. Block 204 receives a signal for a reduction state 225 from block 202, for example "event reduction is valid". In block 202, event reduction is valid, for example, when only a reduced number of specific events 220, 221 are further processed as selected events 226. This is the case in particular when, for example, a large number of events 220, 221 are input within the scope of so-called event bursts and are accompanied by an increase in the filling level 228 of the buffer memory 206. In this case, an additional event 220 should be generated, for example using the event type 218 "event reduction is valid" as described above. Then for this event 220' with the associated event type 218, there is also a corresponding counter or counter reading.

[0066] The events processed by the block 202 arrive as selected events 226 at the block 206, which serves as a memory or buffer memory for the selected events 226 delivered from the block 202 and comprises corresponding logic for this. In response, the memory 206 reports back to the block 202 a filling level or memory occupancy 228. The memory 206 is preferably a volatile memory, in particular a buffer memory of a RAM. In addition, a time signal 224, in particular a global time signal 224, arrives at the memory 206 or at a block for buffering the selected events 226. The memory 206 is an integral part of the event manager 30.

[0067] The specific event 236 stored or buffered in the memory 206 arrives at the block 210, which is used to transmit the event report 242 according to the selected event 226 or the stored event 236. The block 210 for transmitting the event also obtains the output signal 231 of the event counter 204, such as the counter readings of the counters Z1, Z2...Zn for the corresponding event type 218 and / or the counter reading of the global event counter 205. The block 210 for transmitting the event, in particular the event report 242, exchanges signals 244 with the cryptographic module 212. The cryptographic module performs cryptographic operations, such as encryption operations, verification and authentication operations, and random number generation. With the help of the cryptographic module 212, encrypted communication of the block 210 to the outside can be carried out. In particular, the cryptographic module 212 uses Figure 2 d encrypts the event report 242. Similarly, the cryptographic module 212 can also use the authentication information 256 to authenticate the event report 242, see also Figure 2 d. Block 210 may reside in the communication adapter 32 and / or the event manager 30. Block 210 outputs a corresponding event report 242. Block 210 receives a request command 240 requesting to read out a corresponding event 236 stored in the memory 206, 208. The request command 240 may be performed periodically and / or in response to an explicit request. In addition, block 210 sends a signal 239 (event release) to the memory 206. Thus, generally after successfully transmitting the associated event report 242 that also contains the stored event 236 or the selected event 226, the memory 206 or 208 is notified to allow the stored and further transmitted events 236, 226 to be overwritten or deleted.

[0068] Furthermore, a further memory 208, in particular a non-volatile memory, is provided in the event manager 30. Specific events 234 and / or counter readings of the event counter 204 which were buffered in the buffer memory 206 are permanently stored in the further, in particular non-volatile memory 208. For this purpose, the memory 208 exchanges data with the event counter 204 and / or with the buffer memory 206.

[0069] The following is based on Figure 4 The working mode of block 202 for prioritizing and reducing events 220 is described in more detail. The mechanism described below is used to select whether metadata 215 that is additionally helpful (and occupies a large amount of memory) for events 220, 221 should be stored. In further summary, block 202 is used to select events to be further processed as selected events 226 from the events 220, 221 delivered to the event manager 30. For each event type 218 of the obtained events 220, 221, it is tracked whether it is the first occurrence of this particular event type 218 or whether an event 220 with this event type 218 has already been sent to the memory or buffer 206; that is, query 301. If the event type 218 is the first occurrence, then block 304 follows, in which the corresponding event 220 is transmitted to the buffer 206 as the selected event 226 and stored there. Otherwise, block 302 follows. In step 302, it is determined according to certain criteria whether the events 220, 221 that have already occurred regarding the event type 218 should still be stored. This is done, for example, after a random selection of events 220, 221, in particular after a selection of events 220, 221 based on a random number 273. The random selection can particularly preferably be based on a control unit-specific or vehicle-specific random number 273. An intelligent algorithm should be used for the random selection in order to limit the overflow of the buffer memory 206 in the worst-case attack scenario (long-term attack with so-called event bursts). On the other hand, a reasonable number of stored events 236 or selected events 226 or log entries in normal scenarios should be retained in order to detect as wide a range as possible during the entire attack. For this purpose, in step 303, the event 220 selected in step 302 is transferred to the memory 206 as the selected event 226 for storage.

[0070] Therefore, if an event is now selected according to a random criterion according to step 302, i.e. query 303, then this event 220, 221 is also sent to the memory 206 as a selected event 226, i.e. step 304. Otherwise, the program flow ends without storing this event 220, 221 in the memory 206 or without additionally storing further metadata 215 for the event 220. When the memory 206 has been read out and notified via block 210, the monitoring of the first occurrence of the event type 218 is reset. If an event 220, 221 is not selected or is discarded, the state "event rejected" is triggered for each discarded event 220, 221. For this purpose, a further counter 204 is particularly preferably provided to detect the number of unselected events 220.

[0071] For additional prioritization, the events 220, 221 can optionally be grouped according to the respective event types 218, and separate instances can be provided for randomly reducing the events for each event type 218. Prioritization can also be additionally implemented by forming groups. This means that the event types 218 are assigned to different priority groups. A specific event type 218 (e.g., event types 218 with ID numbers ID1, ID6, ID14, ID23, etc.) is assigned to the priority group with the highest priority (Prio 1), an associated further event type 218 (e.g., event types 218 with ID numbers ID2, ID5, ID12, ID27, etc.) is assigned to the priority group with the next lower priority (Prio 2), an associated further event type 218 (e.g., event types 218 with ID numbers ID2, ID5, ID12, ID27, etc.) is assigned to the priority group with the next lower priority (Prio 3), and so on. For different priority groups (Prio1, Prio2, Prio3, ...), different numbers of events 220 are randomly selected on average as selected events 226 (N1: number of selected events of priority group 1 (Prio1), Nx: number of selected events of priority group x (Prio_x)). In priority groups with high priorities, more events 220 are randomly selected on average than in priority groups with low priorities (N1>N2...). This can be achieved, for example, in that the areas B1, B2...Bx (with associated priority groups Prio1, Prio2...Prio_x) from which events 220 are selected are selected or the smaller the number, the higher the priority (B1>N2... <B2...)。

[0072] The selected events 226 are stored in the volatile memory 206. However, the selected events 226 should not be immediately stored in the non-volatile memory 208, because storing too frequently may damage the non-volatile memory 208. Figure 6 Explained in more detail, the selected events 226 may be randomly stored in the non-volatile memory 208 .

[0073] One or more memories 206, 208 can handle selected events 226 having different sizes. Figure 7The memory 206 is shown by way of example in . The memory comprises a free storage area 250 and a filled storage area 252. In the filled storage area 252, a plurality of selected events 226 or 226 are stored. These entries 226 can each have different sizes. Due to the non-rigid division of the storage area, the storage space is optimally utilized. If the memory 206 is full, new selected events 226 are discarded. However, in principle, the memory 206 is prevented from being filled up by a self-regulating mechanism as described below. Thus, when the filling level 228 of the memory 206 is very high, on average significantly fewer events 220 are randomly selected than when the filling level 228 of the memory 206 is low. However, if the selected event 226 is discarded because the buffer 206 is full, an event counter of the new event type 218 "Logging buffer overflow (memory 206 overflow)" is implemented to determine the number of discarded events or entries. As Figure 3 As shown, this can be done, for example, by signaling the state 230 of the memory 206 to the counter 204 or by signaling 230 to the counter 204 whenever a further selected event 226 cannot be stored because the memory 206 is full.

[0074] As soon as all stored events 236 or selected events 226 have been successfully reported to an external data logger, for example in a control device, via block 210 within the scope of event reporting 242, buffer 206 is released to overwrite or delete the corresponding event 226 (signal 239 release event). Writing events 236, in particular to a non-volatile memory 208 such as a flash memory, can advantageously be mapped via a non-AUTOSAR storage mechanism to ensure memory efficiency and performance requirements. However, there is also the possibility of using standard AUTOSAR storage mechanisms.

[0075] Combination Figure 5 The event counter 204 is described in more detail. For each event type 218, a separate counter Z1, Z2 ... Zn is implemented within the scope of the event counter 204. The event counter 204 starts with a zero value. First, it is determined whether the counter reading is still less than a maximum value, i.e. query 260. If this is the case, the counter Z1, Z2 ... Zn of the corresponding event type 218 is incremented when an event 220, 221 of a specific event type 218 occurs, i.e. step 262. Otherwise, the counter reading is kept at the maximum value, so that no overflow occurs. The event counter 204 can be reset to zero on request. For example, the counter 204 can be implemented as a 32-bit counter.

[0076] according to Figure 6The non-volatile storage of an event counter 204 and / or specific selected events 226 in a non-volatile memory 208 is described. Data should be stored in the non-volatile memory 208 at regular time intervals. Such time intervals are, for example, in the range of seconds, minutes to hours, for example, data is stored every 30 minutes. The time points of storage should be randomly selected so that an attacker cannot predict the writing behavior. The storage cycle can be randomly controlled, for example, at specific intervals (for example, within 30 minutes, etc., however, the exact storage time point within, for example, a 30-minute interval is randomly controlled). The random variable (for specifying the storage time point) can be generated or selected based on a random number 273 of the control device alone or the vehicle alone.

[0077] Alternatively, the time-controlled storage moment can be randomly selected by multiplying the random number by a basic time interval. Thus, for example, a specific basic time interval is 15 seconds, which is multiplied by, for example, a 3-digit random number or a random number range of the random number 273. The random number 273 itself can be updated periodically and / or randomly. Alternatively, the random number 273 can be given individually in a control device-specific or vehicle-specific manner, for example in production and manufacturing. Alternatively, a specific range of the random number 273 can be selected, on the basis of which a factor that depends on the range of the random number 273 is formed.

[0078] As soon as a new selected event 226 occurs and can be stored in the non-volatile memory 208, the selected event 226 is stored in a non-volatile manner. Furthermore, if a state change of the control device occurs (which can also be caused by an attacker) that leads to the loss of the current RAM content (and thus to the loss of the buffer memory 206), for example due to a requested reset or sleep mode, the storage of the selected event 226 (in the memory 206) and / or further information (such as a specific counter reading 232 of the event counter 204) in the non-volatile memory 208 is initiated.

[0079] The data should be stored in a redundant manner so that it can be restored even if part of the data is damaged. After reading out from the non-volatile memory 208, the authenticity and integrity of the stored data should be checked or ensured. Preferably, the non-volatile memory 208 is arranged in a trusted area. It is assumed here that the memory inside the IC is classified as trusted. For this purpose, the standard AUTOSAR NVM (non-volatile memory) handler can be used.

[0080] exist Figure 52 shows an example of a state diagram for storing selected events 226 in non-volatile memory 208. When state 264 is reached, data can in principle be stored in non-volatile memory 208 in state 264. In state 266, data cannot be stored in non-volatile memory 208. The transition from state 264 to state 266 takes place after the storage has been performed. The transition back to state 264, in which storage can be performed, takes place in a time-controlled manner. Preferably, the time is random, as already described. When the control device is not ready for a sleep state or a reset, the system remains in state 266 (no storage).

[0081] Figure 7 A more accurate illustration of the components of the event manager 30 is shown. A plurality of events 226 are stored in the buffer memory or memory 206 and form a filled storage area 252. Exemplarily, event number 2 (226.2), event number 4 (226.4), event number 8 (226.8), event number 13 (226.13), event number 25 (226.25), event number 38 (226.38), event number 77 (226.77) and event number 97 (226.97) are stored in the buffer memory 206 as selected events 226. As described below, these selected events 226 are selected from a series of occurring events 220 (numbered 0 to, for example, 200) according to a specific process and are stored in the buffer memory 206 as selected events 226.

[0082] The unfilled area or remaining area of ​​the buffer memory 206 forms a free storage area 250 .

[0083] The corresponding filling level 228 of the memory occupancy shown is formed in the embodiment by the last stored selected event 226.97. The storage area of ​​the buffer memory 206 is now divided into a plurality of areas 267 or filling level areas 267 between 0 and 100%. In the embodiment, these are, for example, ten (filling level) areas 267.1-267.10. In the embodiment, the areas 267 are always selected to be the same size, in the embodiment these are 10% intervals. In the embodiment, the memory 206 has exactly the current area 267.4, i.e. the fourth area 267.4, which is between 30% and 40% of the complete memory occupancy.

[0084] In a functional block 268 , the current storage area 267 . 4 in which the current fill level 228 of the memory 206 lies is determined. The current fill level area 267 (in the exemplary embodiment for the fourth area 267 . 4 ) reaches a block 270 .

[0085] In block 270, an offset 271 of the next event is determined. The offset 271 indicates from how many events 220 the next event 226 to be stored in the memory 206 should be selected. This number of events 220 (offset 271) depends on the corresponding fill level 228 or the associated storage area 267, from which the next event 226 to be stored should be selected, in particular randomly. When the fill level 228 or the storage area 267 is low (the fill level 228 of the memory 206 is relatively low), the events 20 are stored faster, so that the offset 271 is relatively small. As the fill level 228 or the storage area 267 increases, the offset 271 increases, i.e. fewer events 220 are stored or events 220 are selected only from a larger number (offset 271). As a result, overflow of the memory 206 can be delayed or prevented in a targeted manner. Within the offset 271, the next event 226 to be stored is selected randomly. For each offset 271, only one event 220 (within the offset 271) is randomly selected or stored. Thus, by varying the offset size depending on the fill level 228 of the memory 206, more or fewer events 220 are randomly selected or stored on average. Thus, as long as the fill level 228 of the memory 206 is within a certain range 227, the event manager 30 always selects the event 226 to be selected from the same associated offset 271 until the fill level 228 reaches the next region 227 with a changed, usually increasing, offset 271.

[0086] If leaving the storage area 267 defined by the lower or upper limit value, the next offset 271 of the new area may be increased or decreased, for example by a specific multiple or by a specific divisor.

[0087] By way of example, Figure 8 The corresponding scenario in the table of FIG. 200 causes the memory 206 to be occupied, such as Figure 7As shown. The offset 271 can be selected exemplarily for different filling levels 228 or storage areas 267, as explained below. Thus, for example, for a storage area between 0 and 10% (267.1), the offset 271 can be assigned to 2 (from zero to 2, so from three events 220), for a storage area between 10% and 20% (267.2) to 8 (from 0 to 8, so from 9 events 220), for a storage area between 20% and 30% (267.3) to 32 (from 0 to 32, so from 33 events 220), and for a storage area between 30% and 40% to 128 (from 0 to 128, so from 129 events 220), and so on. For example, a corresponding increase in the offset 271 of the next storage area 267 can be achieved by a corresponding factor (4), etc. Both the storage area 267 and the offset value 271 are freely configurable and thus adapted to the respective desired conditions, such as memory size etc.

[0088] exist Figure 7 In the subsequent block 272, the filling level 228 or the storage area 267 should now be randomly (according to Figure 7 The next event 220 to be stored is selected by the random number 273 (shown as an example in FIG. 2 ). It must be ensured that the offset 271, i.e. the number of events 220 or the range of the next events 220 to be considered, from which the respective event 220 to be stored should be randomly selected, can be covered by the random number 273 or the corresponding range of random numbers 273. Depending on the corresponding offset 271, the size of the range of random numbers 273 to be considered is selected. If the random number 273 is bit-coded, for example, Figure 7 As shown in the example, for example, for an offset 271 (0-2) equal to 2, a temporary range 273_temp of random numbers with a size of two bits is first selected. When the offset 271 is 8 (0-8), a range x of random numbers 273.x_v with a size of 4 bits is selected. When the offset 271 is 32 (0-32), a temporary range 273_v of random numbers with a size of 6 bits is selected. When the offset 271 is 128 (0-128), a temporary range 273_v of random numbers with a size of 8 bits is selected. The temporary range 273_v of random numbers can be found in the 4th column, where for Figure 7The specific random number 273 of is illustrated as an example. Then check whether the part of the random number 273 contained in the temporary range 273_temp is less than or equal to the offset 271 of the next storage area 276. If this is the case, the temporary range 273_v is actually also used as the random number range as the part 273.x of the random number. The corresponding query in the 5th column can be answered with "true". For these cases, the temporary part 273.x_v of the random number is consistent with the selected random number part 273.x. If this is not the case (answering the query in the 5th column with "false"), the temporary part 273.x_v of the random number is reduced. This can be done by omitting one bit, preferably the most significant bit (MSB). For the value of the random number thus derived in this range 273.x, it can now be ensured that the value is within the offset 271 of the next storage area 267.

[0089] Thus, for example, for an offset 271 (0-8) of 8, the first 4 bits of the random number 273 are taken into account in order to also cover the number 8 itself (the size of the current offset 271), for which see Figure 8 The columns with buffer entries numbered 3, 4, and 5 in the . If the 4-bit value of the associated temporary random number range 273.5_v is <= offset 271 - for example event number 25, 273.5=0b0111=7, then the 4-bit number is used directly. The associated query shows Figure 8 Column 5 of . Since the condition is met, the result is "true".

[0090] If the value of the 4-bit size of the associated temporary random number range 273.4_v > offset 271 - for example for event number 13, 273.4 = 0b1100 = 12, then this 4-bit number is not used directly, but the MSB (most significant bit of the random number range 273.4 under consideration) is truncated and the resulting 3-bit number 0b100 = 4 is used. The truncated MSB does not have to be discarded, but is entered as the LSB (least significant bit) of the next random number range 273.5_v to be considered. In this case, the associated condition (corresponding random number range 273.3 <= offset 271) is not met (the associated result is "false" in column 5). This process ensures that the random number 273 is fully used and not exhausted unnecessarily quickly.

[0091] In order to determine the size of the random number range 273.x (eg, the number of bits required for the range of random numbers 273), it is necessary to consider whether the variable for the size of the offset 271 of the associated storage area 267 representing the next event 220 (eg, the number of bits required) is sufficient.

[0092] Therefore, according to Figure 8In the embodiment of , according to line 1, in the case where the selected random number 273.1 is 2, event number 2 (220.2, global event counter 285 is 2) is selected as the selected event 226.2 at offset 271 of 2 (from 0-2) (after discarding events 220.0, 220.1 numbers 0 and 1). According to line 2, at the next offset range 271 (still in 0-2), event number 1 is randomly selected in relation to this offset range 271. Event number 0 in this offset range 271 has been discarded (corresponding to a global counter reading 285 of 3), but event number 1 in this offset range 271 is selected (corresponding to a global counter reading 285 of 4, resulting in the selected event 226.4). According to line 3, the next offset range 271 is still in 2 (0-2), since the fill level 267 of the buffer 206 is still located in the area 267.1 between 0 and 10%. The random number of 273.3 is 2, so after discarding event numbers 0 and 1 in this offset range 271, event number 2 is selected (global counter reading 285 is 8, selected event 226.8). Since the subsequent fill level 267 is located in the next fill level range 267.2, the new offset 271 now becomes 8 (0-8). As described above, the next 4 bits of the temporary random number range 273.4_v are now considered. Since the associated random number of the temporary random number range 273.4_v is 12, which is greater than the current offset 271 (the query 12<=8 in the 5th column yields "false"), the most significant bit of the temporary random number range 273.4_v is not used, but only the 3 least significant bits (binary 100, i.e. 4) within the selected random number range 273.4 are used. Thus, for this new offset range 271 of 8 (0-8), event numbers 0 (global counter reading 285 is 9) through 3 are discarded, and event number 4 (global counter reading 285 is therefore 13) is selected as the selected event 226.13. Figure 8 The corresponding values ​​for the further fill level 267 are combined by way of example.

[0093] In block 272, therefore, it has now been determined randomly which event 220 is selected next as the selected event 226. The corresponding block 280 now monitors the occurrence of new events 220 (block 284). For example, it was previously set that after storing event 226.8 (the 8th event), event 226.13 (the 13th event) should be stored next. Block 280 therefore waits for event number 13, i.e. discards the next event numbers 9-12 and only stores event number 13 as the selected event 226.13 in the memory 206. Based on the new selected event 226 with the data size of the metadata 215 (event-related metadata 216 and general metadata 217), a new fill level 228 of the memory 206 is determined. This can be done particularly simply, for example, using the length 232 already contained in the metadata 215.

[0094] The random number 273 is selected differently for different control devices or vehicles 18. Thus, for example, the random number 273 can be assigned once for each vehicle or each control device during production. Alternatively, the random number 273 can be regenerated internally according to specific rules. This regeneration can be performed, for example, during system state transitions (at boot, reset, transition to sleep mode, etc.) and / or periodically after a specific time.

[0095] Block 272 determines the next event hit 278 (next event hit: the next event hit 278 in the next offset 271) from the corresponding information. The next event hit 278 reaches block 280 (throw the dice), in which the delivered event 220 is randomly either discarded (event 220 is not stored in the buffer memory 206) or selected as the selected event 226 for storage in the buffer memory 206. If a selection is made (event hit 282, event hit), block 284 follows. Block 284 is called for each event 220. However, block 284 itself calls block 280 (for each event 220), and block 280 provides feedback to block 284 as to whether the event 220 should be selected. If the event 220 is selected by block 280, block 284 triggers the event 220 to be stored in the memory 206 as the selected event 226.

[0096] In block 284 (on event), the selected event 220 is read in for subsequent storage as selected event 226 in free area 250 of buffer memory 206. Block 284 is always called for each new incoming event 220, 221. Block 284 is used for random selection, including possible reduction and priority setting of the incoming events 220, 221.

[0097] In addition to the random selection in block 280, the event 220 can also be randomly reduced, such as has been described with the ETH sensor 26. Thus, a specific data area (preferably the start of a fixed data area or the end of a data area) can be randomly selected. Likewise, only specific reduced address data can be stored.

[0098] Likewise, in the case of a high occurrence rate of events 220 or in general, the sensor 24, 26, 28 itself (in the case of a specific source, such as Ethernet) can select or reduce the events 220, which is similar to a quasi-pre-filtering of the event manager 30 in order to relieve the event manager 30 (events 220 from other sources are also input to it). If the sensor 24, 26, 28 has not yet forwarded the individual events 220 to the event manager 30, this should also be transmitted to the event manager 30 as a separate event type 218 (similar to the reduction state 225 in the event manager 30). However, in general, the event-related selection of events 220 can be carried out in the sensor 24, 26, 28 itself and stored in the buffer memory of the sensor 24, 26, 28. Likewise, corresponding counters can also be set in the sensor 24, 26, 28 for the corresponding event types 218, which can be transmitted to the event manager 30 when necessary. Events 226' selected by the sensors 24, 26, 28 may also be transmitted to the event manager 30 at the request of the event manager 30 for possible forwarding to the superior instance 34 and / or the backend 36. Nevertheless, the processes for random selection and / or priority setting described in conjunction with the event manager 30 may still be run in the sensors 24, 26, 28. However, these processes may be limited to the specific data 211 of the respective source, so that the sensors 24, 26, 28 may only select sensor-specific events 220.

[0099] To increase security, the communication adapter 32 may provide for sending event reports 242 to other IDS instances 34 randomly, non-deterministically, and hidden from an attacker.

[0100] If already combined Figure 2d, an event report 242 is generated from the selected events 226 stored in the buffer memory 206. The event report includes the selected events 226 stored in the buffer memory 206. These selected events 226 are preceded by variables 254 (such as random numbers, times or counters, etc.) that change relative to each event report 242. In addition, the event report 242 also includes authentication information 256. Through this authentication information, authentication can be performed between the communication adapter 32 and the unit (IDS instance 34, back end 36, etc.) that receives the event report 242. The authentication information 256 can be formed, for example, by at least a portion of the data in the event report 242, preferably by all the data in the event report 242 (of course, except for the authentication information 256 to be formed). For this purpose, a corresponding algorithm is stored in the event manager 30. For authentication purposes, the superordinated unit 34 and / or the backend 36 can in the same way form the associated authentication information 256' from the corresponding data of the received event report 242 after decryption and compare it with the actually received authentication information 256 (as transmitted in the event report 242). In case of agreement, authenticity is assumed.

[0101] The event report 242 has a fixed length 258. To achieve this fixed length 258, the data 254, 215_1, 215_8, 215_190, 256 are also filled with so-called filling data 255. The filling data 255 does not contain any information related to the event. Figure 2 d, prior to transmission, the data shown in the event report 242 is provided with encryption 258. The event report 242 encrypted in this manner by encryption 258 is sent by the communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36 as described. Even if the variable 254 that changes for each event report 242 differs by only, for example, 1 bit, the subsequent encryption 258 results in the encrypted event report 242 being significantly different from the previous event report 242 (and not just by one bit).

[0102] Thus, specific events 220 can be transmitted periodically and encrypted (both using plain text of constantly changing variables 254 as part of event report 242 and using encryption 258 of event report 242) within the scope of event report 242. However, even if there are no new events 220, so-called virtual events (e.g. consisting of filler data 255) can also be transmitted periodically and encrypted. This serves to protect the data exchange between communication adapter 32 and further IDS instances 34 or backends 34 from eavesdropping or random hiding.

[0103] The following is based on Figure 9-14The communication process between the event manager 30 and the communication adapter 32 in the control unit or gateway 20 , the communication process between the communication adapter 32 and at least one further IDS instance 34 in the vehicle 18 , and the communication process between the further IDS instance 34 and the backend 36 are described by way of example.

[0104] The communication from a control device such as a gateway 20 to a further IDS instance(s) 34 (e.g. a central event logger in a vehicle 18) should ensure that the further IDS instance 34 or the event logger is informed of unread entries or events 236 or selected events 226 stored in the memory 206. The control device or gateway 20 should periodically send event reports 242 to the further IDS instance 34, preferably via a so-called heartbeat signal (a periodic signal that can be used to check whether the communication participants are connected as specified). The heartbeat signal (including the event report 242) should be encrypted and authentic. Preferably, the transmitted information should be exchanged authentically (if necessary with authentication information 256) and encrypted, preferably randomly or using random numbers 273 between the control device or gateway 20 and the further IDS instance 34. Preferably, the event report 242 should have a fixed length 257, should be encrypted and authenticated. Each encrypted event report 242 should differ from the previous event report 242, even if the transmitted state has not changed.

[0105] In addition, the communication from another IDS instance 34 to the control device or gateway 20 or the associated communication adapter 32 should also be characterized by the following functions. The data logger or IDS instance 34 should read in the event 236 or the associated event report 242 as quickly as possible, in order to prevent in particular the overflow of the memory or buffer memory 206. The event report 242 should be able to be read out via the diagnostic interface, for example, upon request. Alternatively, the event report 242 can be sent periodically in its entirety. Even if no new selected event 226 is available within the scope of the new event report 242, the event report 242 should be transmitted or read out regularly, preferably authentically and encrypted or hidden. The control device or gateway 20 should respond to the read request 240 encrypted and authenticated with a response or event report 242 of a fixed length. Even if the content has not changed, each encrypted response or event report 242 should be different from the previous response or event report 242. This is performed exemplarily by the variable 254 that is constantly changing as already described.

[0106] according to Fig. 9, the event manager 30 first selects the first selected event 226.1 and then the second selected event 226.2. These selected events are processed by the event manager 30 as described. Therefore, the selected events 226.1, 226.2 are stored in the memory 206. The communication adapter 32 contains a signal 400, namely a time-related interrupt signal (Timer IRQ). The time-related signal 400 is preferably formed periodically, thereby periodically starting the sending of event reports 242 from the communication adapter 32 to the other IDS instances 34 in the vehicle 18. However, even in the absence of new events 226.1, 226.2, as described below, a signal (in the form of a "normal" event report 242) is sent from the communication adapter 32 to the other IDS instances 34 (see signal 406). However, it is particularly preferred that the sending of the event report 242 is not triggered by the acquisition of the event 220 or the selected event 226, but is triggered periodically (by the time lapse of the cycle time). This is particularly advantageous, since the transmission to the further IDS instances 34 and / or the backend 36 is also always carried out periodically, i.e. after a certain time has elapsed. The behavior or anomaly detection of the event manager 30 is thus not transparent to the attacker. The attacker never knows whether his attack has been detected, what has been detected and how the anomaly detection system works.

[0107] After the communication adapter 32 has received the signal 400 (Timer Interrupt), the communication adapter 32 requests an event report 242, i.e., signal 402, from the event manager 30. The event manager 30 creates a corresponding event report 242, which includes the previously selected events 226.1 and / or 226.2 (with the corresponding general metadata 217 and event-related metadata 216) and the changed variables 254. In addition, the corresponding padding data 255 is added, so that a fixed length 257 of the event report 242 is reached (in the case of knowing the length of the authentication information 256 that is still to be formed). In addition, the event manager 30 generates the authentication information 256 from the changed information 254, the selected events 226.1, 226.2 and the padding data 255, for example, using a specific algorithm. The authentication information 256 formed in this way completes the event report 242. The complete event report 242 is then encrypted with the key 258. The encrypted event report 242 arrives at the communication adapter 32 as signal 404. Encryption (using altered information 254 and / or key 258) and authentication (forming authentication information 256) may be performed in event manager 30 and / or communication adapter 32 if corresponding security requirements are met.

[0108] Alternatively, the communication adapter 32 can encrypt the event report 242, for example, based on the random number 273. Particularly preferably, a new random number 273 is always formed for encryption, for example by hashing. This further makes the decryption of the transmitted message or the encrypted event report 242 more difficult. If necessary, the communication adapter 33 takes over the authentication using the authentication information 256 and / or the addition of the changeable variable 254 and / or the final encryption of the entire event report 242 using the encryption 258.

[0109] Even if the event manager 30 does not provide a new event report 242 due to the occurrence of a new selected event 226, a corresponding signal 406 is sent in response to the timer interrupt (signal 400). A dummy message with the data format of the event report 242 is then transmitted to the other IDS instance 34 in an encrypted manner (using a key 258) via a random number or a continuously changing variable 254. The dummy message is also always encrypted via a continuously changing variable 254 or a new random number, so that even if no new selected event 226 occurs, other messages or encrypted messages (signal 406) are always transmitted periodically. This periodic transmission can be used to check whether the communication connection between the communication adapter 32 and the other IDS instance 34 is functioning as specified.

[0110] After the further IDS instance 34 obtains the message sent from the communication adapter 32 (signal 406), the further IDS instance 34 sends a confirmation signal (408) to the communication adapter 32. After obtaining the confirmation signal 408, the communication adapter 32 generates a request to the event manager 30 to delete or overwrite the cached, if necessary reduced, selected events 226 or associated event reports 242 (signal 410).

[0111] In an alternative embodiment, the superior instance 34 and / or the back end 36 checks the authenticity of the received encrypted event report 242. To this end, the superior instance 34 and / or the back end 36 uses the known key 258 to decrypt the received message, i.e. the encrypted event report 242. The event report 242 is then available in plain text. The event report 242 is authenticated using the corresponding algorithm for forming the authentication information 256 (which is also used by the event manager 30 or the communication adapter 32 to create the authentication information 256). To this end, all the data of the received and decrypted event report 242 (except the authentication information 256) is used again, and the corresponding authentication information 256' is formed thereby. The authentication information 256' formed is then compared with the authentication information 256 received in the scope of the event report 242. If consistent, the received event report 246 is considered to be authentic. In this variant, further data communication with a higher-level or lower-level instance can only be carried out after authentication has been performed. In this embodiment, a signal 408 (confirmation signal) is sent to the communication adapter 32 only after successful authentication, and the communication adapter 32 then sends a signal 410 to the event manager 30 to release the coverage of the selected events 226.1, 226.2.

[0112] Preferably, the response or confirmation signal 408, 416 should also have a fixed length 257'. Preferably, the confirmation signal 408 should be authenticated and encrypted. Each response or confirmation signal 408 of the upper instance 34 and / or backend 36 should be different from each other, even if the content has not changed.

[0113] Examples of such confirmation signals 408, 416 may be Fig. 9 Found in. The confirmation signal 408, 416 has a similar structure to the event report 242. The confirmation signal 408, 416 includes a changeable variable 254'. The changeable variable 254' changes for each newly sent confirmation signal 408, 416. The changeable variable 254' can again be implemented, for example, by a random number, a counter, a time.

[0114] Particularly preferably, the changeable variables 254' of the confirmation signals 408, 416 can be formed by using the changeable variables 254 of the event report 242 just transmitted. For this purpose, the superordinate instance 34, 36 is configured to extract the changeable variables 254 from the received event report 242 and insert them into the confirmation signals 408, 416. Thus, in a subsequent step, the confirmation signals 408, 416 can also be authenticated by comparing the changeable variables 254' of the received confirmation signals 408, 416 with the changeable variables 254 of the previously sent event report 242. If they are consistent, the real confirmation signals 406, 408 are inferred. In addition, the changeable variables 254' do not have to be generated in the superordinate instance 34, 36 itself. After this, the memory 206 can be released.

[0115] In addition, the confirmation signal 408, 416 includes specific data 255', for example in the form of any template. In addition, the confirmation signal 408, 416 includes authentication information 256'. Similar to the case of the event report 242, the authentication information 256' can again be formed by a specific algorithm, which uses the remaining data of the confirmation signal 408, 416, i.e. the variable 254' and the data 255' that can be changed. The authentication information 256' formed in this way completes the confirmation signal 408, 416. The confirmation signal has a fixed length 257'. It is then encrypted using a key 258'. Optionally, this encryption 258' can also be omitted.

[0116] The receiving instance (e.g., the superior instance 34, the backend 36) and / or the communication adapter 32 or the event manager 30 can in turn decrypt the confirmation signal 408, 412 (using the key 258') and use it for authentication. For this purpose, the authentication information 256'' derived therefrom is determined from the received data (changeable variables 254', data 255') using a corresponding known algorithm and compared with the obtained authentication information 256'. If they are consistent, authenticity is assumed. If the obtained authentication information 256' is correct, a signal 410 for releasing the memory 206 can be generated. If the authentication information 256' is incorrect, the signal 410 cannot be generated, so that the selected event 226 contained in the memory 206 is not (yet) deleted.

[0117] The further IDS instance 34 also periodically receives a timer interrupt signal 412, which is formed similarly to the signal 400 already described. In response to the interrupt signal 412, the further IDS instance 34 again sends an encrypted message, namely the signal 414. The message may contain an event report 242 or a vehicle-related event report (including further event reports), as transmitted via the signal 406 before the communication adapter 32, if necessary. Like the communication adapter 32, the message is encrypted by the further IDS instance 34, in particular by a constantly changing variable 254' such as a random number 273. If the communication adapter 32 does not transmit an event report 242, for example because no new selected event 226 has occurred, a dummy message with the same data format as the event report 242 is used again and transmitted in encrypted form to the backend 36 (signal 414). The backend 36 sends a confirmation signal 416 and / or a further notification or request to overwrite the event 236 cached in the buffer memory 206, etc. to the further IDS instance 34. The confirmation signal 416 can be formed as described above.

[0118] After receiving the signal 410 about the event release, the event manager 30 selects the further selected events 226.3 and 226.4. Further processing can be performed from Fig.10 . At the same time, the event manager 30 also selects another event 226.5. The timer interrupt (signal 420) arrives at the communication adapter 32 again. The communication adapter now requests an event report 242 (signal 422) from the gateway 20. The event manager 30 sends an event report 242 based on the selected events 226.3, 226.4, and 226.5 to the communication adapter 32, that is, signal 424. After obtaining the event report 242, the communication adapter 32 sends the event report 242 encrypted and authenticated by the new changeable variable 254 (such as a random number) to the other IDS instance 34, that is, signal 426. The other IDS instance 34 confirms the acquisition by means of a confirmation signal 428. The confirmation signal 428 can be combined with the confirmation signal 408 ( Fig. 9 ) is formed as described in . After obtaining the confirmation signal 428, the communication adapter 32 sends a request to the event manager 30 to overwrite or delete the selected events 226.3, 226.4, 226.5 on which the event report 242 is based, that is, signal 430. At the same time, another selected event 226.6 is selected between the sending of signal 424 and the receiving of signal 430. However, this selected event 226.6 cannot be overwritten yet, because this selected event 226.6 is not yet the basis of the event report 242 that has been transmitted to the communication adapter 32. In this regard, signal 430 does not involve overwriting the selected event 226.6, but only involves overwriting the selected events 226.3, 226.4, 226.5 that have been transmitted within the scope of the last event report 242.

[0119] As already described, a timer interrupt also occurs at the other IDS instance 34 (signal 432). This causes the other IDS instance 34 to transmit the newly received event report 242 in signal 426 in encrypted form to the backend 36, i.e., signal 434. The backend 36 confirms receipt of the corresponding message 434 by means of a corresponding confirmation signal 436, which is sent to the other IDS instance 34. The confirmation signal 436 can be formed like the confirmation signal 408 or 416.

[0120] Further process in Fig.11 . Another timer interrupt occurs again for the communication adapter 32, i.e., signal 440. The communication adapter 32 then sends a request to the event manager 30 to send an event report 242, i.e., signal 442. The event manager 30 sends an event report 242 containing the event 226.6 selected during this period, i.e., signal 444. The communication adapter 32 encrypts the event report 242 using the new changeable variable 256 and sends the encrypted event report 242 to the other IDS instance 34, i.e., signal 446. Upon acquisition, the other IDS instance 34 sends a confirmation, i.e., signal 448, upon which the communication adapter 32 sends a request to the event manager 30 to overwrite or release the event 226.6 that has already been transmitted, i.e., 450.

[0121] The further IDS instance 34 receives the timer interrupt again, i.e. signal 452. The encrypted event report 242 is then transmitted, if necessary, together with further event reports from further IDS systems, vehicle-related, to the backend 36. The backend 36 sends a confirmation signal and / or a request to release or cover the corresponding event, etc., i.e. signal 456 to the further IDS instance 34.

[0122] In accordance with Fig.12In the exemplary process of , no new selected event 226 occurs between the sending of the last event report 242 and the new occurrence of the timer interrupt (signal 460). After obtaining the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 for the new event report 242 to the event manager 30. The event manager 30 generates - despite the occurrence of the new selected event 226 - an event report 242 with virtual content, which is then sent to the communication adapter 32, i.e., signal 464. The other IDS instance 34 and / or the backend 36 can recognize the virtual content as virtual content. The communication adapter 32 encrypts the received event report 242 with virtual content with the new, changeable variable 254 and sends the encrypted and authenticated event report 242 to the other IDS instance 34, i.e., signal 466. The acquisition is confirmed by the other IDS instance 34, i.e., signal 468. When this signal is obtained, the communication adapter 32 resends a request signal to the event manager 30 to cover the last selected event 226, i.e., signal 470. This is done even if there are no new selected events 226 in the constellation.

[0123] The further IDS instance 34 retrieves the timer interrupt, i.e. the signal 472. The further IDS instance 34 then encrypts the last encrypted event report 242 received and sent by the communication adapter 32 and, if necessary, sends it vehicle-relatedly together with further event reports from further IDS systems to the backend 36. The backend 36 sends a confirmation signal 476 and / or a request to release the event on which it is based, etc. to the further IDS instance 34.

[0124] exist Fig.13In the communication sequence, the communication adapter 32 regains a timer interrupt, i.e., signal 480. This timer interrupt 480 can be a special signal, which causes the communication adapter 32 to request an event summary (instead of one of the common event reports 242) from the event manager 30, i.e., signal 482. The event manager 30 sends the event summary to the communication adapter 32, i.e., signal 484. The event summary can contain superior information, such as different counter readings 231 for different event types 218, or the occurrence of new event types, etc. The event summary is encrypted by the communication adapter 32 again by means of a new changeable variable 254, such as a random number, and transmitted to the further IDS instance 34, i.e., signal 486. As soon as the IDS instance 34 obtains the encrypted event summary from the communication adapter 32, the further IDS instance 34 forwards the event summary to the backend 36, particularly preferably in encrypted form. In an embodiment, no timer interrupt is set for the transmission process between the further IDS instance 34 and the backend 36 to start the communication process. However, alternatively, the communication process can be started periodically again, just like sending common event reports.

[0125] exist Fig.14 In the communication sequence of , the backend 36 sends a request for an event report to the further IDS instance 34, i.e., signal 490. The further IDS instance 34 sends an encrypted request for an event report to the communication adapter 32, i.e., signal 492, for example, via the diagnostic interface. The encryption can again be performed via a changeable variable 254', such as a random number, which is changed in particular for each encryption. After obtaining the request 492, the communication adapter 32 sends a query for an event report 242 to the event manager 30, i.e., signal 494. After obtaining the corresponding query 494, the event manager 30 sends the event report 242 to the communication adapter 32, i.e., signal 496. The communication adapter 32 encrypts the event report 242, for example, via a new changeable variable 254 such as a random number and sends the event report to the further IDS instance 34, i.e., signal 498. After obtaining the encrypted event report 242, the further IDS instance 34 sends the event report 242 to the backend 36. The backend 36 confirms the acquisition to the other IDS instance 34, i.e., signal 492. The other IDS instance 34 confirms the acquisition of the confirmation signal 492 to the communication adapter 32, i.e., signal 494. After acquiring the corresponding signal 494, the communication adapter 32 sends a corresponding request to the event manager 30 to release or cover at least the events 220 transmitted within the scope of the last event report 242.

[0126] The method described can be implemented in a computing unit, a computer or a control unit, in particular in a control unit of a vehicle 18. Likewise, the method can be created within the scope of a computer program, which is configured to carry out the method when it is executed on a computer. Furthermore, the computer program can be stored on a machine-readable storage medium. However, the program can be loaded wirelessly "over the air" as software or loaded wiredly via a diagnostic interface, for example.

Claims

1. A method for processing data anomalies, wherein at least one sensor (24, 26, 28) for identifying anomalies obtains data (211), wherein the sensor (24, 26, 28) checks whether the obtained data (211) has an anomaly, wherein when an anomaly is identified, an event (220, 221) is generated according to the associated data (211), wherein it is randomly determined whether the event (220, 221) is further processed, wherein it is randomly determined whether the event (220, 221) is at least partially stored in a memory and / or whether the event (220, 221) is reduced, The events (220, 221) are randomly determined by selecting them using a random number (273) and / or a range (273.x) of random numbers (273), so that a number or an offset (271) of the number of events (220, 221) randomly selected as events (220, 221) to be further processed is contained in the random number (273) and / or the range (273.x) of random numbers (273).

2. The method according to claim 1, characterized in that Events (220, 221) to be further processed are at least partially stored in a volatile memory (206) or a buffer memory and / or a non-volatile memory (208).

3. The method according to claim 2, characterized in that Events (220, 221) to be further processed are selected depending on a fill level (228) of the volatile memory (206).

4. The method according to claim 2, characterized in that: The number or offset (271) of events (220, 221) from which events (220, 221) to be further processed are randomly selected depends on the fill level (228) of the volatile memory (206).

5. The method according to claim 2, characterized in that: The volatile memory (206) comprises at least two storage areas (267), to each of which are allocated events (220, 221) of different numbers or offsets (271), from which events (220, 221) to be stored are randomly selected.

6. The method according to claim 2, characterized in that The range (273.1, 273.2) of the random number (273) is selected depending on a fill level (228) of the volatile memory (206) and / or depending on the number or offset (271) of events (220, 221) from which the events (220, 221) to be stored are selected.

7. The method according to claim 1, characterized in that First, a temporary range (273.x_v) of the random number (273) is selected, the random number (273) based on the temporary range (273.x_v) is compared with the associated offset (271), and if the random number (273) based on the temporary range (273.x_v) is greater than the offset (271), the temporary range (273.x_v) is reduced by one segment and used as the range (273.x) of the random number.

8. The method according to claim 7, characterized in that The segment of the temporary range (273.x_v) from which it is reduced is part of the next temporary range (273.x+1_v) or the next range (273.x+1).

9. The method according to claim 1, characterized in that: The random number (273) is regenerated periodically and / or based on specific system events.

10. The method according to any one of claims 1 to 2, characterized in that An event type (218) is determined for the event (220, 221), and for an event (220, 221) having an event type (218) that has appeared in a previous event (220, 221), it is randomly determined whether to further process the event (220, 221).

11. The method according to any one of claims 1 to 2, characterized in that A plurality of sensors (24, 26, 28) are provided for identifying anomalies, each sensor obtaining data (211) from different data sources (25, 27, 29), wherein each sensor (24, 26, 28) checks whether the obtained data (211) contains anomalies, generates events (220, 221) according to the associated data (211) when anomalies are identified, and forwards the events (220, 221) to an event manager (30).

12. The method according to claim 1, characterized in that The random decision is made using a vehicle-specific and / or control unit-specific random number (273).

13. The method according to claim 9, characterized in that The specific system event is a transition of a system state.

14. The method according to claim 13, characterized in that The system state transition includes resetting, starting, and transitioning to sleep mode.

15. The method according to claim 4, characterized in that When the filling level (228) of the memory (206) is low, events (220, 221) are selected from a small number of events (220, 221) to be further processed.

16. The method according to claim 7, characterized in that The temporary range (273.x_v) is reduced by one section by omitting high-significant bits and used as the range (273.x) of the random number.

17. The method according to claim 11, characterized in that The data source is a communication system and / or a host computer (29) or a microcontroller.

Images