Method for handling data anomalies in a motor vehicle

Abstract

A method for processing data anomalies, in particular in a motor vehicle, is proposed, wherein at least one sensor (24, 26, 28) for identifying anomalies obtains data (211), wherein the sensor (24, 26, 28) checks the obtained data (211) for anomalies, wherein upon identification of an anomaly an event (220, 221) is generated depending on the associated data (211), wherein an event report (242) is generated depending on the event (220, 221), characterized in that the event report (242) comprises at least one variable (254) which changes for each event report (242) and / or is sent periodically.

Description

TECHNICAL FIELD

[0001] The present application relates to a method for processing data anomalies, in particular in a motor vehicle. BACKGROUND

[0002] DE 102018209407 A1 has disclosed 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 data streams in the communication network, wherein the at least one detector recognizes at least one anomaly by a rule-based anomaly recognition 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 recognized anomaly via the communication network.

[0003] In particular, the automatic creation of protocols, history records or reports (logging) upon recognition of anomalies or events should take place in the case of high event rates and / or long-lasting attacks without overloading and rejecting the corresponding service. The entries of the log records or the corresponding event reports should be authentic, complete and available. If possible, an indeterminate history record about a complete (long-lasting) attack should be created for the attacker. Manipulation and in particular deletion by the attacker should be avoided. Outside the control device, the log record entries should be protected from unauthorized analysis. The logger should reliably send event reports, for example via an interface to an external node. After successful transmission to the external node, the event entries can be deleted locally, in particular preferably after a confirmation, in particular an authenticated confirmation, by the receiving instance. Furthermore, the logger should send so-called heartbeat signals, which show the network connection. Accumulation of events should be possible in order to reduce the number of log record entries to be processed.

[0004] Under normal operating conditions, events (Events) are not triggered or are triggered only rarely, for example in the order of magnitude of one event per hour. In the worst case, an attacker can completely control the interface, in particular the Ethernet interface. At full bandwidth of for example 100 Mbit, an attacker can send at most 128000 UDP (User Datagram Protocol, a network protocol) frames per second. Each such frame can trigger an event (anomaly recognized in the data stream). It is assumed that such an attack occurs with a frequency of one attack per lifetime of the vehicle. The permissible number of so-called write cycles of the memory, in particular the flash memory, is limited and must be taken into account. Likewise, the number of valid operating hours is limited. Likewise, the availability of a superior external data logger is limited. Therefore, the corresponding log record events or event reports must be buffered. All log record entries or event reports should be able to be transmitted to the superior data logger at least once per day.

[0005] For conventional 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 corresponding data in the event of an identified intrusion attempt and thereby prevents the intrusion attempt), the deterministic behavior and limited resources of embedded systems are often problematic.

[0006] Instead, it is desirable to specify an improved method for identifying anomalies. This task is solved by the features of the independent claims. SUMMARY

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

[0008] The way of working of the anomaly identification is hidden from the attacker by the event report including at least one variable that changes for each event report and / or being sent periodically. By the periodic sending of the event report, the attacker cannot reconstruct whether his attack was detected or whether it was further transmitted to a superior instance. It is thereby possible to prevent old event reports from being reintroduced and thereby to generate a replay attack.

[0009] In a suitable extension it is provided that a random number and / or a time and / or a counter are used as variables that change for each event report. By the cryptographic combination with the constantly changing variables, the encrypted event report looks completely different from previous or subsequent event reports with the same event (not just 1 bit changed). This further increases the security.

[0010] In a suitable extension it is provided that the event report is transmitted to a superior instance in the motor vehicle and / or to a backend outside the vehicle.

[0011] In a suitable extension it is provided that the event manager obtains events of a plurality of sensors and generates the event report. The event report represents a summary of the last occurring events and enables a correspondingly accurate analysis of anomalies, for example in a backend, in particular if different data sources are summarized.

[0012] In a suitable extension it is provided that the event report is transmitted periodically even if no new event has occurred since the last event report was sent. The attacker cannot foresee whether his attack has been detected and further transmitted, since the event report is also sent periodically during the attack phase. By means of changeable variables and / or encryption, the attacker cannot identify the dummy data as dummy data. It is particularly preferred that the event report is created from dummy messages in the absence of new events.

[0013] In a suitable extension it is provided that the event report comprises authentication information and / or at least one selected event and / or padding data. Thereby the superior instance can check whether it is real data. It is particularly advantageous for this purpose to provide that the authentication information is formed from further information contained in the event report.

[0014] In a suitable extension it is provided that the event report always has the same length and / or is encrypted with a key. Thereby the attacker cannot see whether events were transmitted in the event report or how many events were transmitted. Thereby, the attacker cannot guess the context of the event report.

[0015] In a suitable extension it is provided that the event report is transmitted periodically and / or cryptographically from the further instance for identifying an intrusion to the backend. Thereby the non-deterministic behavior of the communication channel between the superior instance and the communication adapter or event manager is ensured, in particular in terms of feedback. Suitably, this is also achieved in that an acknowledgement signal is sent to the unit that sent the event report, in particular to the communication adapter, after the unit that received the event report obtains the event report as provided.

[0016] In a suitable extension it is provided that the transmitted event report is decrypted and / or authentication information is formed from the data contained in the event report, the authentication information is compared with the authentication information contained in the event report, and an acknowledgement signal is sent when the formed authentication information coincides with the obtained authentication information.

[0017] In a suitable extension it is provided that a signal for releasing or overriding a memory is obtained after the acknowledgement signal is obtained, in which memory at least one selected event is contained as a component of the last transmitted event report. Thereby, a further check can be made particularly suitably in the context of authentication. BRIEF DESCRIPTION OF DRAWINGS

[0018] Further advantageous designs result from the other dependent claims and the following description and drawings. In the drawings

[0019] Figure 1 schematic components of anomaly recognition are shown,

[0020] Figure 2An exemplary structure or interaction of received data, an exemplary structure or interaction of events derived from the data, a structure of associated selected events, and an event report are shown,

[0021] Figure 3 A more accurate structure of the event manager is shown,

[0022] Figure 4 A flow chart for selecting events to be further processed is shown,

[0023] Figure 5 A flow chart of the incrementing of the counter is shown,

[0024] Figure 6 A flow chart of the storing of the non-volatile memory is shown,

[0025] Figure 7 A schematic overview of the random selection of events to be stored is shown,

[0026] Figure 8 A Figure 7 Allocation of specific variables used in the method,

[0027] Figures 9-14 Different communication flows between the event manager, the communication adapter, the further IDS instance and the backend are shown. DETAILED DESCRIPTION

[0028] In connection with the aspects described below, the deviation from normal behavior will be referred to as an anomaly, which can occur in real operation for various reasons in the data 211 of a system, in particular a networked system, for example the data of a communication system or system data. Reasons for this can be, for example, the following types: a defective or completely failed sensor provides false data or no data at all, a system component is damaged, the system is manipulated by an external attack, a local attack or a physical attack, for example a hacker attack.

[0029] The recognition of anomalies in the data 211 is achieved by means of a so-called intrusion detection system IDS or IDPS. In the following, IDS denotes a system that monitors the data 211 for anomalies. The data can be, for example, data 211 at the time of a data connection in a communication network via which the control device 20 of a gateway, for example, communicates on different communication channels, for example via a bus system such as 25 or the Internet 27. However, other data 211, for example system data within a control device (or a host 29 or a microcontroller or a processor or within a chip arranged in the control device), should also be checked by the IDS system for anomalies. The detection of anomalies in the data 211 is carried out by suitable sensors 24, 26, 28. The sensors 24, 26, 28 are adapted to the respective source of the data 211, in the embodiment the bus system 25, 27 or the host 29.

[0030] According to Figure 1 , a control device, such as a gateway 20, is arranged in the vehicle 18. The control device or gateway 20 comprises a processor(s), a memory, a working memory (for example as a component of the host system 29) and an interface for communication via a communication network. The gateway 20 processes, for example, instructions for data connections. Data 211 in the form of data packets are generated by this communication. Data 211 are also generated during the operation of the host 29, for example system data. In the normal state, the data 211 comply with, for example, the recipient address and the target address, whether the correct program flow (for example for the host 29) is complied with, the time stamp, the occurrence frequency or the nominal value of the frequency of the specific data packet data 211. The data 211 of the data packets are exchanged between further control devices or components not shown in detail in the vehicle 18 to complete specific tasks. The gateway 20 serves to couple a plurality of communication systems or interfaces, such as the CAN bus 25, the Ethernet connection 27 and data connections, to the host system 29, which is a component of the control device 20 or gateway. However, other communication systems (for example further wired bus systems, such as LIN, CAN-FD, etc.) or wireless networks (for example WLAN or Bluetooth) can be coupled to each other by the gateway 20 for data exchange. In general, an intrusion recognition IDS or anomaly recognition is used in the control device to monitor all data 211 (data 211 received by the communication systems and data 211 generated within the control device 20 by the host 29) for the presence of corresponding anomalies. In embodiments, the IDS function mechanism is exemplarily described for the gateway 20. However, in general, the described anomaly recognition or intrusion recognition IDS function can be implemented in any control device or any electronic component. In particular, this use is not limited to the vehicle 18. Rather, any communication component, for example a communication module in the Internet of Things or in a networked production system, can be equipped with the described function.

[0031] The communication components, such as the control device or gateway 20, comprise at least one anomaly recognition 22. The data 211 input via the interface of the respective communication system 25, 27, 29 is guided via so-called sensors 24, 26, 28 for recognizing anomalies or recognizing intrusions, in short IDS sensors. Corresponding sensors 24, 26, 28 are thus arranged in the gateway 20. Such sensors 24, 26, 28 serve to recognize whether the obtained data 211 shows anomalies. For this purpose, corresponding filter algorithms or rule sets for detecting and classifying anomalies are stored in the sensors 24, 26, 28. If the sensors 24, 26, 28 determine an anomaly, the corresponding data packet of the data 211 is classified as an event 220 (attempted intrusion). In general, the sensors 24, 26, 28 can classify different anomalies as events 220 (assigning the respective event 220 to a specific event type 218) and recognize these anomalies depending on the source 25, 27, 29. Depending on the respective event type 218 (different anomaly types in the data 211), the sensors 24, 26, 28 aggregate specific event-related metadata 216 to the associated event 220. In addition, the event-related metadata 216 can also contain data or data components of the anomaly data 211. The events 220 generated in this way are forwarded to the event manager 30. The sensors 24, 26, 28 are generally designed to forward the associated data 211 of the communication system, for example the bus system 25, 27, to the specified address without anomalies. In the event of an anomaly being recognized, 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 serve to reduce events 220 (reduced events or pre-reduced events 221). By means of this reduction, the load on the event manager 30 can be reduced, for example, by forwarding only a small part of the useful data of the data 211 or data packets containing anomalies. This is particularly advantageous in the case of large amounts of data, as occurs, for example, in the case of an Ethernet connection.

[0032] The IDS CAN sensor 24, for example, serves to recognize anomalies in the case of a CAN bus 25, the IDS Ethernet sensor 26 serves to recognize anomalies in the case of an Ethernet system 27, and the IDS host sensor 28 serves to recognize anomalies in the case of a 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 anomaly sources in the respective source and classify them if necessary.

[0033] IDS CAN sensors 24 detect relevant events 220 of associated event types 218, for example invalid CAN-ID, invalid message frequency, invalid message length, etc. IDS Ethernet sensors 26 detect relevant events 220 of associated event types 218 for Ethernet 27, for example invalid address or MAC address, invalid message frequency, invalid message length, etc. IDS host sensors 28 detect relevant events 220 of associated event types 218 for host system 29, for example invalid code execution, program corruption, stack counter, etc. The respective event types 218 are usually provided with event-specific event IDs. There are a large number of predefined event types 218 for different data sources with associated unique event IDs.

[0034] The following further anomalies can be considered as events 220 for further event types 218. These are, for example, events 220 or event types 218 that can be assigned to a firewall, for example frame loss due to buffer full, filter violation (stateless / stateful), transmission rate limit active or inactive, monitoring mode active or inactive, context transformation. Further anomalies involving the host system 29 can also be considered as events 220 with associated event types 218, for example CPU load too high, memory access violation, error at code execution, ECU reset detected, log entry corruption in non-volatile memory, log record memory overflow, denial of event, MAC address port change, etc.

[0035] The event manager 30 serves to further process the input events 220 or the event-related metadata 215 contained in the respective events 220. In particular, the event manager 30 serves to aggregate, format or prepare the events 220 and / or to prioritize and / or reduce / select and / or store or keep or permanently store the selected and / or reduced events 220, 221. In particular, the event manager 30 decides which of the input events 220 should be further processed. The events selected from the input events 220 are referred to as selected events 226. The corresponding selection should be made as non-deterministic as possible. In addition, the event manager 30 sets further general metadata 217, in particular for the input events 220 or the selected events 226. Thereby, it is possible to observe the events 220 transmitted by the different sensors 24, 26, 28 at a higher level, for example by adding the number of events occurring, the associated timestamps or time signals 224, etc. in the scope of the general metadata 217. In addition, it is ensured that even in the case of so-called event bursts, a sufficient number of convincing events 220 can be stored as selected events 226.

[0036] The event manager 30 exchanges signals with a communication adapter 32 of the intrusion detection or anomaly detection. The communication adapter 32 serves as a communication means for exchanging data between the event manager 30 and further components 34, 36 outside the anomaly detection 22 of the control device or gateway 20. In particular, the communication adapter 32 serves as an interface for exchanging data between the event manager 30 and a further IDS instance 34, preferably within the vehicle 18, and / or a backend 36, preferably outside the vehicle 18. The further IDS instance 34 can be optionally provided only.

[0037] For improving security, the event manager 30 can perform a random, non-deterministic for an attacker and hidden reduction and prioritization of the events 220, 221. Thereby, the non-volatile storage of selected events 226 can be performed randomly, non-deterministic for an attacker and hidden. The randomly controlled selection can be based on a random number 273 specific to the control device alone, for example. Likewise, 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 stores the added generic metadata 217 as selected events 226 randomly.

[0038] For improving security, the communication adapter 32 can upload or send the event reports 242 randomly, non-deterministic for an attacker and hidden to the further IDS instance 34. The randomly controlled upload can be based on a random number 273 specific to the control device (or gateway 20) alone, for example. Thereby, a specific event 220 can be transmitted periodically and encrypted in the scope of the event reports 242. However, even without a new event 220, a so-called dummy event can be transmitted periodically and encrypted in the format of the event reports 242. This serves to prevent the exchange of data between the communication adapter 32 and the further IDS instance 34 or the backend 36 from being tapped or randomly hidden.

[0039] In conjunction with Figure 2 It is exemplarily shown how the data 211 are further processed by the sensors 24, 26, 28 and sent to the event manager 30 in the event of an anomaly being detected, until the event manager sends the event reports 242 via the communication adapter 32.

[0040] In Figure 2 It is exemplarily shown in a the data packet of the data 211, which can occur in a network frame (e.g. CAN, Ethernet), for example. The data 211 have a header 214 comprising a source address and a target address (e.g. MACa, MACb), for example. In addition, the data 211 comprise useful data 213.

[0041] As described in more detail below, sensors 24, 26, and 28 can optionally randomly select useful data areas 219 to forward to event manager 30. Sensors 24, 26, and 28 have determined that this is an anomaly based on a specific event type 218 (event ID, ID). Therefore, sensors 24, 26, and 28 generate data such as... Figure 2 The event-related metadata 216 is shown in b. Different information about the anomaly can be stored in the event-related metadata 216 based on the event type 218 (or ID). In this embodiment, the event-related metadata 216 specifically uses the source and destination addresses (MACa, MACb), the event type 218, and a selected useful data area 219.

[0042] Alternatively, the useful data 213 related to the event can be forwarded to the event manager 30 in its entirety within the scope of event 220.

[0043] Alternatively, event 220 may not include event-related useful data 213, such as when host 29 is used as the source. This could be event type 218, such as information about a data frame being lost due to a full buffer, activation or deactivation of watch mode, excessive CPU load, corrupted entries in non-volatile memory 208, log buffer overflow, event reduction being effective, and so on.

[0044] Furthermore, for different event types 218, additional event-related information within the scope of event-related metadata 216 may be part of event 220. In the case of event type 218 "Context Change," event-related metadata 216 may include, for example, a context, such as a 32-bit context. In the case of event type 218 "Memory Access Violation" or "Code Execution Violation," event-related metadata 216 may include, for example, an access address (e.g., 32 bits), a program counter (e.g., 32 bits), and a task ID (e.g., 8 bits). In the case of event type 218 "Control Device Reset Detected," event-related metadata 216 may include, for example, the reason for the reset (e.g., 8 bits), such as POR (Return Point), software reset, exception, etc.

[0045] The Ethernet-related event 220 below can 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), the ID of the filter rule that caused event 220 (if available), the physical port address, the physical port ID through which the frame was obtained, the source address (e.g., MAC address, e.g., 48 bits), the destination address (e.g., MAC address, e.g., 48 bits), the possible IP address of the source or destination, and the specification of the UDP / TCP port (e.g., 16 bits, optional if present in the frame). Alternatively, static / state-related filter violations can also be recorded together, such as the rule ID, physical port, frame (number of bytes), the specific number of bytes stored in the received frame, the selected useful data region 219 (specific number of bytes), the selected useful data region 219 in the original frame, the useful data region 219 index (e.g., 16 bits), and the starting byte of the selected useful data region 219 in the original frame. Other Ethernet-related events can also be included in event 220 transmitted to event manager 30. For example, for event type 218 "Transmission rate limited (valid / invalid)", it is the rule ID with the associated ID of the filter rule that caused event 220; for event type 218 "Change context", it is the context (e.g., 32-bit); and for event type 218 "Address hop" or "MAC hop", it is the old port (the physical port ID originally assigned to the address), the new port (the physical port ID of the recently observed address), and the address (preferably the MAC address). However, event type 218 without metadata 216 may also occur, such as "Frame loss due to buffer full", etc.

[0046] Therefore, the forwarding of event-related useful data 213 depends in particular on the source of data 211 with associated event type 218. Metadata 216 is transmitted to event manager 30 as event 220 or reduced event 221 (due to the random selection or reduction of useful data area 219 to be transmitted in sensors 24, 26, 28).

[0047] If Event Manager 30 selects event 220 or 221 for further processing (selected event 226), as explained in more detail below, then general metadata 217 is also added to event-related metadata 216, thereby generating... Figure 2Metadata 215 is shown in c. General metadata 217 is typically generated in event manager 30. This is, for example, the output signal of event counter 204, i.e., the current counter reading 231, indicating how many global events 220 or how many events 220 currently have a specific event type 218. Furthermore, general metadata 217 may include, for example, a time signal 224 regarding when the event 220 occurred. Additionally, metadata 217 may include the length 232 (data size) of event-related metadata 216 or complete metadata 215. This is advantageous for subsequent memory management of buffer memory 206.

[0048] The following general metadata 217 is presented as an example. This could be, for example, an event type 218 within the range of event IDs (e.g., 8 bits). This event ID of event type 218 is unique and may include, for example, TLV-based encoding (TLV: Type-Length-Value). General metadata 217 includes a length 232, for example, between 8 and 16 bits in size. The size of the data (metadata 215) follows the length field in bytes, up to a maximum of 255 bytes. TLV-based encoding can also be set. A time signal 224, i.e., a timestamp (e.g., 64 bits), is also included. For example, the time 224 is described as an absolute time value (in milliseconds) elapsed since a reference time such as January 1, 1970, to describe a unique timestamp. In addition, general metadata 217 may include counter readings 231 or output values ​​231 (e.g., 32-bit) of event type counter 204 and / or counter readings 231 (e.g., 32-bit) of global (event) counter 204, and the sum of all counter readings 231 of event counter 204 for each event type 218.

[0049] Event-related metadata 216 is managed in the form of metadata formed by the corresponding sensors 24, 26, and 28. The event 220, having corresponding metadata 215 formed by both sensors 24, 26, and 28 and the event manager 30, is stored in the buffer memory 206 of the event manager 30. Similarly, additional events 226 (based on...) are selected or reduced by the event manager 30. Figure 2 In the embodiment of d, exemplarily represented as 215_1, 215_8, 215_190, the data are stored in buffer storage 206, as will be explained in more detail below.

[0050] The selected event 226 (in accordance with) stored in buffer memory 206 Figure 2In the embodiment of d, 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. This event report includes the selected events 226 (215_1, 215_8, 215_190 in this example) stored in buffer memory 206. These selected events 226 are previously variables 254 (e.g., random numbers, time, or counters) that have changed relative to each event report 242. Furthermore, the event report 242 also includes authentication information 256. This authentication information allows authentication between the communication adapter 32 or event manager 30 and the unit receiving the event report 242 (IDS instance 34, backend 36, etc.). The event report 242 includes a fixed length 258. To achieve this fixed length of 258, data 254, 215_1, 215_8, 215_190, and 256 are still padded with so-called padding data 255. This padding data 255 does not contain event-related information. For example... Figure 2 As shown in d, the data shown in event report 242 is encrypted with encryption 258 before transmission. Event report 242, encrypted in this way with encryption 258, is sent by communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36, as described.

[0051] IDS sensors 24, 26, and 28 forward event 220 or reduced event 221 to event manager 30. It is precisely in an Ethernet network, under attack intent, that when there are a large number of events 220 to be forwarded with large amounts of data or event-related metadata 216, memory 206, especially volatile memory or buffer memory 206, may quickly become unable to hold all events 220. This is due to the high data transmission rate or the large amount of data that can be transmitted. Therefore, it is meaningful that one or more IDS sensors 24, 26, and 28 have pre-selected events 220 to be forwarded and / or data reduction (reduced event 221) according to specific criteria. These criteria should be characterized by low predictability.

[0052] In the case of IDS sensors 24, 26, and 28, and especially in the case of IDS Ethernet sensor 26, it is preferable to randomly and arbitrarily select specific events 220 to be forwarded and / or reduce events to reduced events 221 for enhanced security. The random or arbitrary selection or reduction of data blocks of specific events 220 or Ethernet frames is nondeterministic and hidden from attackers. The randomized selection or reduction can, for example, be based on a separate random number 273 for a specific control device. In the simplest case, the same random number 273 can also be used in other random-based scenarios, as a reference in the event manager 30 for reducing or prioritizing all events 220, random storage of events 220, etc. Alternatively, the corresponding random number can be regenerated in the control device.

[0053] The input message or data 211 typically has a corresponding header information 214 (e.g., specific address data) and subsequent useful data 213. It usually contains much header information that is not absolutely necessary for anomaly assessment. According to the invention, only the absolutely necessary specific address portions are forwarded as part of the reduced event 221 within the scope of event-related metadata 216, such as the source address (e.g., MAC address, e.g., 48-bit), the destination address (e.g., MAC address, e.g., 48-bit), and the ID number that caused the anomaly (event type 218). Other information—such as the physical port or port ID of the received frame, the source or destination IP address, and a description of the UDP / TCP port of the source or destination (if such information is included in the frame)—does not need to be transmitted in its entirety in event 220.

[0054] However, the useful data region 219 to be forwarded or selected is randomly selected from the useful data 213 of the input data 211, as if already combined. Figure 2The explanations in a and 2b are as follows. Thus, for example, the starting data number (the beginning of the storage area for the useful data to be transmitted, e.g., byte number xyz) can be randomly set (e.g., transmitting a data area whose initial value is randomly determined, e.g., useful data byte number 538 for event 220). The offset of the selected useful data area 219 (the amount of data transmitted, e.g., 10 bytes) can be fixed. Therefore, in addition to the minimum address information (source address, destination address), the useful data bytes numbered 538-547 are forwarded to the event manager 30 as the selected useful data area 219 within the range of event 221 reduced in this way. Alternatively, the offset of the selected useful data area 219 (the amount of useful data transmitted) can also be changed, preferably randomly. Preferably, the selected useful data area 219, particularly the starting or ending area of ​​the selected useful data area 219, depends on a random number 273. This random number 273 is particularly preferably dependent on the control device or gateway 20. Particularly preferably, the random number 273 is unique, i.e., given only once for this particular control device.

[0055] However, alternatively, random number 273 can also be updated. This yields the following advantages. By updating the random number, different events 220 can be recorded or selected even when the attack sequence (event 220 sequence) is the same. This is also the case when the attack targets only a single control device / vehicle 18 rather than the entire fleet. The following assumptions / examples:

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

[0057] 2. Update random number 273 between attack sequences.

[0058] 3. Not all events 220 (event bursts) can be logged or selected within the scope of an attack sequence. This is followed by an event reduction for event report 242.

[0059] 4. Event report 242 with reduced event 221 is fully forwarded to parent instances 34, 36 between the two attack sequences. Thus, after repeating the same attack sequence multiple times, the complete attack sequence can be reconstructed through event report 242.

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

[0061] By uniquely assigning a random number 273 to the corresponding control device 20, in the presence of other control devices, during analysis in the backend 36, by merging numerous reduced events 221 from multiple control devices, a complete message with a complete data area may be synthesized (which also arrives at the other control devices and is correspondingly detected and forwarded in a reduced manner by the corresponding equipped sensors 26). This is because other control devices with the same sensor functionality, as described above, now also randomly select other useful data areas 219 (with other randomly selected start or end addresses), which, after merging multiple reduced events 221, can cover most or all of the (useful) data area 213 based on sub-areas of different control devices or selected useful data areas 219. Event 220 can thus be reconstructed from reduced event 221 or selected useful data area 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 another selected useful data area 219) from another control device, and sub-data areas 558-567 (of another selected useful data area 219) from yet another control device, and the corresponding selected useful data areas 219 are then recombined into a complete (useful) data area 213, for example, in a higher-level control device or in the backend 36. This is particularly true in the case of a so-called broadcast attack on the entire fleet or a so-called multicast attack on a portion of the fleet.

[0062] Preferably, the start and / or end of the forwarded or selected useful data area 219 is re-randomized after a specific event (periodically, startup of the control device, reset of the control device, etc.). For this purpose, for example, random number 273 can be regenerated. Alternatively, other ranges of 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.

[0063] The processed, reduced event 221 is forwarded from sensor 26 to event manager 30. Therefore, event manager 30 does not obtain the complete data stream of these network frames from sensor 26, but only the reduced event 221 with a reduced data size. The reduction of the forwarded event 221 is exemplarily described based on 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 Ethernet frames with high transmission rates, such an event 220 would quickly cause buffer memory 206 to overflow. In the case of IDS CAN sensor 24, the corresponding data 211 appears at a lower data rate and with a smaller data volume, so that the event 220, which tends to be complete, can be forwarded and stored here. However, in principle, the data can also be reduced there, as described correspondingly.

[0064] Therefore, the following steps are performed in principle to reduce event 220 in sensors 24, 26, and 28. Data 211 is received from sensors 24, 26, and 28 and / or evaluated to determine if an anomaly exists. If an anomaly exists, data 211 is reduced. This reduction is performed by reducing address regions or headers 214 and / or data regions or useful data 213. Reduction of address regions 214 can be performed by selecting a target address and / or a source address. Reduction of useful data 213 is performed randomly. Useful data 213 is reduced randomly by randomly selecting the start and / or end values ​​of sub-regions of useful data 213. The offset of the data region (the amount of data transmitted) is set to a specific value. The reduced event 221 is transmitted to event manager 30. The reduced event 221 contains the reduced address data and / or the reduced or selected useful data 219. Random number 273 is updated according to a specific system state (periodic, startup, reset, etc.). Alternatively, the update of random number 273 can be performed randomly and / or time-controlled. The random number 273 used to specify the start or end region of the selected useful data region 219, or the range of the random number 273, can depend on the size of the useful region 213 of the received data 211.

[0065] according to Figure 3The structure of the event manager 30 is shown in more detail below. The event manager 30 has multiple interactive functional blocks. Each event 220 or reduced event 221 detected by sensors 24, 26, and 28 reaches block 202. Block 202 is used to select which of the input events 220 or reduced events 221 should be further processed. Specifically, block 202 is used to prioritize and reduce events 220 and 221.

[0066] Each event 220 or each decreasing event 221 also reaches block 204, which serves as a counter 204 for events 220 and 221. Upon occurrence of events 220 and 221, the corresponding counters are incremented, particularly the global event counter 205. Counter 204 preferably has different counters Z1, Z2, ... Zn for different event types 218 (ID1, ID2, ... IDn), as detailed above in conjunction with the corresponding sensors 24, 26, and 28. The global event counter 205 represents the sum of all counter readings for the different event types 218 (ID1, ID2, ... IDn) Z1, Z2, ... Zn. The output signal 231 of block 204 or the counter contains the counter readings for all events 220 and 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 block 204 is sent to block 210 to transmit event 220. Block 204 is configured 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 from block 202 for the reduction state 225, such as "Event Reduction Valid". In block 202, event reduction is valid, for example, when only a specific number of events 220, 221 are reduced and further processed as the selected event 226. This is particularly true when, for example, a large number of events 220, 221 are input within a so-called event burst range, accompanied by an increase in the fill level 228 of the buffer memory 206. In this case, an additional event 220 should be generated, for example, using event type 218 "Event Reduction Valid" as described above. Thus, for this event 220' with the associated event type 218, there is also a corresponding counter or counter reading.

[0067] The event processed by block 202 arrives at block 206 as the selected event 226. Block 206 serves as a memory or buffer for the selected event 226 delivered from block 202 and includes corresponding logic for this. In response, memory 206 reports a fill level or memory occupancy 228 back to block 202. Memory 206 is preferably a volatile memory, particularly a buffer for RAM. Furthermore, a time signal 224, particularly a global time signal 224, arrives at memory 206 or at the block used to buffer the selected event 226. Memory 206 is a component of event manager 30.

[0068] A specific event 236 stored or buffered in memory 206 arrives at block 210, which transmits an event report 242 based on the selected event 226 or the stored event 236. Block 210, used for transmitting the event, also receives the output signal 231 of event counter 204, such as the counter readings of counters Z1, Z2...Zn for the corresponding event type 218 and / or the counter reading of the global event counter 205. Block 210, used for transmitting events, particularly event report 242, exchanges signal 244 with cryptographic module 212. This cryptographic module performs cryptographic operations such as encryption, verification and authentication, and random number generation. Encrypted communication from block 210 to the outside world can be performed by means of cryptographic module 212. Specifically, cryptographic module 212 uses... Figure 2 The encryption 257 shown in d encrypts the event report 242. Similarly, the cryptographic module 212 can also use authentication information 256 to authenticate the event report 242, see also [reference 256]. Figure 2 d. Block 210 may reside in communication adapter 32 and / or event manager 30. Block 210 outputs the corresponding event report 242. Block 210 receives a request command 240 requesting the reading of the corresponding event 236 stored in 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 memory 206. Thus, generally after the successful transmission of the associated event report 242, which also contains the stored event 236 or the selected event 226, memory 206 or 208 is notified to allow overwriting or deleting the stored and further transmitted events 236, 226.

[0069] In addition, an additional memory 208, specifically non-volatile memory, is provided in the event manager 30. The counter readings of a specific event 234 and / or event counter 204 that were previously cached in the buffer memory 206 are permanently stored in this additional, specifically non-volatile memory 208. For this purpose, memory 208 exchanges data with event counter 204 and / or with buffer memory 206.

[0070] The following is based on Figure 4 The workings of block 202 for prioritizing and reducing events 220 are described in more detail. The mechanism described below is used to select whether metadata 215 that is additionally helpful (and consumes a large amount of memory) to events 220, 221 should be stored. More generally, block 202 is used to select events 226 for further processing from events 220, 221 delivered to event manager 30. For each event type 218 of the obtained events 220, 221, it is tracked whether it is the first occurrence of that particular event type 218 or whether an event 220 with event type 218 has already been sent to memory or buffer 206; i.e., query 301. If event type 218 is the first occurrence, then the next step is block 304, where the corresponding event 220 is transferred to buffer 206 as the selected event 226 and stored there. Otherwise, the next step is block 302. In step 302, it is determined according to certain criteria whether events 220, 221 that have already occurred with event type 218 should still be stored. This is, for example, after events 220 and 221 have been randomly selected, particularly based on random number 273. This random selection can be particularly preferably based on a control device-specific or vehicle-specific random number 273. An intelligent algorithm should be used for the random selection to limit the overflow of buffer memory 206 in the worst-case attack scenario (a long-duration attack with so-called event bursts). On the other hand, a reasonable number of stored events 236 or selected events 226 or log entries should be maintained in normal scenarios to detect the widest possible range throughout the attack. To this end, in step 303, event 220 selected in step 302 is transferred to memory 206 as selected event 226 for storage.

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

[0072] For additional priority settings, events 220 and 221 can optionally be grouped according to their respective event types 218, and separate instances can be set to randomly reduce the number of events for each event type 218. Priority settings can also be implemented additionally by forming groups. This means assigning event types 218 to different priority groups. For example, assigning a specific event type 218 (e.g., event type 218 with ID numbers ID1, ID6, ID14, ID23, etc.) to the priority group with the highest priority (Prio 1), assigning another associated event type 218 (e.g., event type 218 with ID numbers ID2, ID5, ID12, ID27, etc.) to the next lower priority group (Prio 3), and so on. For different priority groups (Prio1, Prio2, Prio3, ...), a different number of events 220 are randomly selected on average as the selected events 226 (N1: the number of events selected in priority group 1 (Prio1), Nx: the number of events selected in priority group x (Prio_x)). In priority groups with higher priorities, more events 220 are randomly selected on average than in priority groups with lower priorities (N1>N2...). This can be achieved, for example, by selecting regions B1, B2...Bx (with associated priority groups Prio1, Prio2...Prio_x) from which events 220 are chosen, or by selecting smaller numbers, indicating higher priorities (B1...Bx...Bx). <B2...)。

[0073] The selected event 226 is stored in volatile memory 206. However, the selected event 226 should not be immediately stored in non-volatile memory 208, as too frequent storage may damage non-volatile memory 208. For example, in combination with... Figure 6 To explain in more detail, the selected event 226 can be randomly stored in non-volatile memory 208.

[0074] One or more memories 206, 208 can handle selected events 226 of different sizes. Here in Figure 7The image exemplarily illustrates memory 206. This memory includes a free storage area 250 and a filled storage area 252. In the filled storage area 252, multiple selected events 226 or 226 are stored. These entries 226 can each have different sizes. Due to the non-rigid partitioning of the storage areas, the storage space is optimally utilized. If memory 206 is full, a new selected event 226 is discarded. However, in principle, memory 206 is prevented from being filled through a self-regulating mechanism as described below. Thus, when the fill level 228 of memory 206 is very high, on average, far fewer events 220 are randomly selected than when the fill level 228 of memory 206 is low. However, if a selected event 226 is discarded due to buffer 206 being full, an event counter implementing a new event type 218 "logging buffer overflow (memory 206 overflow)" is used to determine the number of discarded events or entries. Figure 3 As shown, this can be done, for example, by notifying the counter 204 of the state 230 of the memory 206, or by always sending a pulse to the counter 204 at another selected event 226 when the memory 206 is full and cannot store anything.

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

[0076] 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 range of event counter 204. Event counter 204 starts with a value of zero. First, it is determined whether the counter reading is still less than the maximum value, i.e., query 260. If this is the case, the counters Z1, Z2...Zn for the corresponding event type 218 are incremented when events 220 and 221 of a specific event type 218 occur, i.e., step 262. Otherwise, the counter reading is kept at the maximum value so that no overflow occurs. Event counter 204 can be reset to zero upon request. For example, counter 204 can be implemented as a 32-bit counter.

[0077] according to Figure 6The non-volatile storage of event counter 204 and / or a specific selected event 226 in non-volatile memory 208 is described. Data should be stored in non-volatile memory 208 at regular time intervals. Such time intervals are, for example, in the range of seconds, minutes, to hours, such as data being stored every 30 minutes. The storage time points should be randomly selected so that an attacker cannot predict the write behavior. The storage period can be randomly controlled, for example, at specific intervals (e.g., within 30 minutes, however, the exact storage time point within, for example, the 30-minute interval is randomly controlled). Random variables (used to specify the storage time points) can be generated or selected based on random number 273 individual to the control device or vehicle.

[0078] Alternatively, a time-controlled storage moment can be randomly selected by multiplying a random number by a base time interval. Thus, for example, a specific base time interval of 15 seconds is multiplied by, for example, a 3-bit random number or a range of random numbers 273. Random number 273 itself can be updated periodically and / or randomly. Alternatively, random number 273 can be individually given, controllable specifically for a particular device or vehicle, such as in production and manufacturing. Alternatively, a specific range of random number 273 can be selected, on which a factor dependent on the range of random number 273 is formed.

[0079] Once a new selected event 226 occurs and can be stored in 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, for example due to a request for a reset or sleep mode, resulting in the loss of the current RAM contents (and thus the loss of buffer memory 206) (which could also be caused by an attacker), the storage of the selected event 226 (in memory 206) and / or other information (such as a specific counter reading 232 of event counter 204) in non-volatile memory 208 is initiated.

[0080] Data should be stored redundantly so that it can be recovered even if some data is damaged. After reading 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 located in a trusted area. It is assumed here that the memory inside the IC is classified as trusted. Standard AUTOSAR NVM (non-volatile memory) processing procedures can be used for this purpose.

[0081] exist Figure 5The diagram illustrates a state diagram for storing the selected event 226 in non-volatile memory 208. When state 264 is reached, data can, in principle, be stored in non-volatile memory 208. Storage in non-volatile memory 208 is not possible in state 266. The transition from state 264 to state 266 occurs after storage has been performed. The transition back to state 264, where storage is possible, is time-controlled. Preferably, the timing is random, as already described. When the control device is not ready for hibernation or reset, the system remains in state 266 (no storage).

[0082] Figure 7 A more accurate illustration of the components of the event manager 30 is shown. Multiple events 226 are stored in a buffer 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 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 stored in the buffer 206 as selected events 226.

[0083] The unfilled or remaining areas of the buffer memory 206 form a free storage area 250.

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

[0085] In function block 268, the current memory region 267.4 where the current fill level 228 of memory 206 is located is determined. The current fill level region 267 (in this embodiment, it is used as the fourth region 267.4) reaches block 270.

[0086] In block 270, the offset 271 of the next event is determined. Offset 271 indicates how many events 220 should be selected from to store the next event 226 in memory 206. This number of events 220 (offset 271) depends on the corresponding fill level 228 or 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 storage area 267 is low (the fill level 228 of memory 206 is relatively low), events 20 are stored faster, and therefore offset 271 is relatively small. As the fill level 228 or storage area 267 increases, offset 271 increases, i.e., fewer events 220 are stored or events 220 are selected only from a larger number (offset 271). This allows for targeted delays or prevention of memory 206 overflow. Within offset 271, the next event 226 to be stored is randomly selected. For each offset 271, only one event 220 (within offset 271) is always randomly selected or stored. Therefore, by varying the offset size according to the fill level 228 of memory 206, more or fewer events 220 are randomly selected or stored on average. Thus, as long as the fill level 228 of memory 206 is within a specific 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, typically increasing, offset 271.

[0087] If you leave the storage area 267 defined by the lower or upper limit value, you can increase or decrease the next offset 271 of the new area, for example, by increasing it by a certain multiple or decreasing it by a certain divisor.

[0088] Exemplary illustration based on Figure 8 The corresponding scenario in the table causes memory 206 to be occupied, such as... Figure 7As shown. Offset 271 can be selected for different fill levels 228 or storage regions 267, as illustrated below. Thus, for example, for a storage region between 0 and 10% (267.1), offset 271 can be assigned to 2 (from zero to 2, thus selected from three events 220), for a storage region between 10% and 20% (267.2) to 8 (from 0 to 8, thus selected from 9 events 220), for a storage region between 20% and 30% (267.3) to 32 (from 0 to 32, thus selected from 33 events 220), and for a storage region between 30% and 40% to 128 (from 0 to 128, thus selected from 129 events 220), and so on. For example, a corresponding increase in offset 271 for the next storage region 267 can be achieved by a corresponding factor (4), etc. Both storage area 267 and offset value 271 can be freely configured, thus adapting to their respective desired conditions, such as memory size.

[0089] exist Figure 7 In subsequent block 272, it should now be randomly (according to) fill level 228 or storage area 267. Figure 7 The random number 273 (exemplarily shown) is used to select the next event 220 to be stored. Here, 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 corresponding event 220 to be stored should be randomly selected—can be covered by the random number 273 or a corresponding range of random number 273. The size of the range of random numbers 273 to be considered is selected according to the corresponding offset 271. If the random number 273 is, for example, bit-encoded, such as... Figure 7 As illustrated in the example, for example, at an offset of 271 (0-2), a temporary range of two-digit random numbers, 273_temp, is first selected. At an offset of 271 (0-8), a range x of four-digit random numbers, 273.x_v, is selected. At an offset of 271 (0-32), a temporary range of six-digit random numbers, 273_v, is selected. At an offset of 271 (0-128), a temporary range of eight-digit random numbers, 273_v, is selected. The temporary range of random numbers 273_v can be found in column 4, where... Figure 7The specific random number 273 is illustrated by example. Then, it is checked whether the portion of 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 also used as a random number range as part 273.x of the random number. The corresponding query in column 5 can be answered with "true". In these cases, the temporary portion 273.x_v of the random number is consistent with the selected random number portion 273.x. If this is not the case (the query in column 5 is answered with "false"), the temporary portion 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.

[0090] Thus, for example, for an offset of 271 (0-8) of 8, consider the first 4 bits of the random number 273 so as to also cover the number 8 itself (the size of the current offset 271), for which see Figure 8 The column contains buffer entries numbered 3, 4, and 5. If the associated temporary random number range 273.5_v is less than or equal to the 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 The 5th column. Since the condition is met, the result is "true".

[0091] If the 4-bit value of the associated temporary random number range 273.4_v is greater than the offset 271—for example, for event number 13, 273.4 = 0b1100 = 12—then the 4-bit number is not used directly. Instead, the MSB (the most significant bit of the considered random number range 273.4) is truncated, and the resulting 3-bit number 0b100 = 4 is used. The truncated MSB is not discarded but is used as the LSB (least significant bit) of the next 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 random number 273 is fully utilized and is not unnecessarily depleted quickly.

[0092] In order to determine the size of the random number range 273.x (e.g., the number of bits required for the range of random number 273), it must be considered whether the variables (e.g., the required number of bits) used to represent the size of the offset 271 of the associated storage area 267 of the next event 220 are sufficient.

[0093] Therefore, according to Figure 8In the embodiment, according to line 1, when the selected random number 273.1 is 2, event number 2 (220.2, global event counter 285 is 2) is selected as event 226.2 when the offset 271 is 2 (from 0 to 2) (after discarding events 220.0, 220.1, numbers 0 and 1). According to line 2, in the next offset range 271 (still in 0 to 2), event number 1 related to the offset range 271 is randomly selected. Event number 0 in the offset range 271 has been discarded (corresponding to global counter reading 285 of 3), but event number 1 in the offset range 271 is selected (corresponding to 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 to 2) because the fill level 267 of buffer 206 is still in the region 267.1 between 0 and 10%. The random number for 273.3 is 2, so after discarding event numbers 0 and 1 in the offset range 271, event number 2 is selected (global counter reading 285 is 8, the selected event is 226.8). Since the subsequent padding level 267 is in the next padding level range 267.2, the new offset 271 now becomes 8 (0-8). As mentioned above, the next 4 bits of the temporary random number range 273.4_v are now considered. Since the associated random number for the temporary random number range 273.4_v is 12, which is greater than the current offset 271 (the query 12<=8 in column 5 yields "false"), the most significant bit of the temporary random number range 273.4_v is not used; instead, only the 3 least significant bits (binary 100, i.e., 4) within the selected random number range 273.4 are used. Therefore, for this new offset range 271 of 8 (0-8), event number 0 (global counter reading 285 is 9) is discarded to number 3, and event number 4 (global counter reading 285 is therefore 13) is selected as the chosen event 226.13. Figure 8 The corresponding values ​​for the additional fill level 267 are combined as an example.

[0094] Therefore, in block 272, it has now been randomly determined which event 220 will be selected next as the chosen event 226. The corresponding block 280 now monitors for the occurrence of a new event 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, discarding the next event numbers 9-12 and storing event number 13 as the chosen event 226.13 in memory 206. Based on the new chosen event 226 with data size of metadata 215 (event-related metadata 216 and general metadata 217), a new fill level 228 for memory 206 is determined. This can be done particularly simply, for example, using length 232 already included in metadata 215.

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

[0096] Block 272 determines the next event hit 278 from the corresponding information (next event hit: the next event hit 278 at the next offset 271). The next event hit 278 reaches block 280 (throw the dice), where the delivered event 220 is either discarded (event 220 is not stored in buffer memory 206) or selected as the chosen event 226 for storage in buffer memory 206. If a selection is made (event hit 282), then block 284 is next. 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 about whether event 220 should be selected. If event 220 is selected by block 280, then block 284 triggers the storage of event 220 as the selected event 226 in memory 206.

[0097] In block 284 (on event), the selected event 220 is read in and subsequently stored as the selected event 226 in the free area 250 of buffer memory 206. Block 284 is always invoked for each new input event 220, 221. Block 284 is used for random selection, including possible reductions and priority settings of input events 220, 221.

[0098] In addition to the random selection in block 280, event 220 can also be randomly reduced, as described with ETH sensor 26. This allows for the random selection of specific data regions (preferably the beginning or end of a fixed data region). Similarly, only the specific reduced address data can be stored.

[0099] Similarly, when event 220 occurs frequently, or when sensors 24, 26, and 28 themselves (in the case of a specific source, such as Ethernet) can select or reduce event 220, similar to quasi-pre-filtering in event manager 30, to reduce the burden on event manager 30 (which also receives events 220 from other sources). If sensors 24, 26, and 28 have not yet forwarded each event 220 to event manager 30, this should also be transmitted to event manager 30 as a separate event type 218 (similar to reduction state 225 in event manager 30). However, in general, the event-related selection of event 220 can be made within sensors 24, 26, and 28 themselves and stored in their buffer memory. Similarly, corresponding counters can be set in sensors 24, 26, and 28 for the respective event type 218, which can be transmitted to event manager 30 when needed. Event 226' selected by sensors 24, 26, and 28 can also be transmitted to event manager 30 upon request, so as to be forwarded to the parent instance 34 and / or backend 36 if possible. Nevertheless, the procedures for random selection and / or priority setting described in conjunction with event manager 30 can still be run in sensors 24, 26, and 28. However, these procedures can be limited to specific data 211 from the corresponding source, so sensors 24, 26, and 28 can select only sensor-specific events 220.

[0100] To enhance security, the communication adapter 32 may be configured to send event reports 242 randomly, nondeterministically, and covertly to other IDS instances 34.

[0101] If already combined Figure 2As described in d, an event report 242 is generated from selected events 226 stored in buffer memory 206. This event report includes the selected events 226 stored in buffer memory 206. These selected events 226 are preceded by variables 254 (e.g., random numbers, time, or counters) that change relative to each event report 242. Furthermore, the event report 242 also includes authentication information 256. This authentication information allows for authentication between the communication adapter 32 and the unit receiving the event report 242 (IDS instance 34, backend 36, etc.). The authentication information 256 can be formed, for example, from at least a portion of the data in the event report 242, preferably from all the data in the event report 242 (except, of course, the authentication information 256 to be formed). A corresponding algorithm is stored in the event manager 30 for this purpose. For authentication purposes, the upper-level unit 34 and / or the back-end unit 36 ​​can, in the same manner, decrypt the corresponding data from the received event report 242 to form associated authentication information 256', and compare it with the actually received authentication information 256 (as transmitted in the event report 242). If they match, authenticity is assumed.

[0102] Event report 242 has a fixed length of 258. To achieve this fixed length of 258, data 254, 215_1, 215_8, 215_190, and 256 are also padded with so-called padding data 255. Padding data 255 does not contain information related to the event. For example... Figure 2 As shown in d, the data shown in event report 242 is encrypted 258 before transmission. Event report 242, encrypted in this way by encryption 258, is sent by communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36, as described. Even if the variable 254 changed for each event report 242 differs by only, for example, 1 bit, subsequent encryption 258 results in encrypted event report 242 being significantly different from the previous event report 242 (and not just by one bit).

[0103] Thus, a specific event 220 can be transmitted periodically and encrypted within the scope of event report 242 (using both plain text as part of the constantly changing variable 254 and encryption 258 of event report 242). However, even without a new event 220, so-called virtual events (e.g., consisting of padding data 255) can be transmitted periodically and encrypted. This is used to prevent data exchange between communication adapter 32 and other IDS instances 34 or backend 34 from being eavesdropped on or randomly hidden.

[0104] The following is based on Figures 9-14The communication flow between the event manager 30 and the communication adapter 32 within the control device or gateway 20, the communication flow between the communication adapter 32 and at least one additional IDS instance 34 within the vehicle 18, and the communication flow between the additional IDS instance 34 and the backend 36 are described exemplarily.

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

[0106] Furthermore, communication from another IDS instance 34 to the control device or gateway 20 or associated communication adapter 32 should also feature the following characteristics: The data logger or IDS instance 34 should read event 236 or associated event report 242 as quickly as possible to prevent overflow of memory or buffer memory 206, in particular. Event report 242 should be readable, for example, via a diagnostic interface upon request. Alternatively, event report 242 can be sent periodically in its entirety. Event report 242 should be periodically transmitted or read, preferably in a real and encrypted or hidden manner, even if no new selected event 226 is available in the range of new event reports 242. Control device or gateway 20 should respond to read request 240 encrypted and authenticated with a response or event report 242 of fixed length. Each encrypted response or event report 242 should be different from the previous response or event report 242, even if the content does not change. This is exemplarily achieved through a constantly changing variable 254 as already described.

[0107] according to Figure 9Event manager 30 first selects the first selected event 226.1, and then selects the second selected event 226.2. These selected events are processed by event manager 30 as described. Therefore, the selected events 226.1, 226.2 are stored in memory 206. Communication adapter 32 includes signal 400, namely a time-dependent interrupt signal (Timer IRQ). The time-dependent signal 400 is preferably formed periodically, thereby periodically initiating the transmission of event report 242 from communication adapter 32 to another IDS instance 34 in vehicle 18. However, even in the absence of new events 226.1, 226.2, as described below, the signal (in the form of a “normal” event report 242) is also transmitted from communication adapter 32 to another IDS instance 34 (see signal 406). However, particularly preferably, the transmission of event report 242 is not triggered based on the acquisition of event 220 or the selected event 226, but is triggered periodically (by the elapsed time of the period). This is particularly advantageous because the transmission to other IDS instances 34 and / or backend 36 is always executed periodically, i.e., after a specific time has elapsed. Therefore, the behavior or anomaly detection of Event Manager 30 is opaque to the attacker. The attacker will never know whether their attack has been detected, what has been detected, or how the anomaly detection system is working.

[0108] After the communication adapter 32 receives signal 400 (Timer Interrupt), it requests event report 242, i.e., signal 402, from the event manager 30. The event manager 30 creates the corresponding event report 242, which includes the previously selected events 226.1 and / or 226.2 (with corresponding general metadata 217 and event-related metadata 216) and the changed variables 254. Furthermore, corresponding padding data 255 is added to achieve a fixed length 257 for the event report 242 (knowing the length of the authentication information 256 to be formed). Additionally, the event manager 30 uses a specific algorithm, for example, to generate authentication information 256 from the changed information 254, the selected events 226.1 and 226.2, and the padding data 255. The authentication information 256 formed in this way completes the event report 242. The complete event report 242 is then encrypted using key 258. The encrypted event report 242 arrives at the communication adapter 32 as signal 404. If the corresponding security requirements are met, encryption (using modified information 254 and / or key 258) and authentication (forming authentication information 256) can be performed in the event manager 30 and / or communication adapter 32.

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

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

[0111] After another IDS instance 34 receives a message sent from communication adapter 32 (signal 406), the other IDS instance 34 sends an acknowledgment signal (408) to communication adapter 32. After receiving acknowledgment signal 408, communication adapter 32 generates a request to event manager 30 to delete or rewrite the cached, reduced, selected event 226 or associated event report 242 (signal 410).

[0112] In an alternative embodiment, the upper-level instance 34 and / or the backend 36 checks the authenticity of the received encrypted event report 242. To do this, the upper-level instance 34 and / or the backend 36 decrypts the received message, i.e., the encrypted event report 242, using a known key 258. The event report 242 is then available in plaintext. The event report 242 is authenticated using a corresponding algorithm used to form authentication information 256 (which is also used by the event manager 30 or communication adapter 32 to create authentication information 256). To do this, all data from the received and decrypted event report 242 (except for authentication information 256) is used again to form corresponding authentication information 256'. The formed authentication information 256' is then compared with the authentication information 256 received within the scope of the event report 242. If they match, the received event report 246 is considered authentic. In this variant, further data communication with higher or lower-level instances is only possible after authentication has been performed. In this embodiment, signal 408 (acknowledgment signal) is sent to communication adapter 32 only after successful authentication, and then communication adapter 32 sends signal 410 to event manager 30 to release overriding of selected events 226.1, 226.2.

[0113] Preferably, the response or acknowledgment signals 408, 416 should also have a fixed length of 257'. Preferably, the acknowledgment signal 408 should be authenticated and encrypted. Each response or acknowledgment signal 408 of the parent instance 34 and / or the backend 36 should be different from each other, even if the content does not change.

[0114] Examples of such confirmation signals 408 and 416 can be found in... Figure 9 The acknowledgment signals 408 and 416 have a similar structure to event report 242. Acknowledgment signals 408 and 416 include a modifiable variable 254'. The modifiable variable 254' changes for each newly sent acknowledgment signal 408 or 416. The modifiable variable 254' can again be implemented, for example, through a random number, a counter, or time.

[0115] Particularly preferably, the modifiable variable 254' of the confirmation signals 408, 416 can be formed using the modifiable variable 254 of the just-transmitted event report 242. For this purpose, the parent instances 34, 36 are configured to extract the modifiable variable 254 from the received event report 242 and insert it into the confirmation signals 408, 416. Thus, in subsequent steps, the confirmation signals 408, 416 can also be authenticated by comparing the modifiable variable 254' of the received confirmation signals 408, 416 with the modifiable variable 254 of the previously sent event report 242. If they match, the true confirmation signal 406, 408 is inferred. Furthermore, the modifiable variable 254' does not need to be generated by the parent instances 34, 36 themselves. After this, the memory 206 can be released.

[0116] Furthermore, confirmation signals 408 and 416 include specific data 255', for example, in any template format. Additionally, confirmation signals 408 and 416 include authentication information 256'. Similar to the case of event report 242, the authentication information 256' can again be formed using a specific algorithm that uses the remaining data of confirmation signals 408 and 416, i.e., the variable 254' and data 255'. The authentication information 256' formed in this way completes confirmation signals 408 and 416. This confirmation signal has a fixed length 257'. It is then encrypted using key 258'. Optionally, this encryption 258' can be omitted.

[0117] The receiving instance (e.g., parent instance 34, backend 36) and / or communication adapter 32 or event manager 30 can decrypt confirmation signals 408, 412 (using key 258') and use them for authentication. To this end, a corresponding known algorithm is used to determine the derived authentication information 256'' from the received data (changeable variables 254', data 255'), and compares it with the obtained authentication information 256'. If they match, authenticity is assumed. If the obtained authentication information 256' is correct, a signal 410 for releasing memory 206 can be generated. If the authentication information 256' is incorrect, the signal 410 cannot be generated, and the selected event 226 contained in memory 206 will (still) not be deleted.

[0118] The additional IDS instance 34 also periodically receives a timer interrupt signal 412, which is similar to the signal 400 already described. In response to the interrupt signal 412, the additional IDS instance 34 sends an encrypted message, namely signal 414. This message may, if necessary, contain event report 242 or vehicle-related event reports (including other event reports), as transmitted via signal 406 prior to communication adapter 32. As with communication adapter 32, the message is encrypted by the additional IDS instance 34, specifically by a constantly changing variable 254' such as a random number 273. If communication adapter 32 does not transmit event report 242, for example because no new selected event 226 has occurred, a virtual message with the same data format as event report 242 is again transmitted to backend 36 in encrypted form (signal 414). Backend 36 sends an acknowledgment signal 416 to the additional IDS instance 34 and / or additional notifications or requests such as event 236 cached in buffer memory 206. Acknowledgment signal 416 may be formed as described above.

[0119] After receiving signal 410 regarding event release, event manager 30 selects the other selected events 226.3 and 226.4. Further procedures can be initiated from... Figure 10 The event manager 30 also selects another event 226.5. A timer interrupt (signal 420) re-arrives at the communication adapter 32. The communication adapter now requests event report 242 (signal 422) from the gateway 20. The event manager 30 sends event report 242 based on the selected events 226.3, 226.4, and 226.5 to the communication adapter 32, i.e., signal 424. After receiving event report 242, the communication adapter 32 sends event report 242 encrypted and authenticated by a new, changeable variable 254 (such as a random number) to the other IDS instance 34, i.e., signal 426. The other IDS instance 34 confirms the acquisition via acknowledgment signal 428. Acknowledgment signal 428 can be combined with acknowledgment signal 408 ( Figure 9 As described above. After receiving the acknowledgment 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, and 226.5, on which the event report 242 is based, i.e., signal 430. Simultaneously, another selected event 226.6 is chosen between the transmission of signal 424 and the reception of signal 430. However, this selected event 226.6 cannot be overwritten yet because it is not yet the basis for the event report 242 already transmitted to the communication adapter 32. In this respect, signal 430 does not involve overwriting the selected event 226.6, but only overwriting the selected events 226.3, 226.4, and 226.5 that have already been transmitted within the scope of the last event report 242.

[0120] As already described, a timer interrupt (signal 432) also occurs at the other IDS instance 34. This prompts 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 acknowledges receipt of the corresponding message 434 via the corresponding acknowledgment signal 436, which is then sent to the other IDS instance 34. The acknowledgment signal 436 can be formed in the same way as acknowledgment signals 408 or 416.

[0121] Further procedures are underway. Figure 11 As shown in the diagram. Another timer interrupt occurs again for communication adapter 32, signal 440. Communication adapter 32 then sends a request to event manager 30 to send event report 242, signal 442. Event manager 30 sends event report 242 containing the event 226.6 selected during this period, signal 444. Communication adapter 32 encrypts event report 242 using a new changeable variable 256 and sends the encrypted event report 242 to another IDS instance 34, signal 446. Upon receipt, the other IDS instance 34 sends an acknowledgment, signal 448, and upon receiving signal 448, communication adapter 32 sends a request to event manager 30 to overwrite or release the already transmitted event 226.6, signal 450.

[0122] Another IDS instance 34 receives a timer interrupt again, signal 452. Then, the encrypted event report 242, if necessary, is transmitted to the backend 36 along with other event reports from other IDS systems. The backend 36 sends an acknowledgment signal and / or a request to release or overwrite the corresponding event to (multiple) other IDS instances 34, signal 456.

[0123] According to Figure 12In the exemplary process, no new selected event 226 occurs between the sending of the last event report 242 and the occurrence of a new timer interrupt (signal 460). After receiving the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 to the event manager 30 for the new event report 242. The event manager 30 generates an event report 242 with virtual content—despite the occurrence of the new selected event 226—and then sends this event report to the communication adapter 32, i.e., signal 464. The additional IDS instance 34 and / or backend 36 can recognize the virtual content as virtual content. The communication adapter 32 encrypts the received event report 242 with virtual content using a new, changeable variable 254 and sends the encrypted and authenticated event report 242 to the additional IDS instance 34, i.e., signal 466. This acquisition is confirmed by the additional IDS instance 34, i.e., signal 468. Upon receiving this signal, the communication adapter 32 resends the request signal to the event manager 30 to overwrite the last selected event 226, i.e., signal 470. Even if there are no new selected events in this constellation (226), this will still proceed.

[0124] The additional IDS instance 34 reacquires the timer interrupt, i.e., signal 472. Then, the additional IDS instance 34 encrypts the last acquired encrypted event report 242 sent by communication adapter 32 and, if necessary, sends it vehicle-related to the backend 36 along with other event reports from the other IDS system. The backend 36 sends an acknowledgment signal 476 and / or a request to release the event on which it is based to the additional IDS instance 34.

[0125] exist Figure 13In the communication sequence, communication adapter 32 re-acquires a timer interrupt, i.e., signal 480. This timer interrupt 480 can be a special signal that causes communication adapter 32 to request an event digest from event manager 30 (instead of one of the common event reports 242), i.e., signal 482. Event manager 30 sends the event digest to communication adapter 32, i.e., signal 484. The event digest can contain higher-level information, such as different counter readings 231 for different event types 218, or the occurrence of a new event type, etc. The event digest is also encrypted by communication adapter 32 again via a new, changeable variable 254, such as a random number, and transmitted to another IDS instance 34, i.e., signal 486. Once IDS instance 34 receives the encrypted event digest from communication adapter 32, the other IDS instance 34 forwards the event digest to backend 36, preferably in encrypted form. In this embodiment, no timer interrupt is set to initiate the communication process for the transmission between the other IDS instance 34 and backend 36. However, alternatively, the communication process can be initiated periodically, just like sending a common event report.

[0126] exist Figure 14 In the communication sequence, backend 36 sends a request for an event report to another IDS instance 34, signal 490. The other IDS instance 34, for example, sends an encryption request for the event report to communication adapter 32 via a diagnostic interface, signal 492. This encryption can be performed again using a changeable variable 254', such as a random number, which changes specifically for each encryption. After receiving request 492, communication adapter 32 sends a query for event report 242 to event manager 30, signal 494. After receiving the corresponding query 494, event manager 30 sends event report 242 to communication adapter 32, signal 496. Communication adapter 32 encrypts event report 242, for example, using a new changeable variable 254 such as a random number, and sends the event report to the other IDS instance 34, signal 498. After receiving the encrypted event report 242, the other IDS instance 34 sends event report 242 to backend 36. Backend 36 confirms the acquisition, i.e., signal 492, to another IDS instance 34. The other IDS instance 34 then confirms the acquisition of confirmation signal 492, i.e., signal 494, to communication adapter 32. After acquiring the corresponding signal 494, communication adapter 32 sends a corresponding request to event manager 30 to at least release or overwrite event 220 transmitted within the scope of the last event report 242.

[0127] The described method can be implemented in a computing unit, computer, or controller, particularly in the control equipment of vehicle 18. Similarly, the method can be created within the scope of a computer program configured to execute 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, for example, as software "with a radio," or wired via a diagnostic interface.

Claims

1. A method for handling data anomalies in a motor vehicle, wherein at least one sensor (24, 26, 28) for identifying anomalies acquires data (211), wherein the sensor (24, 26, 28) checks whether the acquired data (211) is abnormal, and generates an event (220, 221) based on the associated data (211) when an anomaly is identified, wherein an event manager (30) generates an event report (242) based on the events (220, 221), characterized in that, The event report (242) includes at least one variable (254) that changes for each event report (242) and is sent periodically, wherein if no new event (220, 221) occurs, the event report (242) is generated based on a virtual event and transmitted periodically and encrypted. When the event report (242) is generated, the events (220, 221) are discarded or stored as selected events by the event manager (30), and the event report (242) is generated by the event manager (30) based on the stored selected events.

2. The method according to claim 1, characterized in that, Use random numbers (273) and / or time and / or counters as variables (254) that change for each event report (242).

3. The method according to any one of claims 1 to 2, characterized in that, The event report (242) is transmitted to a higher-level instance (34) in the motor vehicle (18) and / or to a rear end (36) outside the vehicle (18).

4. The method according to any one of claims 1 to 2, characterized in that, The event manager (30) receives events (220, 221) from multiple sensors (24, 26, 28) and generates the event report (242).

5. The method according to any one of claims 1 to 2, characterized in that, Even if no new events (220) have occurred since the last event report (242) was sent, the event report (242) is transmitted periodically.

6. The method according to any one of claims 1 to 2, characterized in that, In the absence of new events (220), the event report is created based on the virtual message (242).

7. The method according to any one of claims 1 to 2, characterized in that, The event report (242) includes authentication information (256) and / or at least one selected event (226) and / or populated data (255).

8. The method according to claim 7, characterized in that, The authentication information (256) is formed from additional information (254, 226, 255) contained in the event report (242).

9. The method according to any one of claims 1 to 2, characterized in that, The event report (242) always has the same length (257) and / or is encrypted with a key (258).

10. The method according to any one of claims 1 to 2, characterized in that, The event report (242) is periodically and / or encryptedly transmitted from another instance (34) used to identify the intrusion to the backend (36).

11. The method according to any one of claims 1 to 2, characterized in that, After receiving the event report (242), the units (34, 36) that receive the event report (242) obtain the event report (242) as required, send an acknowledgment signal (406, 412) to the unit that sent the event report (242).

12. The method according to any one of claims 1 to 2, characterized in that, The sent event report (242) is decrypted and / or authentication information (256') is formed from the data contained in the event report (242). The authentication information is compared with the authentication information (256) contained in the event report (242), and an acknowledgment signal (408, 416) is sent when the formed authentication information (256') matches the obtained authentication information (256).

13. The method according to any one of claims 1 to 2, characterized in that, The received acknowledgment signal (408, 416) is evaluated to determine whether the variable (254') contained in the acknowledgment signal is consistent with the variable (254) in the previously sent event report (242).

14. The method according to claim 13, characterized in that, After receiving the confirmation signal (408, 416), a signal is obtained for releasing or overwriting the memory (206), which contains at least one selected event (226) as part of the last sent event report (242).

15. The method according to claim 11, characterized in that, The unit that sends the event report (242) is the communication adapter (32).

Images