Patent ID: 12255902

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

In conjunction with aspects of the following embodiments, deviations from a normal behavior, which during actual operation may occur in data211(for example, data of a communication system, or system data) of an in particular networked system, are referred to below as an anomaly. The following are examples of possible causes: defects or completely failed sensors deliver incorrect data or no data at all, components of the system are damaged, the system has been manipulated by external, or also local or physical, attacks (a hacker attack, for example).

The detection of anomalies in data211is implemented with the aid of a so-called intrusion detection system (IDS or IDPS). In the following discussion, IDS refers to a system that monitors data211for anomalies. These may be, for example, data211for the data link in a communications network, via which control unit20, for example a gateway, communicates on different communication channels (for example, via bus systems25or Internet27). However, other data211, for example system data within a control unit (or a host29situated therein or a microcontroller or processor, or within a chip) are also to be checked for anomalies via this IDS system. The detection of anomalies of data211takes place via suitable sensors24,26,28. Sensors24,26,28are adapted to the particular source of data211(in the exemplary embodiment, bus systems25,27or host29).

According toFIG.1, a control unit such as a gateway20is situated in a vehicle18. Control unit or gateway20includes a processor/processors, memory, working memory (for example, as an integral part of a host system29), and interfaces for a communication via a communications network. Gateway20executes, for example, instructions for the data link. The communication results in data211in the form of data packets. Data211, for example system data, also result during operation of host29. In a normal state, setpoint values, for example with regard to the recipient address and destination address, observance of correct program sequence (for host29, for example), time stamp, frequency of occurrence or frequency of data211of certain data packets, are adhered to. Data211of data packets are exchanged in order to fulfill the specific tasks between further control units or components, not shown in greater detail, in vehicle18. Gateway20is used to couple multiple communication systems or interfaces, for example a CAN bus25, an Ethernet connection27, and a data link to host system29, which is an integral part of control unit20or of the 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) may be coupled to one another via gateway20for purposes of data exchange. In general, an intrusion detection system IDS or anomaly detector in a control unit is used to monitor all data211(data211received by the communication system as well as data211generated within control unit20by host29) for corresponding anomalies. In the exemplary embodiment, the IDS functional mechanism is described for gateway20as an example. In general, however, the described functionalities of the anomaly detector or intrusion detection system IDS may be implemented in any arbitrary control unit or arbitrary electronic components. In particular, the use is not limited to a vehicle18. Rather, arbitrary communication components, for example communication modules in the Internet (Internet of things (IOT)) or in networked production systems, may be equipped with the described functionalities.

A communication component such as control unit or gateway20includes at least one anomaly detector22. Data211entering via the interfaces of particular communication systems25,27,29are in each case led via so-called sensors24,26,28for the anomaly detection or intrusion detection, referred to as IDS sensors for short. Appropriate sensors24,26,28are thus situated in gateway20. Such sensors24,26,28are used to detect whether obtained data211represent an anomaly. For this purpose, appropriate filter algorithms or rule sets which are used to detect and classify anomalies are stored in sensors24,26,28. If an anomaly is ascertained by a sensor24,26,28, the corresponding data packet of data211is classified as an event220(of an attempted intrusion). In general, depending on source25,27,29, sensors24,26,28may classify (association of particular event220with certain event types218) and detect different anomalies as events220. Sensors24,26,28compile certain event-dependent metadata216as an associated event220, based on particular event type218(different types of anomalies in data211). In addition, event-dependent metadata216may also contain data or data components of anomalous data211. Event220generated in this way is relayed to an event manager30. Sensors24,26,28are generally designed to relay associated data211of a communication system (bus systems25,27, for example) to the destination address when an anomaly is not present. For a detected anomaly, sensors24,26,28could be designed in such a way that associated data211of a communication system (bus system25,27, for example) are not relayed to the destination address. Alternatively, sensors24,26,28may also be used to reduce events220(reduced event or pre-reduced event221). Due to this reduction, event manager30could be relieved of load, for example by only a small portion of useful data of anomaly-containing data211or data packets being relayed. This is advantageous in particular for large data volumes, such as those occurring with Ethernet connections.

Thus, for example, IDS CAN sensors24are used for anomaly detection for a CAN bus25, IDS Ethernet sensors26are used for an Ethernet system27, and IDS host sensors28are used for a host system29. Depending on the different communication paths and communication protocols, even further IDS sensors may be provided which are capable of detecting and optionally classifying anomalies in the particular sources or anomaly sources.

IDS CAN sensors24detect relevant events220of associated event types218such as invalid CAN IDs, invalid message frequencies, invalid message lengths, or the like. IDS Ethernet sensors26detect events220of associated event types218that are relevant for Ethernet27, such as invalid addresses or MAC addresses, invalid message frequencies, invalid message lengths, or the like. IDS host sensors28detect events220of associated event types218that are relevant for host system29, such as invalid code executions, corruption of programs, stack counters, or the like. Particular event types218are often provided with an event-specific event ID. There are numerous predefined event types218for various data sources with associated unique event IDs.

The following further anomalies may be taken into account as events220for further event types218. For example, these are events220or event types218that are to be associated with the firewall, such as loss of the frame due to a full buffer memory, filter violation (stateless/stateful), limitation of the transfer rate active or inactive, monitoring mode activated or deactivated, context change. Even further anomalies that relate to host system29may be taken into account as events220with associated event types218, for example excessive CPU load, memory access violation, errors in the code execution, ECU reset detected, log entries in the nonvolatile memory corrupted, overflow of the logging memory, rejection of an event, change of MAC address port, etc.

Event manager30is used to further process incoming events220or event-dependent metadata215contained in particular event220. In particular, event manager30is used to aggregate, format, or prepare events220and/or to prioritize and/or reduce/select events220and/or to store or persist or permanently store selected and/or reduced events220,221. In particular, event manager30decides which incoming events220are to be further processed. The events that are selected from incoming events220are referred to as selected events226. The appropriate selection is to take place as nondeterministically as possible. In addition, event manager30particularly preferably provides incoming events220or selected events226with yet further generic metadata217. As a result, events220that are transmitted by different sensors24,26,28may be regarded as higher level, for example by adding the number of occurred events, the associated time stamp or time signal224, or the like within the scope of generic metadata217. Furthermore, it is ensured that even in the event of a so-called event burst, a sufficiently large number of meaningful events220may be stored as selected events226.

Event manager30exchanges signals with a communication adapter32of the intrusion or anomaly detection. Communication adapter32functions as a communication means for the data exchange between event manager30and further components34,36outside anomaly detector22of control unit or gateway20. In particular, communication adapter32is used as an interface for the data exchange between event manager30and further IDS entities34(preferably inside vehicle18) and/or a back end36(preferably outside vehicle18). Further IDS entity34may be only optionally provided.

To increase the security, event manager30could carry out a random reduction and prioritization of events220,221that is nondetermininistic for and concealed from an intruder. Thus, random, nonvolatile storage of selected events226could be carried out in a way that is nondetermininistic for and concealed from the intruder. The random selection could be based, for example, on a random number273that is unique to a certain control unit. Event manager30may likewise carry out a random storage of counter contents231of event counters204. In addition to event-dependent metadata216, event manager30also randomly stores added generic metadata217as selected events226.

To increase the security, communication adapter32could carry out random uploading or sending of an event report242to the other IDS entities34in a way that is nondetermininistic for and concealed from the intruder. The random uploading could be based, for example, on a random number273that is unique to a certain control unit (or gateway20). Certain events220could thus be cyclically transmitted with encryption within the scope of event report242. Even if no new events220are present, so-called dummy events in the format of an event report242could be cyclically transmitted with encryption. This is used to protect against eavesdropping or to randomly conceal the data exchange between communication adapter32and further IDS entities34or back end36.

As an example, in conjunction withFIG.2it is shown how data211are further processed by sensor24,26,28in the event of a detected anomaly and sent to event manager30until the event manager sends an event report242via communication adapter32.

FIG.2ashows by way of example a data packet of data211as may occur, for example, in a network frame (CAN, Ethernet, for example). Data211include a header214that includes, for example, the source address and the destination address (MACa, MACb, for example). In addition, data211include useful data213.

As explained in greater detail below, sensor24,26,28could optionally randomly select a useful data range219, which is relayed to event manager30. Sensor24,26,28has ascertained that this is an anomaly according to a certain event type218(event ID or ID). Therefore, sensor24,26,28generates event-dependent metadata216as illustrated inFIG.2b. Depending on event type218(or ID), different pieces of information concerning the anomaly could be stored for event-dependent metadata216. In the exemplary embodiment, the source address and destination address (MACa, MACb), event type218, and selected useful data range219, among others, are used as event-dependent metadata216.

Alternatively, event-dependent useful data213could also be relayed to event manager30completely within the scope of event220.

Alternatively, event220could also include no event-dependent useful data213, for example when host29is used as the source. This may involve event types218such as information concerning loss of the data frame due to a full buffer, activation or deactivation of the observation mode, excessive load on the CPU, corruption of entries of nonvolatile memory208, overflow of the logging buffer, active event reduction, or the like.

In addition, for different event types218, further event-dependent information within the scope of event-dependent metadata216may be an integral part of event220. For event type218“change of context,” event-dependent metadata216could include, for example, the context, for example with a size of 32 bits. For event type218“memory access violation” or “code execution violation,” event-dependent metadata216could include, for example, the accessed address (32 bits, for example), the program counter (32 bits, for example), the task ID (8 bits, for example). For event type218“detected reset of a control unit,” event-dependent metadata216could include, for example, the reason for the reset (8 bits, for example), for example point of return (POR), software reset, exceptions, etc.

Subsequent Ethernet-based events220could be logged as event-dependent metadata216, such as static/state-dependent filter violations (certain rule ID or ID for certain event type218(16 bits, for example), an ID of the filter rule that caused event220, if available, physical port address, physical port ID via which the frame was obtained, source address (MAC address, for example, 48 bits, for example), destination address (MAC address, for example, 48 bits, for example), possibly the IP address of the source or destination, determination of the UDP/TCP port (16 bits, for example) if present in the frame (optional)). Alternatively, static/state-dependent filter violations could be concurrently logged, for example rule ID, physical port, frame (number of bytes) in which a certain number of bytes of the received frame are stored, selected useful data range219(certain number of bytes), selected useful data range219of the bytes of the original frame, useful data range219index (16 bits, for example), start byte of selected useful data range219in the original frame. Even further Ethernet-based events could be contained in events220that are transmitted to event manager30, for example for event type218“transfer rate limited (active/inactive),” the rule ID with associated ID of the filter rule that has caused event220, for event type218“change of context,” the context (32 bits, for example), for event type218“address hopping” or “MAC hopping,” the old port (physical port ID that was originally associated with the address), the new port (physical port ID where the address has been recently observed), the address, preferably the MAC address. However, event types218without metadata216, for example “loss of frame due to full buffer,” etc., may also occur.

The relaying of event-dependent useful data213is thus in particular a function of the source of data211having associated event type218. Metadata216are transferred to event manager30as event220or reduced event221(due to the random selection or reduction of useful data range219to be transferred in sensor24,26,28).

If event manager30selects this event220,221(selected event226) for further processing as explained in greater detail below, generic metadata217are also added to event-dependent metadata216, resulting in metadata215shown inFIG.2c.These generic metadata217are generally generated in event manager30. These are, for example, output signals of event counters204, i.e., present counter contents231, concerning which number of global event220or which number of event of a certain event type218that is involved for present event220. In addition, generic metadata217may include a time signal224, for example, indicating when this event220occurred. Furthermore, metadata217could include the particular length232(size of the data) of event-dependent metadata216or of complete metadata215. This is advantageous for the subsequent memory management of buffer memory206.

The following generic metadata217are proposed as an example. This could be, for example, an event type218within the scope of an event ID (8 bits, for example). This event ID of event type218is unique, and may include type-length-value (TLV)-based encoding, for example. Generic metadata217include length232, for example between 8 and 16 bits in size. The size of the data (metadata215) follows the length field in bytes, with a maximum of 255 bytes. TLV-based encoding could once again be provided. Time signal224, a time stamp (64 bits, for example), is also included. Time224is indicated, for example, in the form of an absolute time value that has elapsed since a reference point in time, such as Jan. 1, 1970 (in milliseconds) for indicating a unique time stamp. In addition, generic metadata217may include counter contents231or starting values231of event type counter204(32 bits, for example) and/or counter content231of global (event) counter204(32 bits, for example), a sum of all counter contents231of event counters204for each event type218.

Event-dependent metadata216are accepted as particular sensor24,26,28has formed them. This event220together with corresponding metadata215formed by sensor24,26,28and by event manager30is stored in buffer memory206of event manager30. As explained in greater detail below, even further events226selected or reduced by event manager30(in the exemplary embodiment according toFIG.2d, referred to as215_1,215_8,215_190as an example) are similarly stored in buffer memory206.

An event report242is now generated from selected events226(in the exemplary embodiment according toFIG.2d, referred to as215_1,215_8,215_190as an example (metadata215event number 1, metadata215event number 8, metadata215event number190as examples of selected events226)) stored in buffer memory206. This event report includes selected events226(in the example,215_1,215_8,215_190) that are stored in buffer memory206. These selected events226are preceded by a variable254(for example, a random number, time, or counter, etc.) that is changed with regard to each event report242. In addition, event report242includes a piece of authentication information256, via which the authentication between communication adapter32or event manager30and the unit (IDS entity34, back end36, or the like) that receives event report242may take place. Event report242has a fixed length258. To achieve this fixed length258, data254,215_1,215_8,215_190,256are additionally filled by so-called padding data255. These padding data255contain no event-relevant information. Prior to a transfer, the shown data of event report242are provided with encryption258as indicated inFIG.2d. Event report242that is encrypted in this way by encryption258is sent from communication adapter32, and is decrypted and authenticated by further IDS entity34or back end36, as described.

IDS sensors24,26,28relay events220or reduced events221to event manager30. In particular for Ethernet networks, in the event of an intrusion attempt, for a plurality of events220to be relayed having large data volumes or event-dependent metadata216, a memory206, in particular a volatile memory or buffer memory206, very quickly can no longer accept all events220. This is due to the high data transfer rate or high data volumes that may be transferred. Therefore, it may make sense for one or multiple IDS sensors24,26,28to already carry out a preselection of events220to be relayed and/or a data reduction (reduced events221) according to certain criteria. These criteria should be characterized by low predictability.

For IDS sensors24,26,28, in particular for IDS Ethernet sensors26, for increasing the security, the selection of certain events220to be relayed and/or the reduction of the events to reduced events221preferably takes place randomly. A random or arbitrary selection or a reduction of certain events220or data blocks of an Ethernet frames takes place in a way that is nondeterministic for and concealed from an intruder. The random selection or reduction could be based, for example, on a random number273that is unique to a certain control unit. In the simplest case, the same random number273could also be used for the other random scenarios as a reference in event manager30for reducing or prioritizing all events220, the random storing of events220, or the like. Alternatively, appropriate random numbers could also be regenerated anew in the control unit.

Incoming messages or data211typically include appropriate pieces of header information214(certain address data, for example), followed by useful data213. Many pieces of header information which are not absolutely necessary for the anomaly evaluation are usually contained. According to the present invention, only certain address portions that are absolutely necessary are relayed as an integral part of a reduced event221within the scope of event-dependent metadata216, for example the address of the source (MAC address, for example, 48 bits, for example), the address of the destination (MAC address, for example, 48 bits, for example), and the ID number that has resulted in an anomaly (event type218). Other pieces of information, such as possibly the physical port or port ID where the frame was received, the IP address of the source or destination, information about the UDP/TCP port of the source or of the destination, if such information is contained in the frame, do not have to be transmitted, or completely transmitted, in event220.

However, useful data range219that is selected or to be relayed is randomly selected from useful data213of incoming data211, as also already explained in conjunction withFIGS.2aand2b. Thus, for example, the number of the start date (beginning of the memory area of the useful data to be transferred, for example byte number xyz) could be randomly established (for example, transferring a data range whose initial value was randomly ascertained, for example useful data byte number538for this event220). The offset of selected useful data range219(number of transmitted data, for example 10 bytes) could be chosen to be fixed. Thus, the useful data bytes having numbers538through547, in addition to the minimum address information (source address, destination address), would be relayed to event manager30as selected useful data range219within the scope of event221thus reduced. Alternatively, the offset of selected useful data range219(number of transmitted useful data) could also be varied, preferably randomly. Selected useful data range219, in particular the starting range or end range of selected useful data range219, is preferably based on a random number273. This random number273is particularly preferably a function of control unit or gateway20. Random number273is particularly preferably unique, i.e., assigned once only for this particular control unit.

However, random number273may optionally also be renewed. This results in the following advantages. By replacing the random number, for the same intrusion sequence (sequence of events220) different events220are logged or selected. This is also the case when the intrusion takes place only on a single control unit/vehicle18and not on the entire fleet, as shown in the following assumption/example:1. Multiple repetitions of the same intrusion sequence (sequence of events220)2. Random numbers273are renewed between intrusion sequences3. Within the scope of an intrusion sequence, not all events220can be logged or selected (event burst). An event reduction for event report242follows4. An event report242containing reduced events221is completely relayed to higher-order entity34,36between two intrusion sequences. After multiple repetitions of the same intrusion sequence, the complete intrusion sequence may thus be reconstructed via event reports242.

Sensor26could preferably adapt the selection of random number273or the various ranges of random number273to the size of incoming data211, in particular to the size of incoming useful data213. If useful data213have a smaller data range, random number273must be selected in such a way that the selection of a certain reduced useful data range219also falls only into this small data range of useful data213. Random number273or the range of random number273under consideration must thus be correspondingly small. However, if incoming useful data213have a very large data range, random number273or the range of random number273under consideration must be selected to be large enough that the selection of a certain reduced useful data range219may also cover this large data range of useful data213. Random number273is thus correspondingly larger.

Due to the fact that random number273has been uniquely assigned to a particular control unit20, if further control units are present, the complete message (which has also gone to the further control units and has likewise been relayed with appropriate detection and reduction, using appropriately equipped sensors26at that location) could possibly be combined with the complete data range during an analysis in back end36by compiling a large number of reduced events221of multiple control units. This is because other control units with the same sensor function as described also now randomly select other useful data ranges219(including other randomly selected start addresses or end addresses), which after the compiling of multiple reduced events221may cover a large portion of (useful) data range213or the complete data range of useful data213, based on the subranges or selected useful data ranges219of the various control units. Thus, various control units could reconstruct an event220from reduced events221or selected useful data range219, for example by partial data range538through547(of the one selected useful data range219) being provided by the one control unit, partial data range548through557(of a further selected useful data range219) being provided by a further control unit, partial data range558through567(of a further selected useful data range219) being provided by a further control unit, and particular selected useful data ranges219being combined once again, for example in a higher-order control unit or in back end36, to form complete (useful) data range213. This is the case in particular for a so-called broadcast attack on the entire vehicle fleet or a so-called multicast attack on portions of the vehicle fleet.

The random ascertainment of the start and/or the end of relayed or selected useful data range219is preferably carried out anew after certain events (cyclically, start-up of the control unit, reset of a control unit, etc.). For this purpose, for example random number273could be generated anew. Alternatively, some other range of random number273could be used for generating the start and/or end of the data range or of selected useful data range219to be relayed.

Processed reduced events221are relayed from sensor26to event manager30. Thus, event manager30does not obtain complete data streams of these net frames from this sensor26, but, rather, obtains only reduced events221with reduced data size. The reduction of events221to be relayed has been described by way of example, based on an IDS Ethernet sensor26. However, in principle this could also be implemented in other IDS sensors24,26,28. However, due to the high information content in an Ethernet frame with high transfer rates, specifically such events220would quickly result in an overflow of buffer memory206. For IDS CAN sensors24, data211in question occur with a low data rate and a low data volume anyway, so that generally speaking, complete events220may be passed on and stored here. However, in principle the data could also be reduced there, as correspondingly described.

In principle, the following steps for reducing events220thus take place in sensor24,26,28. Data211are received from sensor24,26,28and/or data211are evaluated as to whether an anomaly is present. Data211are reduced when an anomaly is present. The reduction takes place by reducing the address range or header214and/or the data range or useful data213. The reduction of address range214could take place by selecting the destination address and/or the source address. The reduction of useful data213takes place randomly. The reduction of useful data213takes place randomly by random selection of a start value and/or an end value of a subrange of useful data213. The offset of the data range (number of transmitted data) is fixed at a certain value. Reduced events221are transmitted to event manager30. Reduced events221contain reduced address data and/or reduced or selected useful data219. Updating of random number273takes place as a function of certain system states (cyclical, start-up, reset, etc.). Alternatively, an update of random number273could take place randomly and/or in a time-controlled manner. Random number273or ranges of random number273for determining the start range or end range of selected useful data range219may be a function of the size of useful range213of received data211.

The configuration of event manager30is shown in greater detail according toFIG.3. Event manager30includes multiple functional blocks that are in interaction with one another. Each of events220or reduced events221detected by sensors24,26,28arrives at a block202. Block202is used to select incoming events220or reduced events221that are to be further processed. In particular, block202is used to prioritize and reduce events220,221.

Each event220or each reduced event221likewise arrives at a block204that is used as a counter204for events220,221. For an occurred event220,221, a corresponding counter, in particular a global event counter205, is incremented. Counter204particularly preferably includes different counters Z1, Z2, . . . Zn for different event types218(ID1, ID2, . . . IDn), as explained in greater detail above in conjunction with corresponding sensors24,26,28. Global event counter205in turn represents the sum of all counter contents of counters Z1, Z2, . . . Zn for different event types218(ID1, ID2, . . . IDn). Output signal231of block204or counter contains the counter contents of all events220,221, i.e., counter contents of particular event-dependent counters Z1, Z2, . . . Zn and of global event counter205. Corresponding output signal231from block204is supplied to a block210for communicating events220. Block204is configured to receive a reset signal222, which represents a reset request to the counter or to event counters204,205. Block204obtains from block202a signal for a reduction status225, for example “event reduction active.” In block202, an event reduction is active, for example, when only a reduced number of certain events220,221are further processed as selected events226. This is the case in particular when, for example, within the scope of a so-called event burst, a large number of events220,221arrive with an increased fill state228of buffer memory206. In this case, an additional event220is to be generated, for example with an event type218“event reduction active” as described above. For this event220′ with associated event type218, there is then likewise a corresponding counter or counter content.

The events processed by block202arrive as selected events226at a block206, which is used as a memory or buffer memory for selected events226that are supplied from block202, and which includes the appropriate logic for this purpose. In turn, memory206reports the fill state or memory allocation228back to block202. Memory206is preferably a volatile memory, in particular a buffer memory of a RAM. In addition, time signal224, in particular a global time signal224, arrives at memory206or at the block for buffering selected events226. Memory206is an integral part of event manager30.

Certain events236stored or buffered in memory206arrive at a block210that is used to communicate event reports242as a function of selected events226or stored events236. Block210for communicating events also obtains output signals231of event counter204, for example counter contents of counters Z1, Z2 . . . Zn for particular event types218and/or the counter content of global event counter205. Block210for communicating events, in particular event reports242, exchanges signals244with a cryptography module212. The cryptography module carries out cryptography operations such as encryption operations, authentication operations, as well as random number generation, etc. An encrypted communication of block210to the outside may take place with the aid of cryptography module212. Cryptography module212carries out in particular an encryption of event report242, using encryption257indicated inFIG.2d. Cryptography module212may likewise carry out an authentication of event report242using authentication information256(also cf.FIG.2d). Block210may reside in communication adapter32and/or in event manager30. Block210outputs appropriate event reports242. Block210receives a request command240to read out corresponding events236stored in memory206,208. Request command240may take place cyclically and/or in response to an explicit request. In addition, block210sends a signal239(event enablement) to memory206. After a successful transfer of associated event reports242, which also contain stored events236or selected events226, memory206or208is thus generally notified that stored and further communicated events236,226are allowed to be overwritten or deleted.

In addition, a further memory208, in particular a nonvolatile memory, is provided in event manager30. Certain events234that have been buffered in buffer memory206and/or counter contents of event counter204are permanently stored in further memory208, which in particular is nonvolatile. For this purpose, memory208exchanges data with event counter204and/or with buffer memory206.

The mode of operation of block202for prioritizing and reducing events220is described in greater detail below with reference toFIG.4. The mechanism described below is used to select whether supplemental helpful (and memory-intensive) metadata215are to be stored for an event220,221. In a further generalization, block202is used to select, from events220,221supplied to event manager30, the events that are to be further processed as selected events226. For each event type218of obtained event220,221, it is tracked whether this is the first occurrence of this certain event type218, or whether an event220with this event type218has already been sent to memory or buffer206(query301). For the first occurrence of an event type218, block304follows, in which particular event220, as selected event226, is transferred to buffer206and stored there. Otherwise, block302follows. In this step302, it is decided according to a certain criterion whether event220,221, which has already occurred with regard to event type218, is nevertheless to be stored. This takes place, for example, after a random selection of event220,221, in particular based on a random number273. This random selection could particularly preferably be based on a control unit-specific or vehicle-specific random number273. An intelligent algorithm is to be used for the random selection in order to limit overflow of buffer memory206in worst case intrusion scenarios (prolonged intrusion with so-called event bursts). On the other hand, a reasonable number of stored events236or selected events226or log entries should be obtained in normal scenarios in order to capture the largest possible spectrum over the complete intrusion. For this purpose, event220selected in step302is transmitted to memory206in step303as selected event226for storing.

If the event has thus now been selected according to random criteria according to step302(query303), this event220,221, as selected event226, is also sent to memory206(step304). Otherwise, the program sequence ends without storing this event220,221in memory206or without supplemental storage of further metadata215concerning event220. The monitoring of the first occurrence of event type218is reset when memory206is read out and communication has taken place via block210. If an event220,221has not been selected or discarded, the state “event rejected” is triggered for each discarded event220,221. For this purpose, a further counter204that records the number of unselected events220is particularly preferably to be provided.

For an additional prioritization, events220,221could optionally be grouped as a function of particular event type218, and a dedicated entity for the random event reduction could be provided for each event type218. A prioritization may additionally be achieved by group formation. This means that event types218are assigned to different priority groups. Certain event types218(for example, event types218with ID numbers ID1, ID6, ID14, ID23, etc.) are assigned to the priority group having highest priority (Prio 1), associated further event types218(for example, event types218with ID numbers ID2, ID5, ID12, ID27, etc.) are assigned to a priority group having the next lower priority (Prio 2), associated further event types218(for example, event types218with ID numbers ID3, ID9, ID13, ID19, etc.) are assigned to a priority group having a next lower priority (Prio 3), etc. For different priority groups (Prio1, Prio2, Prio3, . . . ), on average different numbers of events220are randomly selected as selected events226(N1: number of selected events for priority group 1 (Prio1), Nx: number of selected events for priority group x (Prio_x)). For priority groups having high priority, on average more events220are randomly selected than for priority groups having low priority (N1>N2 . . . ). This could be achieved, for example, by selecting ranges B1, B2 . . . Bx (with associated priority groups Prio1, Prio2 . . . Prio_x) or the number from which an event220is selected to be smaller the higher the priority is (B1<B2 . . . ).

Selected events226are stored in volatile memory206. However, selected events226are not to be directly stored in nonvolatile memory208, since too frequent storage could damage nonvolatile memory208. Storing selected events226in nonvolatile memory208could take place randomly, for example as explained in greater detail in conjunction withFIG.6.

Memory or memories206,208may deal with selected events226having different sizes. Memory206is shown here by way of example inFIG.7. Memory206includes a free memory area250and a filled memory area252. Multiple selected events226or226are stored in filled memory area252. Entries226may each have different sizes. Optimal use of the memory space is made by the nonrigid division of memory areas. If memory206is full, new selected events226are discarded. However, in principle, as discussed below, complete filling of memory206is prevented by a self-regulating mechanism. Thus, for a very high fill state228of memory206, on average many fewer events220are randomly selected than for a low fill state228of memory206. However, if selected events226are discarded due to a full buffer206, then an event counter for a new event type218“logging buffer overflow (overflow of memory206)” is implemented to ascertain the number of discarded events or entries. As shown inFIG.3, this may take place, for example, by status230of memory206being communicated to counter204, or by this signal230always sending a pulse to counter204when once again a further selected event226cannot be stored due to a full memory206.

As soon as all stored events236or selected events226have been successfully reported to an external data logger in the control unit, for example, via block210within the scope of an event report242, buffer206is enabled to overwrite or delete events226in question (signal239(free event)). The writing of events236in particular into a nonvolatile memory208such as a flash memory could advantageously be mapped via a non-AUTOSAR memory mechanism in order to ensure memory efficiency and meet performance requirements. However, there is also the option to utilize a standard AUTOSAR memory mechanism.

Event counter204is described in greater detail in conjunction withFIG.5. A dedicated counter Z1, Z2 . . . Zn within the scope of event counter204is implemented for each event type218. Event counter204in each case starts with the value zero. It is initially ascertained whether the counter content is still smaller than a maximum value (query260). If this is the case, upon occurrence of an event220,221of a certain event type218, counter Z1, Z2 . . . Zn increments for particular event type218(step262). Otherwise, the counter content is held at the maximum value, and thus no overflow occurs. It is possible to reset event counter204to zero on request. Counter204could be implemented as a 32-bit counter, for example.

According toFIG.6, the nonvolatile storage of event counter204and/or of certain selected events226in nonvolatile memory208is described. The data are to be stored in nonvolatile memory208at regular time intervals. Such time intervals are, for example, in the range of seconds, minutes, to hours; for example, a storage of the data takes place every 30 minutes. The point in time for the storage is to be randomly selected in order to make the writing procedure unforeseeable by an intruder. The memory cycles could take place randomly, for example within a certain interval (for example, within 30 minutes etc., but the exact point in time of the storage within the 30-minute interval, for example, is random). In turn, the random variable (for determining the point in time of the storage) could be generated or selected as a function of a random number273that is unique to the control unit or to the vehicle.

Alternatively, storage moments could be randomly selected in a time-controlled manner by multiplying a random number by a base time interval. Thus, for example, this involves a certain base time interval of 15 seconds, which is multiplied, for example, by a 3-bit random number or random number range of a random number273. Random number273itself could be cyclically and/or randomly updated. Alternatively, random number273could be assigned individually on a control unit- or vehicle-specific basis, for example during the production and manufacturing. Alternatively, a certain range of random number273could be selected, on the basis of which the factor is formed as a function of the range of random number273.

As soon as a new selected event226occurs and storage in nonvolatile memory208is possible, selected events226are stored in a nonvolatile manner. In addition, storage of selected events226(in memory206) and/or further information such as counter content232of event counter204are/is initiated in nonvolatile memory208when a state change (which could also have been caused by an intruder) of the control unit concerning a loss of the present RAM content (and thus the loss of buffer memory206), for example due to a requested reset or rest mode, is pending.

The data are to be stored in a redundant manner in order to make reconstruction possible, even if a portion of the data was corrupt. The authenticity and integrity of the stored data are to be checked or ensured after reading out from nonvolatile memory208. Nonvolatile memory208is preferably situated in a trusted zone. It is assumed that the IC-internal memory is classified as trusted. A standard AUTOSAR nonvolatile memory (NVM) handler could be used for this purpose.

FIG.5shows an example of a state graph for storing selected events226in nonvolatile memory208. The storage of data in nonvolatile memory208is possible in principle in a state264when this state264is reached. Storage in nonvolatile memory208is not possible in a state266. A change from state264into state266takes place after the storage has taken place. A change back into state264, in which storage is possible, takes place in a time-controlled manner. The time is preferably random, as described above. The system remains in state266(no storage) when the control unit does not prepare for a rest state or reset.

FIG.7shows a more detailed illustration of the components of event manager30. Multiple events226are stored in buffer memory or memory206and form filled memory area252. As an example, an event number 2 (226.2), an event number 4 (226.4), an event number 8 (226.8), an event number 13 (226.13), an event number 25 (226.25), an event number 38 (226.38), an event number 77 (226.77), and an event number 97 (226.97) have been stored as selected events226in buffer memory206. These selected events226have been selected, as described below, from a series of occurring events220(numbers 0 to 200, for example) according to a certain procedure and stored as selected events226in buffer memory206.

The unfilled area or the remaining area of buffer memory206forms free memory area250.

In the exemplary embodiment, corresponding fill state228of the shown memory allocation is formed by most recently stored selected event226.97. The memory area of buffer memory206is now divided into multiple ranges267or fill state areas267between 0% and 100%. In the exemplary embodiment, these are, for example, ten (fill state) areas267.1through267.10. In the exemplary embodiment, ranges267are always selected to be the same size, and in the exemplary embodiment these are 10% intervals. In the exemplary embodiment, memory206at that moment includes present area267.4, i.e., fourth area267.4, which is situated between 30% and 40% of the complete memory allocation.

Present memory area267.4, in which present fill state228of memory206is present, is ascertained in functional block268. Present fill state area267, which in the exemplary embodiment is267.4for the fourth area, arrives at a block270.

Offset271for the next event is ascertained in block270. Offset271indicates from how many events220the next event226to be stored in memory206is to be selected. This number (offset271) of events220from which the next event226to be stored is to be selected, in particular randomly, is a function of particular fill state228or associated memory area267. For a low fill state228or memory area267(fill state228of memory206is relatively low), events20are stored more quickly; i.e., offset271is relatively small. With increasing fill state228or memory area267, offset271increases; i.e., fewer events220are stored or only one event220is selected from a fairly large number (offset271). An overflow of memory206may thus be delayed or prevented in a targeted manner. The random selection of next event226to be stored takes place within an offset271. Only one event220(within offset271) is always randomly selected or stored for each offset271. Thus, on average, more or fewer events220are randomly selected or stored by varying the offset size as a function of fill state228of memory206. Thus, as long as fill state228of memory206is within a certain range227, event manager30always selects an event226to be selected from the same associated offset271until fill state228reaches next range227with a changed, generally increased, offset271.

If memory area267, defined by a lower or upper limiting value, is departed from, next offset271for the new range may be increased or decreased, for example by a certain factor or divisor.

As an example, a corresponding scenario is shown in the table according toFIG.8, which results in an allocation of memory206as shown inFIG.7. Offset271could be selected for different fill states228or memory areas267by way of example, as stated below. Thus, for example, for the memory area between 0 and 10% (267.1), offset271could be assigned to two (from zero to two, the selection thus taking place from three events220), for the memory area between 10% and 20% (267.2), offset271could be assigned to 8 (from zero to eight, the selection thus taking place from nine events220), for the memory area between 20% and 30% (267.3), offset271could be assigned to 32 (from zero to 32, the selection thus taking place from 33 events220), and for the memory area between 30% and 40%, offset271could be assigned to 128 (from zero to 128, the selection thus taking place from 129 events220), etc. A corresponding increase of the offset271for next memory area267could be made, for example, using an appropriate factor (4) or the like. Memory areas267as well as offset values271may be freely configured, and thus adapted to the particular desired situation, for example memory size, etc.

In subsequent block272inFIG.7, next event220to be randomly stored (as a function of random number273as illustrated inFIG.7as an example) is now to be selected as a function of fill state228or memory area267. It must be ensured that offset271, i.e., the number of events220or the range of next events220to be considered, from which particular event220to be randomly stored is to be selected, may be covered by random number273or a corresponding range of random number273. The size of the range of random number273to be considered is selected as a function of particular offset271. If random number273is, for example, bit-encoded as illustrated inFIG.7as an example, for example for an offset271of two (0-2), initially a preliminary range of random number273_temp preliminary having a size of two bits is selected. For an offset271of 8 (0-8), a range x of random number273.x_vhaving a size of 4 bits is selected. For an offset271of 32 (0-32), a preliminary range of random number273_vhaving a size of 6 bits is selected. For an offset271of 128 (0-128), a preliminary range of random number273_vhaving a size of 8 bits is selected. The preliminary range of random number273_vis shown in column 4, indicated there by way of example for specific random number273fromFIG.7. A check is subsequently made as to whether the section of random number273contained in preliminary range273_temp is less than or equal to offset271for next memory area276. If this is the case, preliminary range273_vis also actually used as a section of random number273.xas a random number range. The corresponding query in column 5 may be answered by “TRUE.” For these cases, the temporary section of random number273.x_vmatches the selected section of random number273.x. If this is not the case (query in column 5 is answered by “FALSE”), the preliminary section of random number273.x_vis reduced in size. This may take place by omitting one bit, preferably the most significant bit (MSB). For the value of the random number in this range273.xthat then results, it may now be ensured that this value is within offset271for next memory area267.

Thus, for example, for an offset271of 8 (0-8), initially 4 bits of random number273are considered in order to also cover the number 8 itself (size of present offset271) (cf. columns with numerical buffer entries of 3, 4, 5 inFIG.8). If the 4-bit value of associated preliminary random number range273.5_v<=offset271−event number 25,273.5, for example =0b0111=7, this 4-bit number is directly used. The associated query is shown in column 5 inFIG.8. Since the condition is met, the result is “TRUE.”

If the 4-bit value of associated preliminary random number range273.4_v>offset271−event number 13,273.4, for example =0b1100=12, this 4-bit number is not directly used, and instead the most significant bit (MSB) for the range of random number273.4under consideration is truncated, and the resulting 3-bit number 0b100=4 is used. The truncated MSB does not have to be discarded, and instead is entered as the least significant bit (LSB) of the next range of random number273.5_vto be considered. In this case, the associated condition (is the corresponding random number range273.3<=offset271?) is not met (the associated result in column 5 is “FALSE”). By use of this procedure, it may be ensured that random number273is completely used and is not expended too quickly.

For ascertaining the size of random number range273.x(for example, the number of required bits for the range of random number273), it must be ensured that the size (for example, the number of required bits) is sufficient for representing the size of offset271of associated memory area267of next event220.

Thus, in the exemplary embodiment according toFIG.8, according to row 1, for offset271of 2 (0-2) for selected random number273.1of 2, event number 2 (220.2, global event counter285is 2) is selected (after discarding events220.0,220.1number 0 and number 1) as selected event226.2. According to row 2, for next offset range271(still for 0-2), event number 1 is randomly selected based on this offset range271. Event number 0 in this offset range271has been discarded (corresponding to global counter content285of 3), but event number 1 in this offset range271has been selected (corresponding to global counter content285of 4, resulting in selected event226.4). Next offset range271according to row 3 is still 2 (0-2), since fill state267of buffer206is still in range267.1between 0% and 10%. The random number for273.3is 2, so that after event numbers 0 and 1 are discarded in this offset range271, event number 2 is selected (global counter content285is 8, selected event226.8). Since fill state267is subsequently present in next fill state area267.2, new offset271now changes to 8 (0-8). As described above, the next 4 bits of preliminary random number range273.4_vare now considered. Since the associated random number of preliminary random number range273.4_v, which is 12, is greater than present offset271(query 12<=8 in column 5 results in “FALSE”), the most significant bit of preliminary random number range273.4_vis not used, and instead only the least significant 3 bits are used within the scope of selected random number range273.4(binary100, i.e., 4). For this new offset range271of 8 (0-8), event number 0 (global counter content285is 9) to event number 3 are thus discarded, and event number 4 (global counter content285is thus 13) is selected as selected event226.13. As an example,FIG.8summarizes the corresponding values for further fill states267.

Thus, in block272it has not been randomly ascertained which event220is selected next as selected event226. Corresponding block280now monitors the occurrence of new events220(block284). It has been previously established, for example, that after stored event226.8(8th event), event226.13(13th event) is the next to be stored. Block280thus waits for event number 13, discards the next event numbers 9 through 12, and stores only event number 13 as selected event226.13in memory206. New fill state228of memory206is ascertained as a function of new selected event226together with a data size of metadata215(event-dependent metadata216and generic metadata217). This could take place in a particularly simple manner, for example, using length232as already contained in metadata215.

Random number273is to be selected differently for different control units or vehicles18. Thus, in production, for example, random number273could be assigned once for each individual vehicle or control unit. Alternatively, random number273itself could be newly generated internally according to certain rules. The new generation could take place, for example, during transitions from system states (during bootup, reset, transfer into a sleep mode, etc.) and/or cyclically according to certain time periods.

Based on the information in question, block272ascertains next event hit278(next event hit278in next offset271). Next event hit278arrives at a block280(“throw the dice”) in which on a random basis, supplied event220is either discarded (event220is not stored in buffer memory206) or selected as selected event226for storage in buffer memory206. If the selection takes place (event hit282), block284follows. Block284is called up for each event220. However, block284itself calls up (for each event220) block280, which provides feedback to block284as to whether or not event220is to be selected. If event220has been selected by block280, then block284triggers the storage of event220as selected event226in memory206.

The reading in of selected event220takes place in block284(“on event”) for subsequent storage in free area250of buffer memory206as selected event226. Block284is always called up for every new incoming event220,221. Block284is used for random selection, including possible reduction and prioritization of incoming events220,221.

In addition to the random selection in block280, a random reduction of event220may also take place, for example as described above by use of ETH sensors26. A certain data range (start of a preferably fixed data range, or end of a data range) may thus be randomly selected. Likewise, only certain reduced address data could be stored.

Likewise, for a high rate of occurrence of events220or in general, sensor24,26,28itself (for a certain source, for example Ethernet) could select or reduce events220, a prefiltering in a manner of speaking, analogously to event manager30in order to relieve load on event manager30(into which events220of other sources are also entered). If sensor24,26,28is not already relaying individual events220to event manager30, this is likewise to be communicated as an individual event type218to event manager30(analogously to reduction status225in event manager30). In general, however, the event-dependent selection of events220could take place in sensor24,26,28itself and be stored in a buffer memory of sensor24,26,28. Appropriate counters may likewise also be provided in sensor24,26,28for particular event types218, which could be transmitted to event manager30as needed. In addition, upon request by event manager30, events226′ selected by sensor24,26,28could be communicated to the event manager for possible relaying to higher-order entity34and/or to back end36. The procedures for random selection and/or prioritization, described in conjunction with event manager30, may still take place in sensor24,26,28. Nevertheless, they may be limited solely to specific data211for the particular source; i.e., sensor24,26,28may thus select only sensor-specific events220.

For increasing the security, communication adapter32could provide random sending, which is nondetermininistic for and concealed from an intruder, of an event report242to other IDS entities34.

As described above in conjunction withFIG.2d, an event report242is generated from selected events226that are stored in buffer memory206. This event report includes selected events226that are stored in buffer memory206. These selected events226are preceded by a variable254(for example, a random number, time, or counter, etc.) that is changed with respect to each event report242. In addition, event report242includes a piece of authentication information256via which the authentication between communication adapter32and the unit that receives event report242(IDS entity34, back end36, or the like) may take place. Authentication information256could be formed, for example, from at least a portion of the data of event report242, preferably from all data of event report242(of course, with the exception of authentication information256to be formed). For this purpose, an appropriate algorithm is stored in event manager30. For purposes of authentication, a higher-order unit34and/or back end36may be similarly formed from the corresponding data of received event report242after decryption of associated authentication information256′, and compared to actually received authentication information256as in event report242. Authenticity is assumed when there is a match.

Event report242has a fixed length258. To achieve this fixed length258, data254,215_1,215_8,215_190,256are further filled by so-called padding data255. These padding data255contain no event-relevant information. Prior to a transfer, the shown data of event report242are provided with encryption258, as indicated inFIG.2d. Event report242which is thus encrypted by encryption258is sent by communication adapter32, and is decrypted and authenticated by further IDS entity34or back end36as described. Even if variable254, which changes for each event report242, differs by only 1 bit, for example, subsequent encryption258results in encrypted event report242differing greatly (and not just in one bit) from preceding event report242.

Certain events220could thus be transferred cyclically and with encryption (with a continually changing variable254as part of event report242in plaintext, and with encryption258of event report242) within the scope of event report242. However, even if no new events220are present, so-called dummy events (made up of padding data255, for example) could be transferred cyclically and with encryption. This is used to protect against eavesdropping or to randomly conceal the data exchange between communication adapter32and further IDS entities34or back end36.

The communication sequences between event manager30and communication adapter32within control unit or gateway20, and between communication adapter32and at least one further IDS entity34inside vehicle18, and between further IDS entity34and back end36, are described below by way of example with reference toFIGS.9through14.

The communication from the control unit, for example gateway20, to a further IDS entity/entities34(for example, a central event logger inside vehicle18) is to ensure that further IDS entity34or the event logger is informed about entries that are not read out or events236or selected events226that are stored in memory206. Control unit or gateway20is to send an event report242to further IDS entity34on a regular basis, preferably via a so-called heartbeat signal (cyclic signal, which may be used to check for a proper connection of the communication users). The heartbeat signal (including event report242) is to be encrypted and authenticated. The transmitted information is preferably to be authenticated (optionally using authentication information256) and encrypted, preferably randomly or using a random number273, and exchanged between control unit or gateway20and further IDS entity34. Event report242should preferably have a fixed length257and be encrypted and authenticated. Each encrypted event report242should be different from the preceding event reports242, even if the transmitted status has not changed.

The communication from further IDS entity34to control unit or gateway20or associated communication adapter32is also to be characterized by the following functionalities. The data logger or IDS entity34is to read in events236or associated event reports242as quickly as possible to prevent an overflow in particular of the memory or buffer memory206. It should be possible for event reports242to be read out via a diagnostic interface, for example upon request. Alternatively, event report242could be sent completely cyclically. Event reports242are to be communicated or read out on a regular basis, preferably with authentication and encryption or with masking, even if no new selected events226are available within the scope of a new event report242. Control unit or gateway20is to respond, with encryption and authentication, to a readout request240with a response or an event report242having a fixed length. Each encrypted response or event report242should be different from the preceding responses or event reports242, even if the content has not changed. As an example, this takes place via continually changing variable254, as described above.

According toFIG.9, event manager30initially selects a first selected event226.1and subsequently selects a second selected event226.2. These are processed by event manager30as described. Selected events226.1,226.2are thus stored in memory206. Communication adapter32contains a signal400, a time-dependent interrupt signal (timer IRQ). Time-dependent signal400is preferably formed cyclically, so that the sending of an event report242from communication adapter32to further IDS entities34in vehicle18is thus initiated cyclically. However, even if there are no new events226.1,226.2, as described below a signal (in the form of a “normal” event report242) is sent from communication adapter32to further IDS entity34(cf. signal406). However, the sending of an event report242is particularly preferably not triggered as a function of the receipt of an event220or selected event226, but instead is triggered cyclically (via passage of the cycle time). This is particularly advantageous, since the subsequent transmission to further IDS entities34and/or to back end36also always takes place cyclically, i.e., after passage of a certain time period. Thus, the behavior of event manager30or anomaly detection is not apparent to an intruder. The intruder never knows whether his/her intrusion has been detected, what has been detected, or how the system for anomaly detection operates.

After communication adapter32has received signal400(timer interrupt), communication adapter32requests an event report242from event manager30(signal402). Event manager30creates event report242in question, which includes previously selected events226.1and/or226.2(with respective generic metadata217and event-dependent metadata216) as well as a changed variable254. In addition, appropriate padding data255are added, so that fixed length257of event report242is achieved (with knowledge of the length of authentication information256yet to be formed). Furthermore, for example event manager30generates from changed information254, selected events226.1,226.2, and padding data255a piece of authentication information256, using a certain algorithm. Authentication information256thus formed completes event report242. This is followed by the encryption of complete event report242, using key258. Encrypted event report242as signal404arrives at communication adapter32. Encryption (using changed information254and/or key258) and authentication (formation of authentication information256) could take place in event manager30and/or in communication adapter32when the corresponding security requirements are met.

Alternatively, communication adapter32could encrypt event report242, for example as a function of a random number273. For the encryption, a new random number273is particularly preferably always formed, for example by hashing. This makes it more difficult to decrypt a transferred message or encrypted event report242. Communication adapter33optionally takes over the authentication, using authentication information256and/or the addition of changeable variable254and/or the final encryption of entire event report242via encryption258.

An appropriate signal406is sent to the timer interrupt (signal400), even if no new event report242due to the occurrence of new selected events226is provided by event manager30. A dummy message having the data format of an event report242is then used, and with encryption by a random number or continually changed variable254(using key258) is transferred to further IDS entity34. Dummy messages are also always encrypted using continually changed variables254or new random numbers, so that even when no new selected events226occur, other messages or encrypted messages (signal406) are always cyclically transferred. The functioning of a proper communication link between communication adapter32and further IDS entity34may be checked due to the cyclical transfer.

After the message that is sent from communication adapter32(signal406) is received by further IDS entity34, further IDS entity34sends an acknowledgment signal (408) to communication adapter32. After receipt of acknowledgment signal408, communication adapter32generates a request to event manager30for buffered, optionally reduced, selected events226or associated event reports242to be deleted or once again overwritten (signal410).

In one alternative exemplary embodiment, higher-order entity34and/or back end36checks the authenticity of received encrypted event report242. For this purpose, higher-order entity34and/or back end36decrypt(s) the received message, namely, encrypted event report242, using known key258. Event report242is then available in plaintext. Event report242is authenticated using the appropriate algorithm (which has also been used by event manager30or communication adapter32to create authentication information256) for forming authentication information256. For this purpose, once again all data of received and decrypted event report242(with the exception of authentication information256) are used, and a corresponding piece of authentication information256′ is formed therefrom. Formed authentication information256′ is subsequently compared to authentication information256that is received within the scope of event report242. When there is a match, received event report246is considered to be authentic. In this variant, the further data communication with the higher-level or lower-level entity can occur only after authentication has taken place. In this embodiment, only after a successful authentication is signal408(acknowledgment signal) sent to communication adapter32, which subsequently sends signal410for enabling the overwriting of selected events226.1,226.2to event manager30.

The response or acknowledgment signal408,416should also preferably have a fixed length257′. Acknowledgment signal408should preferably be authenticated and encrypted. Each response or acknowledgment signal408by higher-order entity34and/or back end36should be different, even if the content has not changed.

One example of such an acknowledgment signal408,416is apparent inFIG.9. Acknowledgment signal408,416has a design that is similar to event report242. Acknowledgment signal408,416includes a changeable variable254′. Changeable variable254′ changes for each newly sent acknowledgment signal408,416. Changeable variable254′ could once again be implemented by a random number, a counter, or a time, for example.

Changeable variable254′ of acknowledgment signal408,416could particularly preferably be formed by using changeable variable254of event report242as it has just been transmitted. For this purpose, higher-order entity34,36is configured to extract changeable variable254from received event report242and insert it into acknowledgment signal408,416. In a subsequent step, an authentication of acknowledgment signal408,416could also thus take place by comparing received changeable variable254′ of acknowledgment signal408,416to changeable variable254of event report242that has just been sent. When there is a match, an authentic acknowledgment signal406,408is deduced. In addition, changeable variable254′ itself does not have to be generated in higher-order entity34,36. This may be followed by the enabling of memory206.

In addition, acknowledgment signal408,416includes certain data255′, for example in the form of arbitrary patterns. Furthermore, acknowledgment signal408,416includes a piece of authentication information256′. Authentication information256′, similarly as for event report242, could once again be formed using a certain algorithm that relies on the remaining data of acknowledgment signal408,416, namely, changeable variable254′ and data255′. Authentication information256′ thus formed completes acknowledgment signal408,416. Authentication information256′ has a fixed length257′. An encryption using a key258′ then takes place. This encryption258′ could optionally also be dispensed with.

The receiving entities (higher-order entity34and back end36, for example) and/or communication adapter32or event manager30are once again capable of decrypting acknowledgment signal408,412(using key258′) and authenticating. For this purpose, once again based on the received data (changeable variable254′, data255′), using an appropriately known algorithm, resulting pieces of authentication information256″ are ascertained and compared to obtained pieces of authentication information256′. Authenticity is assumed when there is a match. If the pieces of obtained authentication information256′ are satisfactory, signal410could be generated for enabling memory206. If pieces of authentication information256′ are not satisfactory, it would not be possible for this signal410to be generated, so that selected events226contained in memory206are not (yet) deleted.

In addition, further IDS entity34cyclically receives a timer interrupt signal412, which is formed similarly to signal400as described above. Further IDS entity34once again sends an encrypted message, signal414, on this interrupt signal412. This message optionally contains event report242or a vehicle-related event report (with incorporation of further event reports), as transmitted via signal406upstream from communication adapter32. The same as with communication adapter32, the message is encrypted by further IDS entity34, in particular using a continually changing variable254′ such as a random number273. If communication adapter32has transmitted no event report242, for example because no new selected event226occurred, once again a dummy message having the same data format as an event report242is used, and transferred to back end36with encryption (signal414). Back end36sends an acknowledgment signal416and/or a further communication or request to overwrite events236that are buffered in buffer memory206, or the like, to further IDS entity34. Acknowledgment signal416may be formed as described above.

After receipt of signal410regarding the event enablement, event manager30selects further selected events226.3and226.4. The further sequence is apparent inFIG.10. In the meantime, event manager30also selects a further event226.5. A timer interrupt (signal420) newly arrives at communication adapter32. The communication adapter now requests an event report242for gateway20(signal422). Event manager30sends to communication adapter32an event report242that is based on selected events226.3,226.4,226.5(signal424). After receipt of event report242, communication adapter32sends event report242, which is encrypted and authenticated using a new changeable variable254such as a random number, to further IDS entity34(signal426). Further IDS entity34acknowledges the receipt via an acknowledgment signal428. Acknowledgment signal428may be formed as described in conjunction with acknowledgment signal408(FIG.9). After receipt of acknowledgment signal428, communication adapter32once again sends a request to event manager30to overwrite or delete selected events226.3,226.4,226.5on which event report242is based (signal430). Between the sending of signal424and the receipt of signal430, in the meantime a further selected event226.6is selected. However, this selected event226.6cannot be overwritten yet, since this selected event226.6has not yet been the basis for an event report242already transmitted to communication adapter32. In this regard, signal430does not pertain to overwriting selected event226.6, but, rather, pertains merely to overwriting those selected events226.3,226.4,226.5that have already been transmitted within the scope of most recent event report242.

For further IDS entity34, a timer interrupt (signal432) once again occurs, as described above. As a result, further IDS entity34is prompted to transfer event report242, newly received in signal426, to back end36with encryption (signal434). Back end36acknowledges receipt of message434in question via a corresponding acknowledgment signal436, which is sent to further IDS entity34. Acknowledgment signal436could be formed in the same way as acknowledgment signal408or416.

The further sequence is shown inFIG.11. A further timer interrupt for communication adapter32occurs anew (signal440). Communication adapter32subsequently sends a request to event manager30to send an event report242(signal442). Event manager30sends an event report242containing event226.6, which has been selected in the meantime (signal444). Communication adapter32encrypts event report242, using a new changeable variable256, and sends encrypted event report242to further IDS entity34(signal446). Upon receipt, further IDS entity34sends an acknowledgment (signal448), upon receipt of which communication adapter32sends a request to event manager30to overwrite or enable already transmitted events226.6(450).

Further IDS entity34once again receives a timer interrupt (signal452). Encrypted event report242, optionally together with further vehicle-related event reports of further IDS systems, is subsequently transmitted to back end36. Back end36sends an acknowledgment signal and/or a request to further IDS entity/entities34to enable or overwrite, etc., appropriate events (signal456).

In the example of a sequence according toFIG.12, no new selected event226has occurred between the sending of most recent event report242and the new occurrence of a timer interrupt (signal460). After receipt of timer interrupt460, communication adapter32sends an appropriate request signal462for a new event report242to event manager30. Although new selected event226has occurred, event manager30generates an event report242with dummy content, which is then sent to communication adapter32(signal464). This dummy content may be recognized as such by further IDS entities34and/or by back end36. Communication adapter32encrypts received event report242, which contains dummy content, using a new changed variable254and sends encrypted and authenticated event report242to further IDS entity34(signal466). The receipt is acknowledged by further IDS entity34(signal468). Upon receipt thereof, communication adapter32sends a new request signal to event manager30to overwrite most recently selected events226(signal470). This takes place even if no new selected events226as in this configuration are present.

Further IDS entity34obtains a new timer interrupt (signal472). Further IDS entity34subsequently encrypts most recently obtained encrypted event report242as transmitted by communication adapter32, and sends it, optionally together with vehicle-related further event reports from further IDS systems, to back end36. Back end36sends an acknowledgment signal476and/or a request to enable the underlying events, etc., to further IDS entity34.

In the communication sequence inFIG.13, communication adapter32obtains a new timer interrupt (signal480). This timer interrupt480may be a specific signal, so that communication adapter32requests an event summary from event manager30(and not one of customary event reports242) (signal482). Event manager30sends the event summary to communication adapter32(signal484). The event summary may contain higher-order pieces of information, such as various counter contents231for various event types218, or the occurrence of a new event type, etc. Once again, the event summary is also encrypted by communication adapter32, using a new changeable variable254such as a random number, and is transferred to further IDS entities34(signal486). As soon as IDS entity34has obtained the encrypted event summary from communication adapter32, further IDS entity34relays the event summary, particularly preferably in encrypted form, to back end36. In the exemplary embodiment, for the sending operation between further IDS entity34and back end36, no timer interrupt for initiating the communication operation is provided. Alternatively, however, the communication operation as well as the sending of a customary event report could once again be initiated cyclically.

In the communication sequence inFIG.14, back end36sends a request for an event report to further IDS entity34(signal490). Further IDS entity34sends an encrypted request for an event report, for example via a diagnostic interface, to communication adapter32(signal492). The encryption may once again take place using changeable variable254′ such as a random number, which in particular changes for each encryption. After receipt of request492, communication adapter32sends a request for an event report242to event manager30(signal494). After receipt of request494in question, event manager30sends event report242to communication adapter32(signal496). Communication adapter32encrypts event report242, for example using a new changeable variable254such as a random number, and sends it to further IDS entity34(signal498). After receipt of encrypted event report242, further IDS entity34sends event report242to back end36. Back end36acknowledges receipt to further IDS entity34(signal492). Further IDS entity34acknowledges the receipt of acknowledgment signal492to communication adapter32(signal494). After receipt of signal494in question, communication adapter32sends an appropriate request to event manager30to enable or overwrite at least events220that are transmitted within the scope of most recent event report242.

The described method may be implemented in a processing unit, computer, or controller, in particular in a control unit of a vehicle18. Likewise, the method may be set up within the scope of a computer program that is configured to carry out the method when it is executed on a computer. In addition, the computer program may be stored on a machine-readable memory medium. Nevertheless, the program may be run, for example, wirelessly “over-the-air” as software or in a hard-wired manner via diagnostic interfaces.