AAP HW: Flooding prevention and suspend detection & undisturbed controller replacement against message modification attacks

Abstract

The invention name of the present disclosure is "AAP HW: Flood Prevention and Hang Detection & Unperturbed Controller Replacement for Message Modification Attacks." Systems, methods, computer-readable storage media, and devices provide active attack detection in autonomous vehicle networks. A device can include a plurality of electronic control units communicably coupled over a network, and logic, at least a portion of which is implemented in hardware, to: receive an indication from a first electronic control unit (ECU) of the plurality of ECUs to transmit a first data frame via the network; determine whether a transmission window of the first ECU is open based on a message identifier (ID) of the first ECU; and grant the first ECU permission to transmit the first data frame via the network based on a determination that the transmission window of the first ECU is open.

Description

Background Technology

[0001] Autonomous vehicles comprise multiple components that can be communicatively coupled via an in-vehicle communication network. A malicious attacker could attempt to gain control of one or more components, potentially negatively impacting the operation of the autonomous vehicle and posing significant safety risks. Often, maintaining the integrity of trusted message flows on the in-vehicle network is difficult while detecting and / or preventing attacks. Attached Figure Description

[0002] Figure 1 An embodiment of the system is illustrated.

[0003] Figure 2 The illustration shows an example of active attack detection in an autonomous vehicle network.

[0004] Figure 3 The illustration shows an example of active attack detection in an autonomous vehicle network.

[0005] Figures 4A-4C The illustration shows an example of active attack detection in an autonomous vehicle network.

[0006] Figures 5A-5B The illustration shows an example of active attack detection in an autonomous vehicle network.

[0007] Figure 6 An example of the first logical flow is illustrated.

[0008] Figure 7 An example of the second logical flow is illustrated.

[0009] Figure 8 An example of the third logical flow is illustrated.

[0010] Figure 9 An example of the fourth logical flow is illustrated.

[0011] Figure 10 An example of a storage medium is illustrated.

[0012] Figure 11 An embodiment of the system is illustrated. Detailed Implementation

[0013] The embodiments disclosed herein provide techniques for detecting attacks on autonomous vehicle components and taking corrective actions to neutralize such attacks. For example, the embodiments disclosed herein can detect flooding attacks and / or suspension attacks while allowing trusted message flows (e.g., data frames) to remain intact on the in-vehicle network. Furthermore, the embodiments disclosed herein can neutralize messages transmitted by compromised system components to prevent other system components from implementing commands specified by said messages. Further, the embodiments disclosed herein provide techniques for removing compromised components from the system so that they are replaced by backup components.

[0014] The embodiments disclosed herein provide various methods for detecting attacks on components of autonomous vehicles, also known as electronic control units (ECUs). For example, the embodiments disclosed herein provide distributed and / or centralized methods for attack detection. In a distributed approach, hardware security logic can be a component of each ECU (and / or can be located between a given ECU and the in-vehicle network). This allows the hardware security logic to prevent flooding attacks on ECUs and / or detect hang-up attacks in the autonomous vehicle. In a centralized approach, the hardware security logic can be a separate component that listens for traffic on the network to prevent flooding attacks on any ECU on the network and / or detect hang-up attacks on any ECU on the network.

[0015] In a distributed approach, to prevent flooding attacks, security logic typically manages the access of the corresponding ECU to the in-vehicle network. In such an embodiment, each ECU may have defined transmission (or delivery) intervals during which each ECU can transmit a single message. If an ECU attempts to transmit additional messages during a transmission interval, the security logic may restrict the transmission of the additional messages over the network. However, if a collision is detected on the network, the security logic may permit the ECU to attempt additional transmissions, allowing the ECU to transmit the single message during the transmission interval. In a distributed approach, to detect suspending attacks, the security logic may determine whether the corresponding ECU has already transmitted a message during one or more transmission intervals. If the ECU has not transmitted a message during one or more transmission intervals, the security logic may determine that the ECU is under suspending attack and generate an alert and / or take corrective actions (e.g., restricting the ECU from transmitting messages and / or operating within the autonomous vehicle).

[0016] In a centralized approach, security logic can detect flooding attacks based on the voltage fingerprint of transmissions made by each ECU. If the voltage fingerprint of a given message does not match (or is dissimilar, or unequal to) the known voltage fingerprint (also known as a “voltage feature” or “multiple voltage features”) of the ECU that transmitted the message, the security logic can determine that the message is malicious and the transmitting ECU is under flooding attack. In such an example, the security logic can generate an alert and / or take corrective actions (e.g., counteract the malicious message, restrict the ECU from transmitting messages, and / or operate within the autonomous vehicle). This allows the security logic to counteract malicious messages while preserving trusted messages. To detect suspending attacks, the security logic can determine whether a given ECU has already transmitted a message during the transmission interval. If the ECU has not transmitted a message during the transmission interval, the security logic can determine that the ECU is under suspending attack. Furthermore, the security logic can determine whether the ECU transmitted a message with an untrusted voltage fingerprint during the transmission interval. If a message with an untrusted voltage fingerprint (e.g., a voltage fingerprint that is not equal to one or more known voltage characteristics associated with the transmitting ECU) is detected during a transmission cycle, the security logic can determine that the ECU is under a suspending attack and counteract the message. The security logic can then generate an alert and / or take corrective action against the suspending attack (e.g., restricting the ECU from transmitting messages and / or operating within the autonomous vehicle). Typically, by utilizing voltage fingerprints, the security logic is able to detect suspending attacks and detect that a malicious attacker is transmitting malicious messages. This allows the security logic to counteract malicious messages while permitting trusted messages to traverse the network.

[0017] Conventionally, the operation specified in a message transmitted by a compromised ECU can be implemented by other ECUs in the autonomous vehicle. For example, a message sent by a compromised brake controller could cause a brake actuator to maliciously apply the brakes of the autonomous vehicle. However, advantageously, the embodiments disclosed herein prevent the operation from being implemented in the vehicle. For example, security logic can analyze at least a portion of the payload of a message transmitted over the network based on the current system state. If the security logic determines that the analyzed portion of the payload specifies modifying the autonomous vehicle's operating parameters to a specified value, the security logic can determine whether that specified value is outside the expected range of the operating parameters. For example, if the vehicle is traveling at 20 mph, the expected range of the vehicle speed could be 15-25 mph. If the specified value of the operating parameter is outside the expected range (e.g., 50 mph), the security logic can modify the message so that other ECUs in the vehicle do not cause the autonomous vehicle's operating parameters to adopt that specified value (e.g., do not cause the autonomous vehicle to accelerate to 50 mph). For example, security logic can modify the second part of a message (which can be any field of the message) to corrupt the message, causing it to be rejected and / or not consumed by other ECUs.

[0018] Furthermore, the embodiments disclosed herein can provide a backup ECU that can be dynamically activated when a damaged ECU is detected. This allows the backup ECU to provide reliable and effective information once activated in the autonomous vehicle. For example, a backup brake controller can replace the main brake controller subjected to flooding and / or hang-up attacks. Additionally, in some embodiments, the backup ECU can learn the behavior of the main ECU under normal operating conditions. This allows the backup ECU to immediately replace the damaged ECU and begin transmitting information to maintain the actuation cycle of the autonomous vehicle.

[0019] Advantageously, the embodiments disclosed herein provide techniques for enhancing security in autonomous vehicles. By detecting different types of attacks, the embodiments disclosed herein can isolate a compromised ECU and activate a backup ECU in the system. Furthermore, by modifying messages transmitted by the compromised ECU, the embodiments disclosed herein ensure that other ECUs in the system do not act on any messages transmitted by the compromised ECU. This improves the performance of the autonomous vehicle and enhances the security of its operation.

[0020] Referring generally to the notation and terminology used herein, one or more portions of the following detailed description may be presented according to the program procedures executed on a computer or computer network. These procedures are described and represented by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. Procedures herein and generally considered to be self-consistent sequences of operations leading to desired results. These operations are those that require physical manipulation of physical quantities. Typically, although not essential, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. For general reasons, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc. However, it should be noted that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

[0021] Furthermore, these manipulations are often referred to using terms such as addition or comparison, which are typically associated with intellectual operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such human operator capability is, in most cases, undesirable or unnecessary. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include general-purpose digital computers, such as those selectively activated or configured by computer programs stored therein and written in accordance with the teachings herein, and / or include devices specifically constructed for the claimed purpose. The various embodiments also relate to devices or systems for performing these operations. These devices may be specifically constructed for the claimed purpose or may include general-purpose computers. The required structures for the various machines among these machines will be apparent from the given description.

[0022] Referring now to the accompanying drawings, similar reference numerals are used throughout to refer to similar elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding thereof. However, it will be apparent, however, that novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form for ease of description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0023] Figure 1 An embodiment of system 100 is illustrated. As shown, system 100 includes a plurality of electronic control units (ECUs) 101-1 to 101-N, where "N" is a positive integer greater than 1. Although in Figure 1Four ECUs 101 are depicted, but the device including system 100 may include any number of ECUs. In one embodiment, the device including system 100 may include an autonomous vehicle. Typically, an ECU can control one or more components of an autonomous vehicle, such as braking components, powertrain components, steering components, airbags, etc. Example ECUs include, but are not limited to, engine control module (ECM), powertrain control module (PCM), transmission control module (TCM), brake control module (BCM or EBCM), central control module (CCM), central timing module (CTM), general electronic module (GEM), body control module (BCM), or suspension control module (SCM). Multiple ECUs 101 may be communicatively coupled via network 112, which may also be referred to as a network. In one embodiment, network 112 includes a controller area network (CAN), which allows ECUs 101 to communicate with each other using data frames (also referred to as messages) transmitted according to a CAN message-based protocol, and does not require a centralized host in system 100. Although Network 112 is discussed with reference to autonomous vehicles, this disclosure is equally applicable to other types of networks, and the use of autonomous vehicles as examples herein should not be considered as a limitation of this disclosure.

[0024] ECU 101 illustratively includes processor 103 and memory 104. Processor 103 may include multiple processor cores, each of which may include multiple processing threads. Processor 103 may include a general-purpose processor, a special-purpose processor, a central processing unit, a controller, a microcontroller, etc. In other embodiments, ECU 101 may include other types of configurable logic and / or circuitry systems, such as field-programmable gate arrays (FPGAs), microcontrollers, application-specific integrated circuits (ASICs), system-on-a-chip (SoCs), programmable logic arrays (PLAs), complex programmable logic devices (CPLDs), or fixed-function logic hardware using circuitry technologies such as, for example, complementary metal-oxide-semiconductor (CMOS) or transistor-transistor (TTL) technologies, or any combination thereof.

[0025] As shown in the figure, ECUs 101-1, 101-3, and 101-N include instances of security logics 102-1, 102-3, and 102-N, respectively. Similarly, an instance of security logic 102-2 is located between ECU 101-2 and network 112. Regardless of whether security logic 102 is incorporated into or outside of ECU 101, security logic 102 can be configured to regulate access to network 112 by the corresponding ECU 101. Security logic 102 can be implemented using hardware, software, and / or a combination of hardware and software. For example, security logic 102 may include a microcontroller, FPGA, ASIC, PLA, CMOS, TTL, CPLD, or any other type of logic. In one embodiment, security logic 102 is ECU 101.

[0026] Figure 1 This indicates a "distributed" approach, where instance control of security logic 102 is exercised by ECU 101's access to the network. For example, when ECU 101-1 attempts to transmit a data frame (or message) via network 112, security logic 102-1 may permit and / or restrict ECU 101-1 from transmitting the data frame. Similarly, when ECU 101-2 attempts to transmit a data frame via network 112, security logic 102-2 may permit and / or restrict ECU 101-1 from transmitting the data frame. Security logic 102 typically modulates control over network 112 to prevent flooding attacks against compromised ECU 101 or to detect hang-up attacks against compromised ECU 101. A flooding attack can occur when a malicious entity (e.g., a virus, malware, malicious hardware, etc.) compromises ECU 101 and causes ECU 101 to transmit multiple data frames via network 112, thereby "flooding" network 112. This can reflect a form of denial-of-service attack because legitimate business cannot be transmitted via network 112. The hang-up attack reflects that a malicious entity causes the compromised ECU 101 to suppress the transmission of trusted data frames as intended via network 112 and / or transmit fraudulent data frames instead of trusted data frames.

[0027] Each ECU 101 can be configured to periodically transmit data frames. Each ECU 101 can be associated with one or more unique message identifiers (IDs), which are inserted into the messages transmitted by the ECU 101. For example, ECU 101-1 can transmit data frames with message ID values ​​varying from 0 to 10, while ECU 101-2 can transmit data frames with message ID values ​​varying from 11 to 100, and so on. In some embodiments, the message ID value reflects the relative priority of arbitration on network 112. For example, if ECU 101-1 attempts to transmit a data frame with ID value 1, and ECU 101-2 attempts to transmit a data frame with ID value 50, then ECU 101-1 will be granted access to network 112 before ECU 101-2 because message ID value 1 has a higher priority than message ID value 50. Generally, the lower the message ID number, the higher the message priority.

[0028] In some embodiments, each instance of security logic 102 is programmed to include knowledge of the transmission patterns of the corresponding ECU 101 it manages. In other embodiments, security logic 102 can learn the transmission patterns of the corresponding ECU 101 by monitoring the timing of data frames transmitted by each ECU 101 during normal operation. Advantageously, security logic 102 can ensure that each ECU 101 transmits only a single data frame at a given transmission interval and while a transmission window is open for the ECU 101, except for the exceptions described herein. Doing so allows security logic 102 to prevent flooding attacks, detect hang-up attacks, and take corrective actions to protect the security of system 100 and / or the autonomous vehicle including system 100. For example, security logic 102 can disable an affected ECU 101, restrict the transmission of data frames by the affected ECU 101, modify the data frames transmitted by the affected ECU 101, and / or replace the affected ECU 101 with a different ECU 101.

[0029] In an embodiment where network 112 is a CAN implementation, the functionality described herein operates at a low level in the CAN stack by observing the data transmitted via network 112 bit by bit to extract information about each frame as it is transmitted in network 112. Conventionally, CAN requires messages to be fully received before they can be used by an ECU. Thus, conventional solutions must wait for the entire frame to be received before any analysis. Advantageously, however, by operating at a lower level in the CAN stack, the embodiments disclosed herein can inspect messages as they are transmitted over the network. In this way, the embodiments disclosed herein facilitate faster (relative to conventional CAN implementations) decision-making before messages are received by upper-level services and / or other receiving ECUs in the CAN stack (which may operate according to the conventional CAN stack and / or modified CAN stacks disclosed herein). Furthermore, although CAN is an example network implementation disclosed herein, the techniques disclosed herein can be applied to other types of networks.

[0030] Figure 2 The diagram shows the detection pair. Figure 1 The timing diagram 200 is an example of a flood attack on ECU 101. As shown, timing diagram 200 includes a timeline reflecting the flood attack caused by... Figure 1 The timing diagram 200 includes a timeline 201 representing the data frames transmitted by the example ECU 101. The timing diagram 200 further includes a timeline 202 representing the transmission windows of the example ECU 101. In timeline 202, solid lines represent “open” transmission windows, where ECU 101 is permitted to transmit data frames, while dashed lines represent “closed” transmission windows, where ECU 101 is not permitted to transmit data frames via network 112. Open and / or closed windows can be based on a timing window associated with the message ID of each ECU 101 and / or the data frame to be transmitted by ECU 101. Thus, as shown, windows 220-224 correspond to open transmission windows on timeline 202. Furthermore, timeline 230 can define transmission intervals based on points 231-235, such as a first transmission interval between points 231 and 232, a second transmission interval between points 232 and 233, and so on. The transmission interval can typically be defined as a time interval (e.g., 1 millisecond, 1 second, etc.) during which a single data frame is transmitted by ECU 101, except for the exceptions described herein.

[0031] As shown on timeline 201, during open window 220, ECU 101 may attempt to transmit data frame 203 via network 112. Because data frame 203 is the only data frame to be transmitted during the open transmission window 220 (and within the transmission interval ending at point 231), safety logic 102 managing ECU 101 permits ECU 101 to transmit data frame 203. Similarly, because data frame 204 is the only transmission attempted during open window 221 and the transmission interval defined by points 231 and 232, safety logic 102 permits ECU to transmit data frame 204.

[0032] However, within window 222, another ECU 101 can transmit data frame 205. If ECU 101 were to transmit a data frame at the same time as data frame 205, a collision on network 112 could occur. Therefore, safety logic 102 can delay the transmission of the data frame until data frame 205 has already been transmitted via network 112. However, doing so would delay the transmission of data frame 206 until the transmission interval defined by points 233 and 234. However, as shown, once data frame 205 has been transmitted via network 112 during the transmission interval defined by points 233 and 234 and within window 222, safety logic 102 allows ECU 101 to transmit data frame 206.

[0033] As shown, ECU 101 may attempt to transmit data frame 207 during open window 223 and within the transmission interval defined by points 233 and 234. As stated, security logic 102 typically restricts ECU 101 to a single transmission during the transmission window. However, security logic 102 may permit the transmission of data frame 207 during the time interval defined by points 233 and 234 because the transmission of data frame 206 is delayed due to a detected collision. Therefore, in this example, security logic 102 is able to determine that a second transmission during the transmission interval defined by points 233 and 234 is credible and not a flooding attack on ECU 101. However, if data frame 206 is not delayed due to a collision, security logic 102 may restrict ECU 101 to transmit data frame 207 to prevent a flooding attack, since only one data frame is permitted to be transmitted by a given ECU during the transmission interval.

[0034] Furthermore, as shown in the figure, when ECU 101 attempts to transmit during a closed transmission cycle, security logic 102 can restrict the transmission of data frames 208 and 209. During open window 224, security logic 102 can allow the transmission of data frame 210 and restrict the transmission of data frame 211, as data frame 211 may reflect a flooding attack. If security logic 102 determines that ECU 101 is under a flooding attack, security logic 102 can generate an alarm and transmit the alarm via network 112 and / or execute corrective actions. For example, security logic 102 can disable the affected ECU 101, restrict the affected ECU 101 from transmitting data frames, modify the data frames transmitted by the affected ECU 101, and / or replace the affected ECU 101 with a different ECU 101.

[0035] Figure 3 The diagram shows the detection pair. Figure 1 The timing diagram 300 is an example of a flood attack on ECU 101. As shown, timing diagram 300 includes a timeline reflecting the flood attack caused by... Figure 1 The timing diagram 300 includes a timeline 301 representing the data frames transmitted by the example ECU 101. The timing diagram 300 further includes a timeline 302 representing the transmission windows of the example ECU 101. In timeline 302, solid lines represent “open” transmission windows, where ECU 101 is permitted to transmit data frames, while dashed lines represent “closed” transmission windows, where ECU 101 is not permitted to transmit data frames via network 112. Open and / or closed windows may be based on a timing window associated with the message ID of each ECU 101 and / or the data frame to be transmitted by ECU 101.

[0036] As shown in the figure, windows 320, 321, 322, 323, and 324 correspond to the transmission windows opened on timeline 302. Furthermore, timeline 330 can define transmission intervals based on points 331-335, such as a first transmission interval between points 331 and 332, a second transmission interval between points 332 and 333, and so on. As stated, ECU 101 can be expected to transmit a single data frame during the transmission interval. Otherwise, ECU 101 may be vulnerable to hang-up attacks.

[0037] Therefore, as shown in the figure, when ECU 101 transmits data frame 303 during window 320, security logic 102 determines that ECU 101 is not under a suspending attack. Similarly, when ECU 101 transmits data frame 304 during window 321, security logic 102 determines that ECU 101 is not under a suspending attack. Data frame 305 can be transmitted by a different ECU 101. Therefore, to avoid collisions, security logic 102 can delay the transmission of data frame 306 by ECU 101. Doing so prevents ECU 101 from transmitting data frames during the transmission interval defined by points 332 and 333. However, advantageously, security logic 102 does not detect suspending attacks on ECU 101 based on the delay introduced by a collision with data frame 305.

[0038] As shown in the figure, ECU 101 does not transmit any additional data frames. Therefore, when transmission window 323 is closed, security logic 102 can determine that ECU 101 is under a suspending attack. Additionally and / or alternatively, when transmission window 324 is closed and ECU 101 does not transmit data frames, security logic 102 can determine that ECU 101 is under a suspending attack. Additionally and / or alternatively, when the transmission interval defined by points 334 and 335 has elapsed and ECU 101 has not transmitted data frames, security logic 102 can determine that ECU 101 is under a suspending attack. If security logic 102 determines that ECU 101 is under a suspending attack, security logic 102 can generate an alarm and transmit the alarm via network 112 and / or execute corrective actions. For example, security logic 102 can disable the affected ECU 101, restrict the affected ECU 101 from transmitting data frames, modify the data frames transmitted by the affected ECU 101, and / or replace the affected ECU 101 with a different ECU 101.

[0039] Figure 4AThis is a schematic diagram 400 reflecting a “centralized” approach, where ECU 101 does not include an instance of security logic 102 and / or where an instance of security logic 102 is not configured between ECU 101 and network 112. Instead, as shown, a single instance of security logic 102-5 is coupled to network 112. As stated, security logic 102-5 may be ECU 101. As shown, security logic 102-5 may include fingerprinting logic 401, cancellation logic 402, and / or any other associated security features. Although depicted as a component of security logic 102-5, in other embodiments, fingerprinting logic 401 and / or cancellation logic 402 may be separate from security logic 102-5. Fingerprinting logic 401 may analyze the voltage of any data frame (or message, or any other type of communication) transmitted by ECU 101 via network 112 (such as the depicted data frame 403 transmitted by ECU 101-1). Additionally and / or alternatively, the fingerprint recognition logic 401 may measure other attributes of the data frame 403, such as timing information, clock offset, current, etc.

[0040] For example, fingerprinting logic 401 can determine that the voltage of data frame 403 is 3.0 volts. However, fingerprinting logic 401 can store one or more known voltage feature profiles for each ECU 101, which may include the voltage (and / or voltage range) of each ECU 101. Therefore, for example, if the known voltage feature profile of ECU 101-1 is 3.3-3.4 volts, there is a voltage mismatch, and fingerprinting logic 401 can determine that ECU 101-1 is subject to flooding and / or hang-up attacks. For example, if data frame 403 is the only data frame transmitted during a transmission interval and / or an open transmission window, fingerprinting logic 401 can determine that ECU 101-1 is subject to a hang-up attack. As another example, if data frame 403 is one of multiple data frames sent by ECU 101-1 during a transmission interval and / or an open transmission window, fingerprinting logic 401 can determine that ECU 101-1 is under flooding attack, even if one of the multiple data frames has a voltage fingerprint of 3.3 volts (and is therefore a trustworthy data frame). Fingerprinting logic 401 can determine the appropriate voltage characteristic based on the message ID included in a given message, and determine the voltage characteristic associated with the ECU 101 corresponding to the message ID.

[0041] The cancellation logic 402 can therefore cancel data frame 403 or any other malicious traffic on network 112. To this end, the cancellation logic 402 can modify data frame 403 by injecting errors to invalidate it, causing it to be rejected by other ECUs 101. For example, the cancellation logic 402 can inject random bits into the cyclic redundancy check (CRC) portion of data frame 403. Additionally and / or alternatively, the cancellation logic 402 can inject random bits into the payload of data frame 403. Additionally and / or alternatively, the cancellation logic 402 can inject random bits into any field of data frame 403. Doing so may cause any ECU 101 using the modified data frame 403 to reject it as invalid.

[0042] In some embodiments, security logic 102 may typically analyze the message ID and voltage fingerprint of each data frame transmitted by ECU 101. If the message ID of a data frame does not include the message ID assigned to the corresponding ECU 101, cancellation logic 402 may modify the data frame to invalidate it. For example, if data frame 403 has message ID 1000, and the voltage characteristics of ECU 101-1 are not associated with message ID value 1000, cancellation logic 402 may invalidate data frame 403.

[0043] Figure 4B An example technique for providing centralized suspend detection for system 400 according to one embodiment is illustrated. As shown, timeline 417 may reflect trusted traffic transmitted by one or more ECUs 101, such as messages 411, 412, 413, and 414. Timeline 418 may reflect suspended messages (depicted in dashed lines), which may be determined by security logic 102-5 according to the techniques described herein. For example, as shown, an attacker may inject malicious messages 415 and / or 416, as represented by the shaded messages in timeline 419. However, security logic 102-5 may determine that messages 415 and / or 416 were sent by the ECU 101 subjected to the suspend attack. Advantageously, security logic 102-5 may cancel out messages 415 and 416, as reflected by the shaded messages in timeline 419, so that messages 415 and 416 are not used by other ECUs 101. Furthermore, as reflected in timeline 418, security logic 102-5 may grant permission for trusted messages, such as message 411 and other trusted messages from timeline 417, to pass through network 112.

[0044] Figure 4CAn example technique for providing centralized flood detection for system 400 according to one embodiment is illustrated. As shown, timeline 421 may reflect trusted traffic, such as messages 431-432, transmitted by one or more ECUs 101. Timeline 422 may reflect multiple flood messages 425, which may be determined by security logic 102-5 according to the techniques described herein. As shown, flood message 425 is marked with example message ID "0", which gives flood message 425 a higher relative priority than trusted messages. For example, as reflected in timeline 422, message 432 has message ID 5, giving priority to flood message 425 transmitted before message 432. Advantageously, security logic 102-5 may cancel flood message 425, as reflected by the shading in timeline 423, so that message 425 is not used by other ECUs 101. Furthermore, as reflected in timeline 422, security logic 102-5 may authorize trusted messages, such as messages 431-432 and other trusted messages from timeline 421, to pass through network 112 in the appropriate order.

[0045] Figure 5A This is a schematic diagram 500 depicting an example of modifying a malicious data frame and replacing the affected ECU with a spare ECU according to one embodiment. Figure 5A As shown, ECU 101-3 is, for example, a backup (or replacement) ECU for ECU 101-1. When acting as a backup ECU, ECU 101-3 can generally operate like ECU 101-1, but does not transmit data via network 112. Furthermore, ECU 101-3 can use data frames generated by ECU 101-1 during operation. This allows ECU 101-3 to learn and / or analyze the behavior of ECU 101-1, enabling a general-purpose ECU to learn to operate as a specific ECU.

[0046] ECU 101-1 can transmit data frame 501 via network 112. Safety logic 102-3 of ECU 101-3 can analyze the first portion 502 of data frame 501 to determine what operating parameters of the autonomous vehicle the data frame 501 intends to modify. For example, ECU 101-1 may be a brake controller, and portion 502 of data frame 501 may specify full brake release. However, safety logic 102-3 can determine the current state of the autonomous vehicle and determine that brake release is outside the expected range of brake operating states. For example, one or more sensor ECUs 101 may indicate an obstacle in the autonomous vehicle's path. In this case, the current state of the system requires at least partial brake application to avoid a collision. However, by releasing the brake, a collision may occur. Therefore, safety logic 102-3 can determine to counteract data frame 501 to protect safety. Advantageously, as stated, by operating at a low level of the network stack, safety logic 102-3 is able to analyze the first portion 502 of data frame 501 before receiving the entire data frame 501. This allows security logic 102-3 to offset data frame 501 earlier than conventional network stack solutions.

[0047] As another example, the first part 502 of data frame 501 may specify that the autonomous vehicle accelerates to 80 mph. However, safety logic 102-3 may determine that the vehicle is currently traveling at 25 mph on a city street with a speed limit of 25 mph. Based on the current state of the autonomous vehicle, accelerating to 80 mph would be outside the expected speed range (e.g., 20-25 mph) and would pose a safety risk. Therefore, safety logic 102-3 may determine to counteract data frame 501 to protect safety.

[0048] Figure 5B An embodiment is depicted in which the cancellation logic 402 modifies the second portion 503 of data frame 501 to prevent data frame 501 from being used and / or implemented by target ECU 101. For example, by injecting random bits into the second portion 503, target ECU 101 will not cause the data frame instructions to be implemented in the autonomous vehicle. The second portion 503 of the data frame can be any portion 503 of the data frame. Continuing with the example of applying brakes to avoid a collision, therefore, one or more ECUs 101, including the brake subsystem, will not cause the brakes to be released. This avoids a collision.

[0049] Furthermore, as shown in the figure, based on the detected malicious data frame 501, ECU 101-1 can be taken offline or otherwise removed from operation in the autonomous vehicle. A backup ECU 101-3 can then be brought online to replace ECU 101-1. In some embodiments, the backup ECU 101-3 can generate and transmit valid data frames based on the current state of the autonomous vehicle. For example, ECU 103-1 can generate a data frame specifying the application of brakes to avoid collisions with obstacles.

[0050] Although depicted as a component of ECU 101-3, safety logic 102-3 may be in a different ECU 101-S (not depicted), which is an ECU dedicated to safety functions. Therefore, such an ECU 101-S may include instances of safety logic 102, fingerprint recognition logic 401, cancellation logic 402, and / or any other relevant safety features. In such an example, ECU 101-S and its components may determine that ECU 101-1 is damaged and communicate with a backup ECU 101-3 (e.g., via network 112 and / or sideband bus) to bring the backup ECU 101-3 online to replace ECU 101-1. Furthermore, although depicted as a component of safety logic 102-3, cancellation logic 402 may be separate from safety logic 102-3 in other embodiments.

[0051] Although reference Figures 5A-5B Security logic 102-3 has been discussed, but any instance of security logic 102 can analyze data frames, cancel invalid data frames, and / or replace a corrupted ECU with a backup ECU. Furthermore, in embodiments where network 112 is CAN, ECU 101 and / or security logic 102 can utilize the CAN protocol to implement additional logic, as the conventional CAN protocol requires analysis of the entire data frame (also called the frame) before taking corrective action. However, doing so would result in another ECU using the given data frame to implement the instructions carried in the data frame (e.g., releasing the brakes). Additionally and / or alternatively, this technique can modify the network protocol (e.g., modify the CAN bus standard) to achieve enhanced functionality and / or performance. By using the strategies described herein, the embodiments disclosed herein can improve the performance of autonomous vehicles by causing malicious instructions to be ignored and / or rejected.

[0052] The operation of the disclosed embodiments can be further described with reference to the following figures. Some of the figures may include logical flows. Although such figures presented herein may include specific logical flows, it will be appreciated that these logical flows merely provide examples of how the general functionality described herein can be implemented. Furthermore, unless otherwise indicated, the given logical flows do not necessarily have to be executed in the order presented. Moreover, the given logical flows may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. The embodiments are not limited to this context.

[0053] Figure 6 An embodiment of logic flow 600 is illustrated. Logic flow 600 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, logic flow 600 may represent some or all of the operations in a centralized mode performed by security logic 102 to detect flood attacks. The embodiments are not limited to this context.

[0054] As shown in the figure, logic flow 600 begins at block 610, where security logic 102, coupled to (or included in) ECU 101, receives a request from the ECU to transmit a first data frame via network 112. For example, ECU 101-1 may attempt to transmit the first data frame, and security logic 102-1 may arbitrate access to network 112. At block 620, security logic 102-1 determines whether a transmission window for ECU 101-1 is currently open. In at least one embodiment, security logic 102-1 includes information specifying a timing window for each ECU 101-1 to 101-N. In some embodiments, security logic 102-1 determines whether a window for ECU 101-1 is open based on a message ID included in the data frame. If the window is not open, logic flow 600 proceeds to block 670, where security logic 102-1 restricts the transmission of the data frame. Safety logic 102-1 can further generate alarms and / or take corrective actions, such as taking ECU 101-1 offline, replacing ECU 101-1 with a spare ECU, etc.

[0055] Returning to box 620, if the window is open, logic flow 600 proceeds to box 630, where safety logic 102-1 determines the total number of data frames transmitted by requesting ECU 101-1 during the current transmission interval. Safety logic 102-1 typically maintains a counter indicating how many data frames are transmitted by ECU 101-1 during the transmission interval and resets the counter at the end of each transmission interval. At box 640, safety logic 102-1 determines whether the total count of data frames determined in box 630 is greater than or equal to 1. If the total count is not greater than or equal to 1 (e.g., zero), logic flow 600 proceeds to box 660, where safety logic 102-1 permits the transmission of the first data frame via network 112. However, if a collision is to occur on network 112, safety logic 102-1 may delay the transmission of the first data frame via network 112.

[0056] Returning to box 640, if the total number of data frames transmitted by ECU 101-1 is greater than or equal to 1, then logic flow 600 proceeds to box 650, where safety logic 102-1 determines whether an exception is satisfied. As stated, ECU 101 is limited to a single transmission during the transmission interval, except for exceptions. Exceptions may include a previous transmission being delayed due to a collision, which pushes the previous transmission to the current transmission interval. If the exception is satisfied, the logic flow proceeds to box 660, where transmission is permitted. Otherwise, the logic flow proceeds to box 670, where transmission is restricted.

[0057] Figure 7 An embodiment of logic flow 700 is illustrated. Logic flow 700 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 700 may represent some or all of the operations performed by security logic 102 in detecting a hangup attack in a distributed mode. The embodiments are not limited to this context.

[0058] As shown in the figure, logic flow 700 begins at block 710, where security logic 102 identifies the start of a transmission interval for ECU 101. For example, security logic 102-1 may determine that a transmission interval for ECU 101-1 has been opened based on the message ID associated with ECU 101-1. At block 720, security logic 102-1 identifies the end of a transmission interval for ECU 101-1. At block 730, security logic 102-1 determines that ECU 101-1 did not transmit data during the transmission interval. At block 740, security logic 102-1 determines that ECU 101-1 is under a suspending attack. At block 750, security logic 102-1 generates an alert indicating that ECU 101-1 is under a suspending attack and transmits the alert via network 112. Additionally and / or alternatively, security logic 102-1 may perform corrective actions such as by disabling ECU 101-1 and / or replacing ECU 101-1 with a spare ECU 101-2.

[0059] Figure 8 An embodiment of logic flow 800 is illustrated. Logic flow 800 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, logic flow 800 may be representative of some or all of the operations performed by security logic 102 in detecting attacks in a centralized mode. The embodiments are not limited to this context.

[0060] As shown in the figure, logic flow 800 begins at block 810, where centralized ECU 101-5 determines the voltage fingerprint of a data frame received from ECU 101-1 via network 112. At block 820, security logic 102-5 determines whether one or more voltage levels of the data frame are not equal to one or more voltage characteristics of ECU 101-1. Voltage characteristics may be known voltage characteristics associated with ECU 101-1 and / or voltage ranges associated with ECU 101-1. At block 830, security logic 102-5 may modify the data frame based on the determination that the voltage of the data frame is not equal to the voltage characteristics of ECU 101-1. For example, security logic 102-5 may modify one or more bits of the data frame to cause the data frame to be corrupted. For example, security logic 102-5 may modify the payload, CRC, and / or any portion of the data frame to corrupt the data frame. At block 840, security logic 102-5 may determine the type of attack based on the timing of the data frame. For example, if the data frame is the only data frame sent by ECU 101-1 during the current transmission interval, security logic 102-5 can determine that ECU 101-1 is under a hangup attack. Additionally and / or alternatively, if multiple data frames have been sent by ECU 101-1 during the current transmission interval, security logic 102-5 can determine that ECU 101-1 is under a flooding attack. In block 850, security logic 102-5 can generate and transmit an alert specifying the determined attack type on network 112. Security logic 102-5 can further perform corrective actions, such as disabling ECU 101-1, preventing ECU 101-1 from transmitting data via network 112, replacing ECU 101-1 with a backup ECU 101-2, etc.

[0061] Figure 9 An embodiment of logic flow 900 is illustrated. Logic flow 900 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, logic flow 900 may be representative of some or all of the operations performed for modifying a message and running a correction action. The embodiments are not limited to this context.

[0062] As shown in the figure, in block 910, an instance of safety logic 102 may receive data frames transmitted by a first ECU 101 (such as ECU 101-1). Safety logic 102 may be in a centralized mode (e.g., safety logic 102-5) and / or in a distributed mode (e.g., safety logic 102-1). Typically, in block 910, safety logic 102 may analyze a first portion of the data frame transmitted by the first ECU 101-1. In block 920, safety logic 102 determines that the first portion of the data frame specifies modifying the operating parameters of the autonomous vehicle to have specified values. For example, the first portion of the payload may specify causing the autonomous vehicle to travel at 50 miles per hour and / or applying brakes.

[0063] In block 930, safety logic 102 determines that a specified value is outside the expected range of operating parameters based on the current operating state of the autonomous vehicle. For example, if the autonomous vehicle is currently idling at a red stop light, safety logic 102 can expect the autonomous vehicle to remain stationary (or below 1 mph) until the light turns green. Therefore, accelerating to 50 mph may be outside the expected range. In block 940, safety logic 102 can modify a second portion of the payload of a data frame. Doing so causes other ECUs 101 using the data frame to reject it. Doing so also causes other ECUs 101 to inhibit the autonomous vehicle from having the specified parameters (e.g., traveling at 50 mph). In block 950, safety logic 102 can take ECU 101-1 offline or otherwise disable ECU 101-1 and bring a backup ECU 101-2 online to replace ECU 101-1. In block 960, the now-online backup ECU 101-2 transmits a new data frame to replace the data frame sent by the first ECU 101-1. For example, a new data frame could specify maintaining the current idling state of the autonomous vehicle because the traffic light remains red.

[0064] Figure 10 An embodiment of storage medium 1000 is illustrated. Storage medium 1000 may include any non-transitory computer-readable or machine-readable storage medium, such as optical, magnetic, or semiconductor storage media. In various embodiments, storage medium 1000 may include article of manufacture. In some embodiments, storage medium 1000 may store computer-executable instructions, such as computer-executable instructions that implement one or more of the logical flows or operations described herein, such as instructions 1001 for security logic 102, instructions 1002 for fingerprint recognition logic 401, and instructions 1003 for cancellation logic 402. Similarly, storage medium 1000 may store instructions for respectively... Figure 6-9The logical flow of computer-executable instructions 1004-1007 is described in 600, 700, 800, and 900. Examples of computer-readable or machine-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and so on. 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 so on. The embodiments are not limited to this context.

[0065] Figure 11 An embodiment of an exemplary computing architecture 1100 including a computing system 1102 is illustrated, which may be adapted to implement the various embodiments described above. In various embodiments, the computing architecture 1100 may include or be implemented as part of an electronic device. In some embodiments, the computing architecture 1100 may be representative of a system, for example, implementing one or more components of system 100. In some embodiments, the computing system 1102 may be representative of, for example, ECU 101 or security logic 102 of system 100 or 400. The embodiments are not limited to this context. More generally, the computing architecture 1100 is configured to implement the references herein. Figure 1-10 All logic, applications, systems, methods, devices, and functionalities described.

[0066] As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, or hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 1100. For example, a component can be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. As an illustration, both an application running on a server and the server itself can be components. One or more components can reside within an executing process and / or thread, and components can be located on a single computer and / or distributed across two or more computers. Furthermore, components can communicatively couple with each other to coordinate their operation via various types of communication media. Coordination can involve one-way or two-way exchange of information. For example, components can transmit information in the form of signals transmitted via communication media. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, alternative embodiments may employ data messages. Such data messages can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and network interfaces.

[0067] The computing system 1102 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, and so on. However, embodiments are not limited to those implemented by the computing system 1102.

[0068] like Figure 11 As shown, computing system 1102 includes processor 1104, system memory 1106, and system bus 1108. Processor 1104 can be any of a variety of commercially available computer processors, including but not limited to AMD® Athlon®, Duron®, and Opteron® processors; ARM® application, embedded, and security processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core®, Core(2)Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual-microprocessor, multi-core processor, and other multiprocessor architectures may also be used as processor 1104.

[0069] System bus 1108 provides interfaces for system components, including but not limited to system memory 1106 to processor 1104. System bus 1108 can be any of several types of bus architectures, which can be further interconnected to local buses, peripheral buses, and memory buses (with or without a memory controller) using any of a variety of commercially available bus architectures. In one embodiment, network 112 is bus 1108. Interface adapters can be connected to system bus 1108 via slot architectures. Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, PCMCIA, and so on.

[0070] System memory 1106 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash memory arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon oxide silicon oxynitride (SONOS) memory, magnetic cards or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB storage, solid-state drives (SSDs), and any other type of storage media suitable for storing information. Figure 11 In the illustrated embodiment, system memory 1106 may include non-volatile memory 1110 and / or volatile memory 1112. The basic input / output system (BIOS) may be stored in non-volatile memory 1110.

[0071] The computing system 1102 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 1114, a floppy disk drive (FDD) 1116 for reading from or writing to a removable disk 1118, and an optical disk drive 1120 for reading from or writing to a removable optical disk 1122 (e.g., a CD-ROM or DVD). The HDD 1114, FDD 1116, and optical disk drive 1120 can be connected to the system bus 1108 via an HDD interface 1124, an FDD interface 1126, and an optical drive interface 1128, respectively. The HDD interface 1124 for external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 1102 is generally configured to implement the references herein. Figure 1-10 All logic, systems, methods, devices, and functionalities described.

[0072] Drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, multiple program modules, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136, can be stored in drive and memory units 1110, 1112. In one embodiment, one or more application programs 1132, other program modules 1134, and program data 1136 can include, for example, various applications and / or components of system 100, such as security logic 102.

[0073] Users can input commands and information into the computing system 1102 via one or more wired / wireless input devices (e.g., keyboard 1138) and pointing devices (e.g., mouse 1140). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, etc. These and other input devices are often connected to the processor 1104 via input device interface 1142 coupled to the system bus 1108, but can also be connected via other interfaces (e.g., parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc.).

[0074] Monitor 1144 or other types of display devices are also connected to system bus 1108 via an interface (such as video adapter 1146). Monitor 1144 can be internal or external to computing system 1102. In addition to monitor 1144, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0075] Computing system 1102 can operate in a networked environment using logical connections to one or more remote computers (such as remote computer 1148) via wired and / or wireless communications. Remote computer 1148 may be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computing system 1102, although for simplicity, only memory / storage device 1150 is illustrated. The depicted logical connections include wired / wireless connectivity to a local area network (LAN) 1152 and / or a larger network (e.g., a wide area network (WAN) 1154). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks (such as intranets), all of which can be connected to global communication networks, such as the Internet.

[0076] When used in a LAN networking environment, computing system 1102 is connected to LAN 1152 via a wired and / or wireless communication network interface or adapter 1156. Adapter 1156 facilitates wired and / or wireless communication to LAN 1152, which may also include a wireless access point disposed thereon for wireless functional communication with adapter 1156.

[0077] When used in a WAN networking environment, computing system 1102 may include modem 1158, or a communication server connected to WAN 1154, or other components for establishing communication via WAN 1154 (e.g., via the Internet). Modem 1158 (which may be internal or external and wired and / or wireless) is connected to system bus 1108 via input device interface 1142. In a networking environment, program modules depicted relative to computing system 1102 or parts thereof may be stored in remote memory / storage device 1150. It will be appreciated that the network connections shown are exemplary and other components for establishing communication links between computers may be used.

[0078] The computing system 1102 is operable to communicate with wired and wireless devices or entities (such as wireless devices operatively arranged in wireless communication (e.g., IEEE 802.16 air modulation technology)) using IEEE 802 series standards. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, as well as others. Thus, communication can be a predefined structure like a conventional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 related media and functions).

[0079] One or more aspects of at least one example can be implemented by representative instructions stored on at least one machine-readable medium representing various logic within a processor, which, when read by a machine, computing device, or system, cause that machine, computing device, or system to produce logic that performs the techniques described herein. Such a representation, referred to as an "IP core," can be stored on a tangible, machine-readable medium and provided to various customers or manufacturing facilities for loading into manufacturing machines that produce logic or processors.

[0080] Various examples can be implemented using hardware components, software components, or a combination of both. In some examples, hardware components may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chipsets, microchips, chipsets, etc. In some examples, software components may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination of whether to use hardware and / or software components to implement the example can vary depending on any number of factors, such as desired computing speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints as desired for a given implementation.

[0081] Some examples may include an article of writing or at least one computer-readable medium. A computer-readable medium may include a non-transitory storage medium that stores logic. In some examples, a non-transitory storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. In some examples, logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0082] According to some examples, a computer-readable medium may include a non-transitory storage medium that stores or maintains instructions that, when executed by a machine, computing device, or system, cause the machine, computing device, or system to perform methods and / or operations according to the described examples. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. The instructions may be implemented according to a predefined computer language, mode, or syntax for instructing a machine, computing device, or system to perform a function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0083] Examples may be described using the expressions "in one example" or "example" along with their derivatives. These terms mean that a particular feature, structure, or property described in connection with the example is included in at least one example. The appearance of the phrase "in one example" in various places in the specification does not necessarily refer to the same example.

[0084] Examples can be described using the expressions “coupled” and “connected” along with their derivatives. These terms are not necessarily intended to be synonyms with each other. For example, a description using the terms “connected” and / or “coupled” may indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0085] The following examples relate to further embodiments from which many substitutions and configurations will become apparent.

[0086] Example 1 is an autonomous vehicle including: a plurality of electronic control units (ECUs) communicatively coupled via a network, and at least a portion of such logic implemented in hardware for: receiving an instruction from a first ECU of the plurality of ECUs to transmit a first data frame via the network; determining, based on a message identifier (ID) of the first ECU, whether a transmission window of the first ECU is open; and, based on the determination that the transmission window of the first ECU is open, permitting the first ECU to transmit the first data frame via the network.

[0087] Example 2 includes the subject matter of Example 1, wherein the logic is further configured to: determine that a second ECU of a plurality of ECUs will transmit a data frame via a network during a transmission window of the first ECU; delay the transmission of a first data frame by the first ECU; and permit the first ECU to transmit the first data frame after the second ECU transmits the data frame and during the transmission window of the first ECU, wherein at least a portion of the transmission window is included in a transmission interval for transmitting data via a network.

[0088] Example 3 includes the subject of Example 2, the logic being further configured to: during a transmission interval, receive a second instruction from a first ECU specifying the transmission of a second data frame via a network during a second transmission window, at least a portion of the second transmission window being included in the transmission interval; and based on the determination that the second ECU transmits data via the network during the first ECU's transmission window, permit the first ECU to transmit the second data frame during a portion of the second transmission window included in the transmission interval.

[0089] Example 4 includes the subject of Example 1, and the logic is further configured to: determine, based on the message ID of the first ECU, whether the transmission interval of the first ECU has been opened and closed; determine that the first ECU has not transmitted data during the transmission interval; determine that the first ECU is under a suspend attack; and generate an alarm specifying that the first ECU is under a suspend attack.

[0090] Example 5 includes the subject of Example 1, and the logic is further configured to: determine a voltage fingerprint of a first data frame; determine that the voltage fingerprint is not equal to a voltage characteristic of a first ECU; and modify at least a portion of the first data frame based on the determination that the voltage fingerprint is not equal to the voltage characteristic of the first ECU.

[0091] Example 6 includes the subject of Example 5, wherein one or more of the cyclic redundancy check portion of the first data frame or the payload of the first data frame are to be modified to cause other ECUs to reject the first data frame, wherein the network includes a controller area network (CAN).

[0092] Example 7 includes the subject matter of Example 1, and further includes a backup ECU of a plurality of ECUs, the backup ECU being configured to: analyze a first portion of the payload of a first data frame; determine that the first portion of the payload specifies that the operating parameters of the autonomous vehicle be modified to a specified value; determine, based on the current state of the autonomous vehicle, that the specified value is outside the expected range of the operating parameters; and modify a second portion of the payload of the first data frame so that the other ECUs suppress the operating parameters of the autonomous vehicle from having the specified value.

[0093] Example 8 includes the subject of Example 7, wherein the backup ECU is further configured to: restrict the operation of the first ECU in the autonomous vehicle; and operate as the first ECU in the autonomous vehicle.

[0094] Example 9 is a device comprising: a plurality of electronic control units (ECUs) of an autonomous vehicle communicatively coupled via a network, and at least a portion thereof logic implemented in hardware for: receiving an instruction from a first ECU of the plurality of ECUs to transmit a first data frame via the network; determining, based on a message identifier (ID) of the first ECU, whether a transmission window of the first ECU is open; and, based on the determination that the transmission window of the first ECU is open, permitting the first ECU to transmit the first data frame via the network.

[0095] Example 10 includes the subject matter of Example 9, wherein the logic is further configured to: determine that a second ECU of a plurality of ECUs will transmit a data frame via a network during a transmission window of the first ECU; delay the transmission of the first data frame by the first ECU; and permit the first ECU to transmit the first data frame after the second ECU transmits the data frame and during the transmission window of the first ECU, wherein at least a portion of the transmission window is included in a transmission interval for transmitting data via a network.

[0096] Example 11 includes the subject of Example 10, the logic being further configured to: during a transmission interval, receive a second instruction from a first ECU specifying the transmission of a second data frame via a network during a second transmission window, at least a portion of the second transmission window being included in the transmission interval; and based on a determination that the second ECU transmits data via the network during the first ECU's transmission window, permit the first ECU to transmit the second data frame during a portion of the second transmission window included in the transmission interval.

[0097] Example 12 includes the subject of Example 9, and the logic is further configured to: determine, based on the message ID of the first ECU, that the transmission interval of the first ECU has been opened and closed; determine that the first ECU has not attempted to transmit data during the transmission interval; determine that the first ECU is under a suspend attack; and generate an alarm specifying that the first ECU is under a suspend attack.

[0098] Example 13 includes the subject of Example 9, and the logic is further configured to: determine a voltage fingerprint of a first data frame; determine that the voltage fingerprint is not equal to the voltage characteristics of a first ECU; and modify at least a portion of the first data frame based on the determination that the voltage fingerprint is not equal to the voltage characteristics of the first ECU.

[0099] Example 14 includes the subject of Example 13, wherein one or more of the cyclic redundancy check portion of the first data frame or the payload of the first data frame are to be modified to cause other ECUs to reject the first data frame, wherein the network includes a controller area network (CAN).

[0100] Example 15 includes the subject matter of Example 9, and further includes a backup ECU of a plurality of ECUs, the backup ECU being configured to: analyze a first portion of the payload of a first data frame; determine that the first portion of the payload specifies that the operating parameters of the autonomous vehicle be modified to a specified value; determine, based on the current state of the autonomous vehicle, that the specified value is outside the expected range of the operating parameters; and modify a second portion of the payload of the first data frame such that the other ECUs suppress the autonomous vehicle's operating parameters from having the specified value.

[0101] Example 16 includes the subject matter of Example 15, wherein the backup ECU is further configured to: restrict the operation of the first ECU in the autonomous vehicle; and operate as the first ECU in the autonomous vehicle.

[0102] Example 17 is a method comprising: receiving, by logic at least partially implemented in hardware, an instruction from a first ECU among a plurality of electronic control units (ECUs) to transmit a first data frame via a network of an autonomous vehicle; determining, by logic, whether a transmission window of the first ECU is open based on a message identifier (ID) of the first ECU; and, by logic, permitting the first ECU to transmit the first data frame via the network based on the determination that the transmission window of the first ECU is open.

[0103] Example 18 includes the subject matter of Example 17, further comprising: determining by logic that a second ECU of a plurality of ECUs will transmit a data frame via a network during a transmission window of the first ECU; delaying by logic the transmission of a first data frame by the first ECU; and allowing by logic the first ECU to transmit the first data frame after the second ECU transmits the data frame and during the transmission window of the first ECU, at least a portion of the transmission window being included in a transmission interval for transmitting data via a network.

[0104] Example 19 includes the subject matter of Example 18, further comprising: during a transmission interval, receiving by logic a second instruction from a first ECU specifying the transmission of a second data frame via a network during a second transmission window, at least a portion of the second transmission window being included in the transmission interval; and by logic, based on a determination that the second ECU transmits data via the network during the transmission window of the first ECU, permitting the first ECU to transmit the second data frame during a portion of the second transmission window included in the transmission interval.

[0105] Example 20 includes the subject of Example 17, and further includes: determining, by logic, that a transmission interval of the first ECU has elapsed based on the message ID of the first ECU; determining, by logic, that the first ECU did not transmit data during a second transmission interval; determining, by logic, that the first ECU is under a hangup attack; and generating, by logic, an alarm specifying that the first ECU is under a hangup attack.

[0106] Example 21 includes the subject matter of Example 20, and further includes: determining a voltage fingerprint of a first data frame by logic; determining by logic that the voltage fingerprint is not equal to a voltage characteristic of a first ECU; and modifying at least a portion of the first data frame by logic based on the determination that the voltage fingerprint is not equal to a voltage characteristic of the first ECU.

[0107] Example 22 includes the subject matter of Example 21, wherein the at least portion of the first data frame includes a cyclic redundancy check portion of the first data frame or the payload of the first data frame, wherein the network includes a controller local area network (CAN).

[0108] Example 23 includes the subject matter of Example 17, and further includes: analyzing a first portion of the payload of a first data frame by logic; determining by logic that the first portion of the payload specifies that the operating parameters of the autonomous vehicle should be modified to a specified value; determining by logic, based on the current state of the autonomous vehicle, that the specified value is outside the expected range of the operating parameters; and modifying by logic a second portion of the payload of the first data frame so that other ECUs inhibit the autonomous vehicle's operating parameters from having the specified value.

[0109] Example 24 includes the subject matter of Example 17, and further includes: restricting the operation of a first ECU in an autonomous vehicle; and enabling a backup ECU of a plurality of ECUs to operate as the first ECU in an autonomous vehicle.

[0110] Example 25 is an apparatus comprising: components for communicatively coupled via a network of multiple electronic control units (ECUs) of an autonomous vehicle; components for receiving an instruction from a first ECU of the plurality of ECUs to transmit a first data frame via the network; components for determining, based on a message identifier (ID) of the first ECU, whether a transmission window of the first ECU is open; and components for permitting the first ECU to transmit the first data frame via the network based on the determination that the transmission window of the first ECU is open.

[0111] Example 26 includes the subject matter of Example 25, further including: means for determining that a second ECU of a plurality of ECUs will transmit a data frame via a network during a transmission window of the first ECU; means for delaying the transmission of a first data frame by the first ECU; and means for allowing the first ECU to transmit the first data frame after the second ECU transmits the data frame and during the transmission window of the first ECU, at least a portion of the transmission window being included in a transmission interval for transmitting data via a network.

[0112] Example 27 includes the subject matter of Example 26, further comprising: means for receiving, during a transmission interval, a second instruction from a first ECU specifying the transmission of a second data frame via a network during a second transmission window, at least a portion of the second transmission window being included in the transmission interval; and means for, based on a determination by the second ECU that the first ECU transmits data via the network during the transmission window of the first ECU, permitting the first ECU to transmit the second data frame during a portion of the second transmission window included in the transmission interval.

[0113] Example 28 includes the subject matter of Example 25, and further includes: components for determining that a transmission interval of the first ECU has elapsed based on the message ID of the first ECU; components for determining that the first ECU did not attempt to transmit data during the transmission interval; components for determining that the first ECU is under a suspending attack; and components for generating an alarm specifying that the first ECU is under a suspending attack.

[0114] Example 29 includes the subject matter of Example 25, and further includes: components for determining a voltage fingerprint of a first data frame; components for determining that the voltage fingerprint is not equal to a voltage characteristic of a first ECU; and components for modifying at least a portion of the first data frame based on the determination that the voltage fingerprint is not equal to a voltage characteristic of the first ECU.

[0115] Example 30 includes the subject of Example 29, wherein one or more of the cyclic redundancy check portion of the first data frame or the payload of the first data frame are to be modified to cause other ECUs to reject the first data frame, wherein the network includes a controller area network (CAN).

[0116] Example 31 includes the subject matter of Example 25, and further includes: components for analyzing a first portion of the payload of a first data frame; components for determining that the first portion of the payload specifies that the operating parameters of the autonomous vehicle should be modified to a specified value; components for determining, based on the current state of the autonomous vehicle, that the specified value is outside the expected range of the operating parameters; and components for modifying a second portion of the payload of the first data frame so that other ECUs suppress the operation parameters of the autonomous vehicle from having the specified value.

[0117] Example 32 includes the subject matter of Example 31, and further includes: components for restricting the operation of a first ECU in an autonomous vehicle; and components for enabling a backup ECU of a plurality of ECUs to operate as the first ECU in an autonomous vehicle.

[0118] Example 33 is a non-transitory computer-readable storage medium storing instructions that, when executed by processor circuitry, cause the processor circuitry to: receive an instruction from a first electronic control unit (ECU) specifying the transmission of a first data frame via a network, the first ECU being one of a plurality of ECUs communicatively coupled via a network in an autonomous vehicle; determine, based on a message identifier (ID) of the first ECU, whether a transmission window of the first ECU is open; and, based on the determination that the transmission window of the first ECU is open, permit the first ECU to transmit the first data frame via the network.

[0119] Example 34 includes the subject of Example 33, storing instructions that, when executed by processor circuitry, cause the processor circuitry to: determine that a second ECU of a plurality of ECUs is to transmit a data frame via a network during a transmission window of the first ECU; delay the transmission of the first data frame by the first ECU; and permit the first ECU to transmit the first data frame after the second ECU transmits the data frame and during the transmission window of the first ECU, at least a portion of the transmission window being included in a transmission interval for transmitting data via a network.

[0120] Example 35 includes the subject of Example 34, storing instructions that, when executed by processor circuitry, cause the processor circuitry to: during a transmission interval, receive a second instruction from a first ECU specifying the transmission of a second data frame via a network during a second transmission window, at least a portion of which is included in the transmission interval; and, based on a determination that the second ECU transmits data via the network during the first ECU's transmission window, permit the first ECU to transmit the second data frame during a portion of the second transmission window included in the transmission interval.

[0121] Example 36 includes the subject of Example 33, storing instructions that, when executed by the processor circuitry, cause the processor circuitry to: determine, based on the message ID of the first ECU, that the transmission interval of the first ECU has expired; determine that the first ECU did not transmit data during the transmission interval; determine that the first ECU is under a hangup attack; and generate an alarm specifying that the first ECU is under a hangup attack.

[0122] Example 37 includes the subject of Example 33, storing instructions that, when executed by processor circuitry, cause the processor circuitry to: determine a voltage fingerprint of a first data frame; determine a known voltage characteristic that the voltage fingerprint is not equal to that of a first ECU; and modify at least a portion of the first data frame based on the determination that the voltage fingerprint is not equal to the known voltage characteristic of the first ECU.

[0123] Example 38 includes the subject of Example 37, wherein one or more of the cyclic redundancy check portion of the first data frame or the payload of the first data frame are to be modified to cause other ECUs to reject the first data frame, wherein the network includes a controller area network (CAN).

[0124] Example 39 includes the subject of Example 33, storing instructions that, when executed by processor circuitry, cause the processor circuitry to: analyze a first portion of the payload of a first data frame; determine that the first portion of the payload specifies that the operating parameters of the autonomous vehicle be modified to a specified value; determine, based on the current state of the autonomous vehicle, that the specified value is outside the expected range of the operating parameters; and modify a second portion of the payload of the first data frame to cause other ECUs to suppress the autonomous vehicle's operating parameters from having the specified value.

[0125] Example 40 includes the subject of Example 39, storing instructions that, when executed by processor circuitry, cause the processor circuitry to: restrict the operation of a first ECU in an autonomous vehicle; and cause a backup ECU of a plurality of ECUs to operate as the first ECU in the autonomous vehicle.

[0126] Furthermore, in the foregoing, various features are combined in a single example to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention to claim more features than expressly enumerated in each claim. Rather, as reflected in the following claims, the subject matter of the invention lies in fewer features than all of the features in a single disclosed example. Thus, the following claims are thereby incorporated into the detailed description, wherein each claim is an independent, separate example. In the appended claims, the terms “including” and “in which” are used as common English equivalents to the corresponding terms “comprising” and “wherein”, respectively. Furthermore, the terms “first,” “second,” “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0127] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

[0128] A data processing system suitable for storing and / or executing program code will include at least one processor directly or indirectly coupled to memory elements via a system bus. Memory elements may include local memory, mass storage devices, and cache memory used during the actual execution of the program code, providing temporary storage for at least some type of program code to reduce the number of times code must be retrieved from mass storage devices during execution. The term "code" encompasses a broad range of software components and constructs, including applications, drivers, processes, routines, methods, modules, firmware, microcode, and subroutines. Therefore, the term "code" can be used to refer to any set of instructions that, when executed by a processing system, perform one or more desired operations.

[0129] The logic circuit systems, devices, and interfaces described herein can perform functions implemented in hardware and in code executed on one or more processors. A logic circuit system refers to hardware or hardware and code that implements one or more logical functions. A circuit system is hardware and can refer to one or more circuits. Each circuit performs a specific function. The circuitry of a circuit system may include discrete electrical components interconnected with one or more conductors, integrated circuits, chip packages, chipsets, memories, etc. Integrated circuits include circuitry created on a substrate such as a silicon wafer and may include components. Furthermore, integrated circuits, processor packages, chip packages, and chipsets may include one or more processors.

[0130] The processor can receive signals such as instructions and / or data at one or more inputs and process these signals to generate at least one output. During code execution, the code alters the physical states and characteristics of the transistors that make up the processor pipeline. The physical states of the transistors are transformed into logical bits of one and zero stored in registers within the processor. The processor can transfer the physical states of transistors into registers and to another storage medium.

[0131] A processor may include circuitry that performs one or more sub-functions, which are implemented to perform the overall function of the processor. An example of a processor is a state machine or application-specific integrated circuit (ASIC) that includes at least one input and at least one output. A state machine can manipulate at least one input to generate at least one output by performing a predetermined series of serial and / or parallel manipulations or transformations on at least one input.

[0132] The logic described above can be part of the design of an integrated circuit chip. This chip design is created using a graphical computer programming language and stored on a computer storage medium or data storage medium (such as a disk, magnetic tape, physical hard drive, or virtual hard drive such as in a storage access network). If the designer does not fabricate the chip or the photomask used to fabricate it, the designer transmits the obtained design directly or indirectly to such an entity by physical means (e.g., by providing a copy of the storage medium containing the design) or electronically (e.g., via the Internet). The stored design is then converted into a suitable format (e.g., GDSII) for fabrication.

[0133] The resulting integrated circuit chips can be distributed by the manufacturer in the form of raw wafers (i.e., as a single wafer with multiple unpackaged chips), as bare dies, or in packages. In the latter case, the chips are mounted in a single-chip package (such as a plastic carrier, in which leads are attached to a motherboard or other more advanced carrier) or a multi-chip package (such as a ceramic carrier with either surface-mount or buried interconnects, or both). In any case, the chips are then integrated with other chips, discrete circuit elements, and / or other signal processing devices as part of (a) an intermediate product (such as a processor board, server platform, or motherboard) or (b) a final product.

[0134] For purposes of illustration and description, the foregoing description of exemplary embodiments has been given. It is not intended to be exhaustive or to limit this disclosure to the precise forms disclosed. Many modifications and variations are possible based on this disclosure. It is intended that the scope of this disclosure is not limited by this detailed description, but rather by the appended claims. Future applications claiming priority of this application may claim protection for the disclosed subject matter in different ways and may generally include any set of one or more limitations disclosed or otherwise shown herein.

Claims

1. A computing device, comprising: The first interface to the microcontroller; The second interface to the Controller Area Network (CAN); A security circuit communicatively coupled to the first interface and the second interface, the security circuit being used for: Receive a first data frame from the microcontroller through the first interface; Determine whether the microcontroller can transmit the first data frame to the CAN; When the microcontroller is able to transmit the first data frame to the CAN, the first data frame is transmitted to the CAN through the second interface; Receive a second data frame from the microcontroller through the first interface; Determine whether the second data frame is part of a flooding attack; When it is determined that the second data frame is part of the flooding attack, the second data frame is modified to include errors to invalidate the second data frame; as well as The modified second data frame is transmitted to the CAN via the second interface.

2. The device of claim 1, wherein the security circuit is configured to: determine whether the second data frame is part of the flooding attack based on the duration of the second data frame.

3. The device of claim 1, wherein the security circuit is configured to: compare the duration of the second data frame with the duration of the transmission window to determine whether the second data frame is part of the flooding attack.

4. The device of claim 1, wherein the security circuit is configured to: determine whether the second data frame is part of the flooding attack based on when the second data frame is received.

5. The apparatus of claim 1, wherein, The first data frame and the second data frame include a message identifier value, which indicates a higher priority level relative to other data frames in the CAN.

6. The device of claim 1, wherein the security circuit is configured to: isolate the microcontroller from the CAN when it is determined that the second data frame is part of the flooding attack.

7. The device of claim 1, wherein the security circuit is configured to: when it is determined that the second data frame is part of the flooding attack, modify the second data frame to include errors to invalidate the second data frame, thereby causing other microcontrollers in the CAN to reject the second data frame.

8. A calculation method, comprising: Receive the first data frame from the microcontroller through the first interface; Determine whether the microcontroller can transmit the first data frame to the CAN; When the microcontroller is able to transmit the first data frame to the CAN, the first data frame is transmitted to the CAN through the second interface; Receive a second data frame from the microcontroller through the first interface; Determine whether the second data frame is part of a flooding attack; When it is determined that the second data frame is part of the flooding attack, the second data frame is modified to include errors to invalidate the second data frame; as well as The modified second data frame is transmitted to the CAN via the second interface.

9. The method of claim 8, wherein, The determination of whether the second data frame is part of the flooding attack is based on the duration of the second data frame.

10. The method of claim 8, further comprising comparing the duration of the second data frame with the duration of the transmission window to determine whether the second data frame is part of the flooding attack.

11. The method of claim 8, wherein, The determination of whether the second data frame is part of the flooding attack is based on when the second data frame is received.

12. The method according to claim 8, wherein, The first data frame and the second data frame include a message identifier value, which indicates a higher priority level relative to other data frames in the CAN.

13. The method of claim 8, further comprising: When it is determined that the second data frame is part of the flooding attack, the microcontroller is isolated from the CAN.

14. The method of claim 8, further comprising: When it is determined that the second data frame is part of the flooding attack, the second data frame is modified to include errors to invalidate the second data frame, thereby causing other microcontrollers in the CAN to reject the second data frame.

15. A machine-readable medium storing instructions, which, when executed, cause a machine to perform any of the methods of claims 8 to 14.

16. A computing device comprising components for performing the method of any one of claims 8 to 14.

17. A computing system, comprising: microcontroller; Controller Area Network (CAN); A transceiver communicatively coupled to the microcontroller and the CAN bus, the transceiver comprising: To the first interface of the microcontroller, To the second interface of the CAN, and A safety circuit for performing any of the methods of claims 8 to 14.

18. The system according to claim 17, wherein, The microcontroller is part of an electronic control unit (ECU).

19. The system according to claim 17 or 18, wherein, The microcontroller and CAN are part of an in-vehicle network (IVN) for autonomous vehicles.

Images