Patent Description:
Appended claim <NUM> defines a method for uncovering an electronic control unit to message identification mapping. Appended claim <NUM> defines a non-transitory computer-readable storage medium. Appended claim <NUM> defines a computing apparatus for uncovering an electronic control unit to message identification mapping. The invention and its scope of protection is defined by these independent claims.

Various embodiments of the present disclosure provide for fingerprinting of electronic control units (ECUs) transmitting messages on a communication bus. Conventional fingerprinting techniques require prior knowledge of message identifications (MIDs) for each transmitter of each ECU. Often this information is unavailable or proprietary. As such, the present disclosure provides systems and methods to uncover an ECU to MID mapping. It is noted, that the present disclosure provides an advantage in that the ECU to MID mapping can be uncovered without access to the physical layer.

In general, the present disclosure provides to "force" retransmission of low priority messages to cause an overlap with the expected arrival time of high priority messages. As a result of the forced retransmission and expected overlap with a high priority message, the system and method can determine whether both messages originated from the same ECU or whether the messages originated from different ECUs. Individual ECUs can be fingerprinted based on identifying messages originating from the ECUs and correlating the message IDs, which is described in greater detail below.

As noted, the present disclosure is directed towards fingerprinting ECUs coupled via a communication bus, which can be implemented in a variety of contexts, such as, for example, industrial networks, vehicular networks, manufacturing networks, retail operation networks, warehousing networks, or the like. Although vehicular networks are often used in this description as an example, the claims are not limited to in-vehicle networks.

Using vehicles as an example, modern vehicles have many (often hundreds) of ECUs. These ECUs are communicatively coupled via an in-vehicle network (IVN), such as, CAN bus. For example, there are multiple ECUs for engine control, transmission, airbags, antilock brakes, cruise control, electric power steering, audio systems, power windows, power doors, power mirror adjustment, battery, recharging systems for hybrid/electric cars, environmental control systems, auto start stop systems, blind spot monitoring, lane keeping assist systems, collision avoidance systems, and more complex systems in the case of autonomous, or semi-autonomous vehicles.

ECU fingerprinting schemes are typically used to mitigate the risk of malicious ECUs masquerading as a valid ECU. For example, during operation, the ECUs generate and transmit messages onto the IVN. The present disclosure provides a method to map each message to an ECU. Subsequently, this mapping can be used by a fingerprinting method ensure that messages originating from a particular ECU (e.g., the anti-lock brake ECU, or the like) has indeed originated from the authentic ECU. In many intrusion detection systems (IDSs) machine learning (ML) models are trained to infer, or classify, messages to ECU labels.

The "ground truth" or accuracy of data used to train the ML models is highly correlated to the accuracy of the ML model during actual usage. Accordingly, establishing ground truth for such IDS systems is important for initial training of the ML model. Furthermore, where the system encounters a context shift, the accuracy of the ML model inference may degrade and no longer be valid. Said differently, a change in the physical environment in which the physical characteristics are measured can change the fingerprint of each ECU. For example, an automobile parked overnight will encounter a context shift (e.g., due to changes in temperature, humidity, cooling of vehicle components, or the like) that may affect the fingerprint of the ECUs in the automobile. As such, retraining of the ML model is often required after a context shift.

Establishing ground truth for purposes of training (or retraining) is complicated in that ML based fingerprinting often requires knowledge of all MIDs originating from all ECUs. As stated, this information is often proprietary. For example, the ECUs are often supplied by different manufactures, and as such knowledge of the proprietary information for each ECU in a system (e.g., automobile, or the like) may not be available to a single entity, even the manufacturer of the system itself. Accordingly, initial training as well as retraining (e.g., after a context shift, or the like) of ML models for an IDS is complicated by the fact that establishment of ground truth is not trivial without the above described information, which is often not available.

Accordingly, the present disclosure provides to discover a mapping between ECUs and MIDs (e.g., for initial training of an ML model or for retraining of an ML model) without prior knowledge of all ECU MIDs.

<FIG> illustrates an example system <NUM>, which can be implemented in a vehicle, such as, for example, an automobile, a motorcycle, an airplane, a boat, a personal watercraft, an all-terrain vehicle, or the like. As noted above, the present disclosure is applicable to other systems, besides vehicles, such as, for example, aerospace, industrial, manufacturing, retail, or the like.

System <NUM> includes a number of electronic control units ECUs <NUM>, <NUM>, and <NUM>. System <NUM> further includes ECU identification device <NUM>. System <NUM> includes a communication bus <NUM>, which can be a CAN bus, a FlexRay bus, a CAN FD bus, an automotive ethernet bus, or a local interconnected network (LIN) bus. Additionally, where implemented in contexts outside of the automotive space, the communication bus <NUM> can be a network bus adapted to the particular implementation, such as, for example, a communication network for manufacturing equipment, or the like.

In general, each of ECUs <NUM>, <NUM>, and <NUM> include circuitry arranged to generate messages and transmit the messages onto communication bus <NUM> and/or consume messages from communication bus <NUM>. The depicted ECUs (e.g., ECUs <NUM>, <NUM>, and <NUM>) can be any of a variety of devices, such as, for example, sensor devices, actuator devices, microprocessor control devices, or the like. For example, the ECUs include circuitry arranged to manipulate voltage levels on communication bus <NUM> to communicate messages via the communication bus <NUM>. As depicted, system <NUM> includes three (<NUM>) ECUs. This is done for clarity of presentation. However, in practice (e.g., in a modern automobile, or the like) hundreds of ECUs may be provided in system <NUM>.

ECUs are arranged to generate and/or consume messages, where the messages can include data or commands. Specifically, ECUs <NUM>, <NUM>, and <NUM> can convey messages via communication bus <NUM>. As such, messages are depicted on communication bus <NUM>. In particular, this figure depicts a number of (MSGs), such as, messages <NUM>, <NUM>, <NUM>, and <NUM>. The number of messages is depicted for purposes of clarity and ease of explanation. Many IVN standards, however, do not provide for indicating source information on the bus. Furthermore, many IVN schemes do not have sufficient bandwidth for conventional cryptography techniques useful to indicate the source of messages.

As such, messages <NUM>, <NUM>, <NUM>, and <NUM> often include a message identification (MID) with which receivers can determine whether the message is relevant or not. In particular, message <NUM> is depicted including MID <NUM><NUM>, message <NUM> is depicted including MID <NUM><NUM>, message <NUM> is depicted including MID <NUM><NUM>, and message <NUM> is depicted including MID <NUM><NUM>.

ECU identification device <NUM> includes memory <NUM>, and processing circuitry <NUM>. Memory <NUM> includes instructions <NUM> (e.g., firmware, or the like) that can be executed by processing circuitry <NUM>. During operation, processing circuitry <NUM> can execute instructions <NUM> to consume messages (e.g., message <NUM>, etc.) from communication bus <NUM> and to generate a set of messages under examination <NUM> from the MID of each consumed message. Furthermore, processing circuitry <NUM> can execute instructions <NUM> to generate a mapping between ECUs and MIDs, represented at ECU message ID sets <NUM>. As noted above, the mapping between ECUs and MIDs is often used by an IDS to monitor message traffic on communication bus <NUM>. In some examples, machine learning (ML) is used. As such, ML model <NUM> is depicted. ML model <NUM> can be trained (or retrained as may be the case) based on the ECU message ID sets <NUM>, or rather, the mapping between ECUs and MIDs.

Processing circuitry <NUM> can include any of a variety of processors, such as, for example, commercial central processing units, application specific integrated circuits, or the like. Processing circuitry <NUM> can be a microprocessor or a commercial processor and can include one or multiple processing core(s) and can also include cache.

Memory <NUM> can be based on any of a wide variety of information storage technologies. For example, memory <NUM> can be based on volatile technologies requiring the uninterrupted provision of electric power or non-volatile technologies that do not require and possibly including technologies entailing the use of machine-readable storage media that may or may not be removable. Thus, each of these storages may include any of a wide variety of types (or combination of types) of storage devices, including without limitation, read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDR-DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory (e.g., ferroelectric polymer memory), ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, one or more individual ferromagnetic disk drives, or a plurality of storage devices organized into one or more arrays (e.g., multiple ferromagnetic disk drives organized into a Redundant Array of Independent Disks array, or RAID array). Additionally, memory <NUM> can include storage devices.

ML model <NUM> can be any of a variety of machine learning models, decision trees, classification schemes, or the like. For example, ML model <NUM> can be a random forest model, a support vector machine, or a neural network.

<FIG> depicts a routine <NUM>. Routine <NUM> can be implemented by an intrusion detection system (IDS), such as ECU identification device <NUM>, to determine whether a low priority message originated from the same ECU as a higher priority message. Often, routine <NUM> can be implemented as part of a larger routine to determine a mapping between ECUs and MIDs without accessing the physical layer and without prior knowledge of a similar mapping. Said differently, routine <NUM> can be implemented as part of a larger routine to establish ground truth for an IDS system, such as may be used to train an ML model (e.g., ML model <NUM>, or the like). <FIG> depicts such a larger routine (e.g., routine <NUM>) and is described in greater detail below.

The routines and logic flows described herein, including routine <NUM>, routine <NUM>, and other logic flows or routines described herein, are representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

Routine <NUM> is described with reference to <FIG>, <FIG>. These figures depict hypothetical message traffic on a communication bus for purposes of describing forcing overlap in messages as detailed herein.

In particular, <FIG> depicts bus traffic 300a showing conventional bus traffic. As described above, a number of messages can be transmitted on a communication bus (e.g., communication bus <NUM>, or the like). Using the CAN bus as an example, message traffic is periodic. That is, messages are transmitted at a set frequency. For example, bus traffic 300a depicts low priority message <NUM>, high priority message <NUM>, and low priority message <NUM> being transmitted at times time 310a, time 310b, and time 310c, respectively. It is noted that the messages depicted in <FIG> can be like messages described above with respect to system <NUM> and <FIG> (e.g., message <NUM>, message <NUM>, message <NUM>, message <NUM>, etc.).

As depicted in <FIG>, messages may have varying priority. For example, low priority message <NUM> and high low priority message <NUM> can be lower priority than high priority message <NUM>. In some examples, messages transmitted on a communication bus may have a field indicating a priority of the message, for example, to avoid collisions or to facilitate arbitration between multiple ECUs transmitting at once. As a specific example, messages transmitted on the CAN bus have a priority defined by an arbitration field in the message ID header.

For purposes of the present disclosure, one of the lower priority messages can be selected as a messages of interest. For example, low priority message <NUM> is depicted as message of interest <NUM>. As used herein, a "message of interest" is a message transmitted on the bus with which routine <NUM> is attempting to determine what other messages originated from the same ECU, in order to generate a mapping between ECUs and MIDs (e.g., ECU message ID sets <NUM>, or the like) as detailed herein.

Routine <NUM> may begin at block <NUM>. At block <NUM> "cause overlap in arrival time between a message of interest and a higher priority message" circuitry can consume messages (e.g., message <NUM>, etc.) from communication bus <NUM> and can "force" retransmission of a lower priority message to influence the arrival time of the retransmitted lower priority message to overlap with a higher priority message. As used herein, a higher priority message implies that the message has higher priority than the message of interest. The terms higher and lower are merely used to describe the relationship between priorities of the message being forced to retransmit and the message with which the retransmitted message is being forced to overlap with.

For example, ECU identification device <NUM> can issue a controlled message error <NUM> to cause message of interest <NUM> (e.g., low priority message <NUM>) to retransmit on the bus such that low priority message <NUM> overlaps or collides with a higher priority message (e.g., high priority message <NUM>). <FIG> depicts bus traffic 300b showing controlled message error <NUM> issued to low priority message <NUM> (e.g., the message of interest <NUM>) at time 310a causing low priority message <NUM> be retransmitted at time 310d and issue another controlled message error <NUM> to the low priority message <NUM> at time 310d such that the message of interest <NUM> will eventually collide or overlap with high priority message <NUM>. As a more specific example, processing circuitry <NUM> of ECU identification device <NUM>, in executing instructions <NUM>, can issue a controlled message error. For example, processing circuitry <NUM> can issue a command, notification, flag, or the like comprising an indication that the message of interest <NUM> was not received correctly.

With some examples, the frequency of controlled message error <NUM> issued by processing circuitry <NUM> can be based on policy where overlap between message of interest <NUM> and a higher priority message is desired but forcing ECUs off the bus is avoided. For example, the controlled message error <NUM> should not cause retransmission of messages such that ECUs no longer meet latency requirements or such that ECUs are forced into a "bus-off" state.

Continuing to decision block <NUM> "was higher priority message delayed by message of interest?" circuitry determines whether the higher priority message was delayed by the message of interest. For example, processing circuitry <NUM> in executing instructions <NUM>, can determine whether the higher priority message (e.g., high priority message <NUM>) was delayed by the message of interest <NUM> (e.g., low priority message <NUM>) <FIG> depicts bus traffic 300d illustrating low priority message <NUM> (e.g., message of interest <NUM>) arriving before high priority message <NUM>. More particularly, transmission of the high priority message <NUM> at time 310e is delayed from the expected time (e.g., time <NUM>10b) as the message of interest <NUM> was transmitted at that time, indicating that they are transmitted by the same ECU.

From decision block <NUM>, routine <NUM> can continue to either decision block <NUM> or block <NUM>. For example, routine <NUM> can continue from decision block <NUM> to decision block <NUM> based on a determination at decision block <NUM> that the higher priority message (e.g., high priority message <NUM>) was not delayed by the message of interest <NUM> (e.g., low priority message <NUM>), while routine <NUM> can continue to block <NUM> from decision block <NUM> based on a determination at decision block <NUM> that transmission of the higher priority message (e.g., high priority message <NUM>) was delayed by transmission of the message of interest <NUM> (e.g., low priority message <NUM>).

At decision block <NUM> "did message of interest lose arbitration to higher priority message?" circuitry determines whether the message of interest lost arbitration to the higher priority message. For example, processing circuitry <NUM> in executing instructions <NUM>, can determine whether the message of interest <NUM> (e.g., low priority message <NUM>) lost arbitration to the higher priority message (e.g., high priority message <NUM>). <FIG> depicts bus traffic 300c illustrating low priority message <NUM> (e.g., message of interest <NUM>) losing arbitration to high priority message <NUM> (e.g., the higher priority message to message of interest <NUM>) at time 310b. More particularly, message of interest <NUM> (e.g., low priority message <NUM> is transmitted at time 310b while high priority message <NUM> is also transmitted at time 310b. As they are both transmitted at the same time, indicating that they are transmitted by different ECUs, an arbitration will take place and the higher priority message (e.g., high priority message <NUM>) will win the arbitration. Said differently, the lower priority message (e.g., message of interest <NUM>) will lose the arbitration to the high priority message <NUM>.

From decision block <NUM>, routine <NUM> can end. For example, routine <NUM> can end after a determination at decision block <NUM> that the message of interest <NUM> (e.g., low priority message <NUM>) did lose arbitration to the higher priority message (e.g., high priority message <NUM>). Optionally, routine <NUM> can also end based on a determination at decision block <NUM> that the message of interest did not lose arbitration with the higher priority message. For example, where arbitration between the message of interest <NUM> and the higher priority message (e.g., high priority message <NUM>) is initiated, it is assumed that the messages are transmitted at the same (or similar) times and as such, did not originate from the same ECU.

At bock block <NUM> "add MID for message of interest and higher priority message to the same ECU message set" circuitry adds indications of the message of interest <NUM> (e.g., low priority message <NUM>) and the high priority message <NUM> to ECU message ID sets <NUM>. Said differently, based on a determination at decision block <NUM> that the higher priority message was delayed by the message of interest <NUM>, it is assumed that the messages originated from the same ECU. As such, the MIDs associated with these messages are associated with the same ECU via ECU message ID sets <NUM>. For example, processing circuitry <NUM> in executing instructions <NUM>, can add indications of MIDs for message of interest <NUM> (e.g., low priority message <NUM>) and high priority message <NUM> to a one of ECU message ID sets <NUM> associated with the ECU message of interest <NUM>. Where the ECU for message of interest <NUM> is unknown, a new set of ECU message ID sets <NUM> can be created for this ECU.

Conversely, where based on a determination at decision block <NUM> that the higher priority message (e.g., high priority message <NUM>) was not delayed by the message of interest <NUM> and a determination at decision block <NUM> that the message of interest <NUM> did lose arbitration to the higher priority message (e.g., high priority message <NUM>), it is assumed that the messages did not originate from the same ECU. As such, the MIDs associated with these messages are not associated with the same ECU via ECU message ID sets <NUM> and routine <NUM> can end.

As noted, <FIG> illustrates a routine <NUM> that can be implemented to identify, discover, or determine a mapping between ECUs and MIDs of messages transmitted on a communication bus. In some example, routine <NUM> can be implemented in a non-adversarial environment (e.g., original equipment manufacturer setting, or the like) where it is assumed that all ECUs are valid. In other examples, routine <NUM> can be implemented in an adversarial environment (e.g., where it is unknown if malicious ECUs exist or not). Examples are not limited in this respect.

Routine <NUM> can begin at block <NUM> "select lowest priority message from a set of messages under examination as message of interest" circuitry can identify the lowest priority message from a set of messages under examination. For example, processing circuitry <NUM> in executing instructions <NUM> can identify the lowest priority message from set of messages under examination <NUM>.

<FIG> illustrates an example set of messages under examination 500a including a number of messages message <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. At block <NUM>, processing circuitry <NUM> can execute instructions <NUM> to identify one of the messages from set of messages under examination 500a as the message having the lowest priority. For example, message <NUM> is illustrated in <FIG> as the message having the lowest priority (e.g., lowest priority message <NUM>). This message (e.g., message <NUM>) can be set as the message of interest (e.g., message of interest <NUM>, or the like) while the other messages (e.g., message <NUM>, etc.) can be labeled as higher priority messages <NUM>.

Returning to <FIG>, routine <NUM> can continue from block <NUM> to execute routine <NUM>. For example, routine <NUM> can be executed to cause the lowest priority message (e.g., message <NUM>), which is designated as the message of interest (e.g., message <NUM>), to overlap with messages from the higher priority messages <NUM> to determine whether the message of interest (e.g., message <NUM>) originated from the same ECU as ones of the higher priority messages <NUM>.

It is noted that routine <NUM> provides to iteratively execute routine <NUM>, in order to cause the message of interest (e.g., message <NUM>) to overlap with each of the higher priority messages <NUM>. To that end, from routine <NUM> in routine <NUM>, routine <NUM> can continue to decision block <NUM> "is there a message in the set of messages under examination that has not overlapped with the message of interest?" circuitry can determine whether there is a message in the set of messages under examination 500a (or more specifically, whether one of the higher priority messages <NUM> has not overlapped with the message of interest (e.g., message <NUM>).

From decision block <NUM>, routine <NUM> can either re-execute routine <NUM>, for example, to cause the message of interest to overlap with another one of the higher priority messages <NUM> or can continue to decision block <NUM>. In particular, routine <NUM> can return to routine <NUM> from decision block <NUM> based on a determination that there are messages (e.g., ones of higher priority messages <NUM>) in the set of messages under examination 500a that have not overlapped with the lowest priority message (e.g., message <NUM>). Alternatively, routine <NUM> can continue to decision block <NUM> from decision block <NUM> based on a determination that there are not messages (e.g., ones of higher priority messages <NUM>) in the set of messages under examination 500a that have not overlapped with the lowest priority message (e.g., message <NUM>).

At decision block <NUM> "is there a message in the set of messages under examination that was not added to the ECU message set?" circuitry can determine whether messages in the set of messages under examination 500a (or rather higher priority messages <NUM>) that were not added to the ECU message ID set as part of routine <NUM>. For example, as detailed earlier, routine <NUM> determines whether a lower priority message originated from the same ECU as a higher priority message, and if so, links or maps the MIDs for these messages to the same ECU, for example, via indications of MIDs in ECU message ID sets <NUM>. Accordingly, <FIG> illustrates an example ECU message ID set 500b depicting messages message <NUM>, message <NUM>, and message <NUM> mapped to the same ECU. That is, assuming based on one iterative execution of routine <NUM> during routine <NUM>, that it is determined that message <NUM>, message <NUM>, and message <NUM> originated from the same ECU then ECU message ID set 500b can be created to map the MIDs for these messages to the same ECU.

From decision block <NUM>, routine <NUM> can continue to either block <NUM> or can end. In particular, from decision block <NUM>, routine <NUM> can continue to block <NUM> based on a determination that messages in the set of messages under examination 500a were not added to an ECU message ID set, while routine <NUM> can end after decision block <NUM> based on a determination that all messages in the set of messages under examination 500a were added to an ECU message ID set.

At block <NUM> "remove messages in the ECU message set from message under examination" circuitry can remove messages that are in an ECU message set from the messages under examination. For example, processing circuitry <NUM> in executing instructions <NUM> can remove from the messages under examination (set of messages under examination <NUM>, or the like) messages that were added to ECU message ID sets <NUM>. As a specific example, <FIG> illustrates set of messages under examination 500c where message <NUM>, message <NUM>, and message <NUM>, which were previously added to ECU message ID set 500b, have been removed, leaving message <NUM>, message <NUM>, message <NUM>, and message <NUM> in the set of messages under examination 500c. From block <NUM>, routine <NUM> can return to block <NUM> where the remaining lowest priority message (e.g., message <NUM>) is designated at lowest priority message <NUM> and the remaining messages in set of messages under examination 500c are designated as higher priority messages <NUM> and routine <NUM> is iteratively executed again to determine whether lowest priority message <NUM> originated from the same ECU as any one of the higher priority messages <NUM> based on causing the lowest priority message <NUM> to overlap with ones of the higher priority messages <NUM> as outlined herein.

<FIG> illustrates an example of a storage device <NUM>. Storage device <NUM> may comprise an article of manufacture, such as, any non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. Storage device <NUM> may store various types of computer executable instructions <NUM>, such as instructions to implement routine <NUM> and/or routine <NUM>. Examples of a computer readable or machine readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. The examples are not limited in this context.

<FIG> illustrates an embodiment of a system <NUM>. System <NUM> is a computer system with multiple processor cores such as a distributed computing system, supercomputer, high-performance computing system, computing cluster, mainframe computer, mini-computer, client-server system, personal computer (PC), workstation, server, portable computer, laptop computer, tablet computer, handheld device such as a personal digital assistant (PDA), or other device for processing, displaying, or transmitting information. Similar embodiments may comprise, e.g., entertainment devices such as a portable music player or a portable video player, a smart phone or other cellular phone, a telephone, a digital video camera, a digital still camera, an external storage device, or the like. Further embodiments implement larger scale server configurations. In other embodiments, the system <NUM> may have a single processor with one core or more than one processor. Note that the term "processor" refers to a processor with a single core or a processor package with multiple processor cores. In at least one embodiment, the computing system <NUM> is representative of the components of the system <NUM>. More generally, the computing system <NUM> is configured to implement all logic, systems, logic flows, methods, apparatuses, and functionality described herein.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary system <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in this figure, system <NUM> comprises a motherboard or system-on-chip(SoC) <NUM> for mounting platform components. Motherboard or system-on-chip(SoC) <NUM> is a point-to-point (P2P) interconnect platform that includes a first processor <NUM> and a second processor <NUM> coupled via a point-to-point interconnect <NUM> such as an Ultra Path Interconnect (UPI). In other embodiments, the system <NUM> may be of another bus architecture, such as a multi-drop bus. Furthermore, each of processor <NUM> and processor <NUM> may be processor packages with multiple processor cores including core(s) <NUM> and core(s) <NUM>, respectively as well as one or more registers, such as registers <NUM> and <NUM>, respectively. While the system <NUM> is an example of a two-socket (<NUM>) platform, other embodiments may include more than two sockets or one socket. For example, some embodiments may include a four-socket (<NUM>) platform or an eight-socket (<NUM>) platform. Each socket is a mount for a processor and may have a socket identifier. Note that the term platform refers to the motherboard with certain components mounted such as the processor <NUM> and chipset <NUM>. Some platforms may include additional components and some platforms may only include sockets to mount the processors and/or the chipset. Furthermore, some platforms may not have sockets (e.g. SoC, or the like).

The processor <NUM> and processor <NUM> can be any of various commercially available processors, including without limitation an Intel® Celeron®, Core®, Core (<NUM>) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; and similar processors. Dual microprocessors, multi-core processors, and other multi processor architectures may also be employed as the processor <NUM> and/or processor <NUM>. Additionally, the processor <NUM> need not be identical to processor <NUM>.

Processor <NUM> includes an integrated memory controller (IMC) <NUM> and point-to-point (P2P) interface <NUM> and P2P interface <NUM>. Similarly, the processor <NUM> includes an IMC <NUM> as well as P2P interface <NUM> and P2P interface <NUM>. IMC <NUM> and IMC <NUM> couple the processors processor <NUM> and processor <NUM>, respectively, to respective memories (e.g., memory <NUM> and memory <NUM>). Memory <NUM> and memory <NUM> may be portions of the main memory (e.g., a dynamic random-access memory (DRAM)) for the platform such as double data rate type <NUM> (DDR3) or type <NUM> (DDR4) synchronous DRAM (SDRAM). In the present embodiment, the memories memory <NUM> and memory <NUM> locally attach to the respective processors (i.e., processor <NUM> and processor <NUM>). In other embodiments, the main memory may couple with the processors via a bus and shared memory hub.

System <NUM> includes chipset <NUM> coupled to processor <NUM> and processor <NUM>. Furthermore, chipset <NUM> can be coupled to storage device <NUM>, for example, via an interface (I/F) <NUM>. The I/F <NUM> may be, for example, a Peripheral Component Interconnect-enhanced (PCI-e).

Processor <NUM> couples to a chipset <NUM> via P2P interface <NUM> and P2P <NUM> while processor <NUM> couples to a chipset <NUM> via P2P interface <NUM> and P2P <NUM>. Direct media interface (DMI) <NUM> and DMI <NUM> may couple the P2P interface <NUM> and the P2P <NUM> and the P2P interface <NUM> and P2P <NUM>, respectively. DMI <NUM> and DMI <NUM> may be a highspeed interconnect that facilitates, e.g., eight Giga Transfers per second (GT/s) such as DMI <NUM>. In other embodiments, the processor <NUM> and processor <NUM> may interconnect via a bus.

The chipset <NUM> may comprise a controller hub such as a platform controller hub (PCH). The chipset <NUM> may include a system clock to perform clocking functions and include interfaces for an I/O bus such as a universal serial bus (USB), peripheral component interconnects (PCIs), serial peripheral interconnects (SPIs), integrated interconnects (I2Cs), and the like, to facilitate connection of peripheral devices on the platform. In other embodiments, the chipset <NUM> may comprise more than one controller hub such as a chipset with a memory controller hub, a graphics controller hub, and an input/output (I/O) controller hub.

In the depicted example, chipset <NUM> couples with a trusted platform module (TPM) <NUM> and UEFI, BIOS, FLASH circuitry <NUM> via I/F <NUM>. The TPM <NUM> is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. The UEFI, BIOS, FLASH circuitry <NUM> may provide pre-boot code.

Furthermore, chipset <NUM> includes the I/F <NUM> to couple chipset <NUM> with a high-performance graphics engine, such as, graphics processing circuitry or a graphics processing unit (GPU) <NUM>. In other embodiments, the system <NUM> may include a flexible display interface (FDI) (not shown) between the processor <NUM> and/or the processor <NUM> and the chipset <NUM>. The FDI interconnects a graphics processor core in one or more of processor <NUM> and/or processor <NUM> with the chipset <NUM>. Additionally, ML accelerator <NUM> coupled to chipset <NUM> via I/F <NUM>. ML accelerator <NUM> can be circuitry arranged to execute ML related operations (e.g., training, inference, etc.) for ML models. In particular, ML accelerator <NUM> can be arranged to execute mathematical operations and/or operands useful for machine learning.

Various I/O devices <NUM> and display <NUM> couple to the bus <NUM>, along with a bus bridge <NUM> which couples the bus <NUM> to a second bus <NUM> and an I/F <NUM> that connects the bus <NUM> with the chipset <NUM>. In one embodiment, the second bus <NUM> may be a low pin count (LPC) bus. Various devices may couple to the second bus <NUM> including, for example, a keyboard <NUM>, a mouse <NUM> and communication devices <NUM>.

Furthermore, an audio I/O <NUM> may couple to second bus <NUM>. Many of the I/O devices <NUM> and communication devices <NUM> may reside on the motherboard or system-on-chip(SoC) <NUM> while the keyboard <NUM> and the mouse <NUM> may be add-on peripherals. In other embodiments, some or all the I/O devices <NUM> and communication devices <NUM> are add-on peripherals and do not reside on the motherboard or system-on-chip(SoC) <NUM>.

<FIG> illustrates an in-vehicle communication architecture <NUM> according to one or more embodiments of the disclosure. For example, one or more vehicular devices, components, or circuits, such as circuitry <NUM> and/or circuitry <NUM>, may communicate with each other via a communication framework <NUM>, which may be an in-vehicle network, such as a CAN bus, implemented to facilitate establishing ground truth for an IDS based on collapsing overlapping MID voltage signatures into a single ECU label.

The in-vehicle communication architecture <NUM> includes various common communications elements, such as a transmitter, receiver, transceiver, and so forth. The embodiments, however, are not limited to implementation by the in-vehicle communication architecture <NUM>. As shown in this figure, the vehicular circuitry <NUM> and circuitry <NUM> may each be operatively connected to one or more respective data devices, such as, data device <NUM> and/or data device <NUM> that can be employed to store information local to the respective circuitry <NUM> and/or circuitry <NUM>, such as fingerprints, distributions, densities, voltage signals, or the like. It may be understood that the circuitry <NUM> and circuitry <NUM> may be any suitable vehicular component, such as sensor, an ECU, microcontroller, microprocessor, processor, ASIC, field programmable gate array (FPGA), any electronic device, computing device, or the like. Moreover, it may be understood that one or more computing devices (containing at least a processor, memory, interfaces, etc.) may be connected to the communication framework <NUM> in a vehicle.

Further, the communication framework <NUM> may implement any well-known communications techniques and protocols. As described above, the communication framework <NUM> may be implemented as a CAN bus protocol or any other suitable in-vehicle communication protocol. The communication framework <NUM> may also implement various network interfaces arranged to accept, communicate, and connect to one or more external communications networks (e.g., Internet). A network interface may be regarded as a specialized form of an input/output (I/O) interface. Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair <NUM>/<NUM>/<NUM> Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE <NUM>. 7a-x network interfaces, IEEE <NUM> network interfaces, IEEE <NUM> network interfaces, and the like. Further, multiple network interfaces may be used to engage with various communications network types. The communication framework <NUM> may employ both wired and wireless connections.

Claim 1:
A method for uncovering an electronic control unit ,ECU, to message identification, MID, mapping, comprising the steps of
identifying, by processing circuitry coupled to a communication bus, a first message from a plurality of messages transmitted on the communication bus as a low priority message;
determining, by the processing circuitry, whether the low priority message and a second message from the plurality of messages originated from a first electronic control unit, ECU, coupled to the communication bus, the second message being a higher priority message than the low priority message; and
associating, by the processing circuitry via an ECU message identification, MID, set, an MID of the low priority message and an MID of the higher priority message to the first ECU; and
wherein the determining whether the low priority message and the higher priority message originated from the first ECU comprises:
issuing (<NUM>) at least one controlled message error on the communication bus against the low priority message to force the low priority message to be retransmitted to cause an overlap between transmission of the low priority message and the higher priority message;
determining (<NUM>) whether, responsive to the overlap, the higher priority message was delayed by the low priority message; and
determining that the low priority message and the higher priority message did originate from the first ECU based on a determination that the higher priority message was delayed by the low priority message.