Patent Application
20250055725
The present disclosure relates generally to controller area network (CAN) communication in a vehicle, and more particularly, to synching CAN databases using remote transmission requests (RTRs) to control CAN communication in a vehicle.
Controller area networks, or CANs, are often utilized in vehicles to implement a robust, relatively inexpensive in-vehicle network connecting several electronic control units (ECUs) in charge of controlling certain vehicle functions, such as climate control, vehicle displays (i.e., clusters), infotainment systems, and the like. A typical CAN utilizes a CAN bus which enables the ECUs in the CAN to communicate with each other without a host computer. The ECUs can send and receive data across the CAN bus in packets called frames.
In this regard,
Problematically, when ECUs transmit CAN data frames across the network, these communications can be vulnerable to hacking due to the open communication channel utilized in CANs. As such, vehicle CANs can be susceptible to intrusions by hackers who may attempt to read and decode the CAN messages by physically connecting to the CAN bus or using on-board (OBD) ports to access the CAN bus. Then, the hacker can decode or reverse engineer the intercepted data. Hackers can also inject messages on the CAN bus which may trigger system malfunction or misbehavior.
According to an object of the present disclosure, a method for controlling controller area network (CAN) communication in a vehicle including a plurality of electronic control units (ECUs) and a plurality of CAN databases accessible by the plurality of ECUs is provided. The method may comprise storing CAN message information in the plurality of CAN databases such that each CAN database stores a unique configuration of the CAN message information, and determining a system mode of operation. The determining the system mode of operation may comprise determining one or more least significant bits (LSBs) of a data length code (DLC), and comparing the one or more LSBs of the DLC against a database to determine the system mode of operation. The method may further comprise generating a remote transmission request (RTR) message. The generating the RTR request may comprise determining one or more most significant bits (MSBs) of the DLC, and adding the one or more MSBs of the DLC to an end of an identifier, generating an RTR request value comprising the identifier and the one or more MSBs of the DLC, wherein the RTR request value is associated with a requested answer value which is associated with the system mode of operation. The method may further comprise communicating the RTR message, through a CAN bus, to the plurality of ECUs, interpreting the RTR request value to determine the requested answer value, generating the requested answer value, and communicating the requested answer value to the plurality of ECUs.
According to an exemplary embodiment, the one or more LSBs of the DLC may comprise two LSBs of the DLC.
According to an exemplary embodiment, the one or more MSBs of the DLC may comprise two MSBs of the DLC.
According to an exemplary embodiment, the answer value may comprise a time value at which each ECU performs CAN communication based upon the uniquely configured CAN message information stored in a particular CAN database among the plurality of CAN databases, and the particular CAN database may be identified by a database reference number.
According to an exemplary embodiment, the method may further comprise, when a subsequent interval among the plurality of periodic intervals begins, receiving a plurality of measurement values deriving from a plurality of sensors equipped in the vehicle, calculating a new database reference number by using the plurality of measurement values and one or more random numbers, the new database reference number newly identifying a particular CAN database among the plurality of CAN databases, and performing CAN communication, by each ECU, based upon the uniquely configured CAN message information stored in the newly identified CAN database.
According to an exemplary embodiment, the answer value may comprise a new data reference number, and the new database reference number may identify a particular CAN database among the plurality of CAN databases.
According to an exemplary embodiment, the method may further comprise designating a particular ECU among the plurality of ECUs as a master ECU to control one or more operations of the method for controlling CAN communication. The remaining ECUs may operate as slave ECUs, and the answer value may comprise a next master identification number.
According to an object of the present disclosure, a system for controlling CAN communication in a vehicle is provided. The system may comprise a plurality of ECUs equipped in the vehicle, a plurality of CAN databases configured to store CAN message information such that each CAN database stores a unique configuration of the CAN message information, a plurality of sensors equipped in the vehicle communicatively coupled to the plurality of ECUs, and a CAN bus through which the plurality of ECUs are configured to perform CAN communication. The plurality of ECUs, in performing the CAN communication, may be configured to determine a system mode of operation comprising determining one or more LSBs of a DLC and comparing the one or more LSBs of the DLC against a database to determine the system mode of operation, generate an RTR message, comprising determining one or more MSBs of the DLC and adding the one or more MSBs of the DLC to an end of an identifier, generating an RTR request value comprising the identifier and the one or more MSBs of the DLC, wherein the RTR request value is associated with a requested answer value which is associated with the system mode of operation, communicate the RTR message, through a CAN bus, to the plurality of ECUs, interpret the RTR request value to determine the requested answer value, generate the requested answer value, and communicate the requested answer value to the plurality of ECUs.
According to an exemplary embodiment, the one or more LSBs of the DLC may comprise two LSBs of the DLC.
According to an exemplary embodiment, the one or more MSBs of the DLC may comprise two MSBs of the DLC.
According to an exemplary embodiment, the answer value may comprise a time value at which each ECU performs CAN communication based upon the uniquely configured CAN message information stored in a particular CAN database among the plurality of CAN databases, and the particular CAN database may be identified by a database reference number.
According to an exemplary embodiment, the plurality of ECUs, when a subsequent interval among the plurality of periodic intervals begins, may be configured to receive a plurality of measurement values deriving from a plurality of sensors equipped in the vehicle, calculate a new database reference number by using the plurality of measurement values and one or more random numbers, the new database reference number newly identifying a particular CAN database among the plurality of CAN databases, and perform CAN communication, by each ECU, based upon the uniquely configured CAN message information stored in the newly identified CAN database.
According to an exemplary embodiment, the answer value may comprise a new data reference number, and the new database reference number may identify a particular CAN database among the plurality of CAN databases.
According to an exemplary embodiment, the plurality of ECUs may be configured to designate a particular ECU among the plurality of ECUs as a master ECU to control one or more operations of the method for controlling CAN communication, the remaining ECUs may be configured to operate as slave ECUs, and the answer value may comprise a next master identification number.
According to an object of the present disclosure, a system for controlling CAN communication in a vehicle is provided. The system may comprise a plurality of ECUs equipped in the vehicle, a plurality of CAN databases configured to store CAN message information such that each CAN database stores a unique configuration of the CAN message information, a plurality of sensors equipped in the vehicle communicatively coupled to the plurality of ECUs, a CAN bus through which the plurality of ECUs are configured to perform CAN communication, and a computing device, comprising a processor and a memory, configured to store programming instructions. The programming instructions, when executed by the processor, may be configured to cause the processor to determine a system mode of operation comprising determining one or more LSBs of a DLC and comparing the one or more LSBs of the DLC against a database to determine the system mode of operation, generate an RTR message, comprising determining one or more MSBs of the DLC and adding the one or more MSBs of the DLC to an end of an identifier, generating an RTR request value comprising the identifier and the one or more MSBs of the DLC, wherein the RTR request value is associated with a requested answer value which is associated with the system mode of operation, communicate the RTR message, through a CAN bus, to the plurality of ECUs, interpret the RTR request value to determine the requested answer value, generate the requested answer value, and communicate the requested answer value to the plurality of ECUs.
According to an exemplary embodiment, the one or more LSBs of the DLC may comprise two LSBs of the DLC.
According to an exemplary embodiment, two MSBs may be added out of a 4-bit DLC to an 11-bit identifier and, together, may form a 13-bit number whose range can extend along a range of possible values. According to an exemplary embodiment, the range of possible values may be from 1 to 8192.
According to an exemplary embodiment, the one or more MSBs of the DLC may comprise two MSBs of the DLC.
According to an exemplary embodiment, the answer value may comprise a time value at which each ECU performs CAN communication based upon the uniquely configured CAN message information stored in a particular CAN database among the plurality of CAN databases, and the particular CAN database may be identified by a database reference number.
According to an exemplary embodiment, the plurality of ECUs, when a subsequent interval among the plurality of periodic intervals begins, may be configured to receive a plurality of measurement values deriving from a plurality of sensors equipped in the vehicle, calculate a new database reference number by using the plurality of measurement values and one or more random numbers, the new database reference number newly identifying a particular CAN database among the plurality of CAN databases, and perform CAN communication, by each ECU, based upon the uniquely configured CAN message information stored in the newly identified CAN database.
According to an exemplary embodiment, the answer value may comprise a new data reference number, and the new database reference number may identify a particular CAN database among the plurality of CAN databases.
According to an exemplary embodiment, the plurality of ECUs may be configured to designate a particular ECU among the plurality of ECUs as a master ECU to control one or more operations of the method for controlling CAN communication, the remaining ECUs may be configured to operate as slave ECUs, and the answer value may comprise a next master identification number.
The accompanying drawings, which are incorporated in and form a part of the Detailed Description, illustrate various non-limiting and non-exhaustive embodiments of the subject matter and, together with the Detailed Description, serve to explain principles of the subject matter discussed below. Unless specifically noted, the drawings referred to in this Brief Description of Drawings should be understood as not being drawn to scale and like reference numerals refer to like parts throughout the various figures unless otherwise specified.
It should be understood that the above-referenced drawings are not necessarily to scale, presenting a somewhat simplified representation of various preferred features illustrative of the basic principles of the disclosure. The specific design features of the present disclosure, including, for example, specific dimensions, orientations, locations, and shapes, will be determined in part by the particular intended application and use environment.
Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present disclosure. Further, throughout the specification, like reference numerals refer to like elements.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
It is understood that the term “vehicle” or “vehicular” or other similar term as used herein is inclusive of motor vehicles in general such as passenger automobiles including sports utility vehicles (SUV), buses, trucks, various commercial vehicles, watercraft including a variety of boats and ships, aircraft, and the like, includes hybrid vehicles, electric vehicles, plug-in hybrid electric vehicles, hydrogen-powered vehicles and other alternative fuel vehicles (e.g., fuels derived from resources other than petroleum), and further includes other “vehicles” such as trains, construction equipment, drones, spacecraft, and any other suitable example thereof. As referred to herein, a hybrid vehicle is a vehicle that has two or more sources of power, for example both gasoline-powered and electric-powered vehicles.
Although exemplary embodiment is described as using a plurality of units to perform the exemplary process, it is understood that the exemplary processes may also be performed by one or plurality of modules. Additionally, it is understood that the term controller/control unit refers to a hardware device that includes a memory and a processor and is specifically programmed to execute the processes described herein. The memory is configured to store the modules and the processor is specifically configured to execute said modules to perform one or more processes which are described further below.
Further, the control logic of the present disclosure may be embodied as non-transitory computer readable media on a computer readable medium containing executable program instructions executed by a processor, controller or the like. Examples of computer readable media include, but are not limited to, ROM, RAM, compact disc (CD)-ROMs, magnetic tapes, floppy disks, flash drives, smart cards and optical data storage devices. The computer readable medium can also be distributed in network coupled computer systems so that the computer readable media is stored and executed in a distributed fashion, e.g., by a telematics server or a Controller Area Network (CAN).
Unless specifically stated or obvious from context, as used herein, the term “about” is understood as within a range of normal tolerance in the art, for example within 2 standard deviations of the mean. “About” can be understood as within 10%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1%, 0.5%, 0.1%, 0.05%, or 0.01% of the stated value. Unless otherwise clear from the context, all numerical values provided herein are modified by the term “about”.
Additionally, it is understood that one or more of the below methods, or aspects thereof, may be executed by at least one control unit (or electronic control unit (ECU)). The at least one control unit or ECU may be implemented in a vehicle, as described herein. The term “control unit” may refer to a hardware device that includes a memory and a processor. The memory is configured to store program instructions, and the processor is specifically programmed to execute the program instructions to perform one or more processes which are described further below. The control unit may control operation of units, modules, parts, or the like, as described herein. Moreover, it is understood that the below methods may be executed by an apparatus comprising the control unit in conjunction with one or more other components, as would be appreciated by a person of ordinary skill in the art.
Furthermore, the control unit of the present disclosure may be embodied as non-transitory computer readable media containing executable program instructions executed by a processor, controller or the like. Examples of the computer readable mediums include, but are not limited to, ROM, RAM, compact disc (CD)-ROMs, magnetic tapes, floppy disks, flash drives, smart cards and optical data storage devices. The computer readable recording medium can also be distributed throughout a computer network so that the program instructions are stored and executed in a distributed fashion, e.g., by a telematics server or a controller area network (CAN). The computer network may refer to a local network, a remote network (e.g., the cloud), or any suitable combination or variation thereof.
Referring now to embodiments of the present disclosure, the vehicle CAN may comprise a plurality of ECUs. Each ECU may be responsible for controlling certain components or functions of the vehicle (e.g., vehicle 900 of
It should be understood that this example is non-limiting and provided for demonstration purposes only.
The ECUs may be configured to utilize information stored in a CAN database for performing communication with each other in the CAN. For example, one or more CAN databases accessible by the ECUs may be configured to store CAN message information that provides an indication of how an ECU which receives an incoming CAN data frame should interpret the received information. The CAN message information may also be referred to as a CAN message reference.
In further detail,
According to the example illustrated in
For instance, according to the CAN message information 100 stored in CAN Database 1, the input data field “Speed” corresponds to ID 100, the input data field “Temperature” corresponds to ID 101, and the input data field “Engine Temperature” corresponds to ID 102. Conversely, according to the CAN message information 100 stored in CAN Database 2, the input data field “Speed” corresponds to ID 102, the input data field “Temperature” corresponds to ID 100, and the input data field “Engine Temperature” corresponds to ID 101. Thus, each of the CAN message information 100 respectively stored in the CAN databases 110 may be uniquely configured via a unique identification scheme of a plurality of data fields of a CAN message (e.g., speed, temperature, engine temperature, etc.). It should be understood that this example is non-limiting and provided for demonstration purposes only.
The ECUs 120 may be configured to utilize the CAN message information 100 stored in a particular CAN database 110 for communicating with each other. Specifically, the ECUs 120 may refer to the IDs for each input data field, as shown in
Problematically, if a hacker obtains the CAN message information 100 being used as a reference by the ECUs 120, the hacker may be capable of decoding intercepted data. To protect against such an intrusion, it is contemplated that the ECUs 120 may utilize a shifting CAN message reference by changing the CAN database 110 in which to access CAN message information 100 on a periodic basis, so that a hacker is unable to know which stored CAN message information 100 is being used by the ECUs at a given time. More particularly, since the message IDs are changed across the CAN databases 110, a hacker may not be able to ascertain the correct IDs needed to decode data being transmitted across the CAN bus 150. This may cause the hacker to miscalculate the data byte length, resulting in an incorrect start of next frame, which further prevents the CAN messages from being surreptitiously decoded.
In this regard,
Firstly, an ECU 120 may be configured to receive a plurality of measurement values deriving from a plurality of sensors 130 equipped in the vehicle. (It is noted that the following steps may be performed by a single ECU 120 or a plurality of ECUs 120.) The ECU 120 may be configured to communicate with any amount or type of sensors 130 in the vehicle, and likewise, the ECU 120 may be configured to receive any amount or type of measurement inputs from the sensors 130 such as, for instance, vehicle speed, engine revolutions per minute (RPM), vehicle odometer, cabin temperature, blower fan speed, windshield wiper speed, radio volume level, current radio frequency, user destination, and so forth.
Next, the ECU 120 may be configured to use these measurement inputs to calculate a database reference number 140 that identifies a particular CAN database 110 among the plurality of CAN databases. The ECU 120 may be configured to calculate the database reference number 140 in various ways. In one example, the ECU 120 may be configured to calculate the database reference number 140 using an equation with the measurement inputs received from the plurality of sensors 130 and one or more random numbers as parameters. The result of the calculation may be applied to a modulo (MOD) of N, where N is the total number of CAN databases 110 in the CAN.
As an example, an equation such as Equation 1, shown below, can be used by the ECU 120 to calculate the database reference number 140.
With respect to Equation 1, P may be the database reference number 140, x1, x2, x3, and x4 may represent measurement values received from four sensors 130 equipped in the vehicle, respectively, R1, R2, R3, and R4 may represent four distinct random numbers, respectively, and N may represent the total number of CAN databases 110.
As another example, an equation such as Equation 2, shown below, can be used by the ECU 120 to calculate the database reference number 140.
With respect to Equation 2, P may be the database reference number 140, x1, x2, x3, and x4 may represent measurement values received from four sensors 130 equipped in the vehicle, respectively, R may represent a random number, and N may represent the total number of CAN databases 110.
Any suitable equation, such as those above, which accepts as parameters one or more random numbers and the measurement inputs received from the sensors 130, may be used to calculate the database reference number 140. The formula for calculating the database reference number 140 may be adjusted to match a desired level of complexity. Thus, it should be understood that the above equations are non-limiting and provided for demonstration purposes only.
According to the example illustrated in
Continuing in this hypothetical example, a first ECU 120 may be configured to transmit a message (i.e., CAN data frame) indicating a tail light status to other ECUs 120 in the CAN. The first ECU 120 may be configured to encode the message based upon the uniquely configured CAN message information 100 stored in the CAN database #309. A second ECU 120 may then receive the encoded message transmitted from the first ECU 120. The second ECU 120 may be configured to decode the message, or determine the contents thereof, using the same uniquely configured CAN message information 100 stored in the CAN database #309. It should be understood that this example is non-limiting and provided for demonstration purposes only.
The ECU 120 (or plurality of ECUs) may be configured to calculate a new database reference number 140 on a periodic basis such that any potential hackers may be prevented from knowing the CAN database 110 being used by the ECUs 120 for CAN communication at any given time. To this end, the ECU 120 may be configured to establish a plurality of periodic intervals during which each ECU 120 may perform CAN communication based upon the uniquely configured CAN message information stored in a particular CAN database 110. Whenever a subsequent or new interval among the plurality of periodic intervals begins, the database reference number 140 may be recalculated by the ECU 120 or, put another way, a new database reference number 140 may be calculated by the ECU 120. Upon such calculation, the ECUs 120 may be configured to perform CAN communication based upon the uniquely configured CAN message information 100 stored in the newly identified CAN database 110. Example processes for establishing the plurality of periodic intervals are described in greater detail below.
The methods for controlling CAN communication using a shifting CAN message reference, as described herein, may be implemented using a variety of operation modes. For example,
In this exemplary mode of operation, each ECU 120 may be configured to independently calculate the database reference number 140 using the same equation, such as either of the example equations described above, with common measurement inputs provided to all ECUs 120. As a result, each ECU 120 may be configured to derive the same database reference number 140, allowing all ECUs 120 in the CAN to retrieve the same uniquely configured CAN message information 100 that is stored in the CAN database 110 corresponding to the database reference number 140. The ECUs 120 may then communicate with each other via the CAN bus 150 based upon the CAN message information 100.
As mentioned above, the ECUs 120 may be configured to calculate a new database reference number 140 on a periodic basis so as to shift the CAN message reference and thus deter hackers from decoding any intercepted messages. In this exemplary mode of operation, a plurality of periodic intervals during which each ECU 120 performs CAN communication based upon the uniquely configured CAN message information 100 stored in a particular CAN database 110 may be established according to a common time set by a time-keeping device equipped in the vehicle, such as an internal clock, a global positioning system (GPS) device, or the like. Thus, when a subsequent interval begins according to the common time set by the time-keeping device, the ECUs 120 may calculate a new database reference number 140. Upon such calculation, the ECUs 120 may perform CAN communication based upon the uniquely configured CAN message information 100 stored in the CAN database 110 newly identified by the database reference number 140.
In a second exemplary mode of operation, a master-slave relationship may be established among the plurality of ECUs 120. Particularly, a given ECU 120 among the plurality of ECUs 120 in the CAN may be designated as a master ECU. The master ECU may be responsible for controlling one or more operations of the method for controlling CAN communication.
Meanwhile, the remaining ECUs 120 may operate as slave ECUs.
In this exemplary mode of operation, all ECUs 120 may be configured to receive the same measurement inputs from the plurality of sensors 130, similar to the example illustrated in
In contrast with the first exemplary mode of operation, the second exemplary mode of operation involves the master ECU establishing the plurality of periodic intervals during which each ECU 120 performs CAN communication based upon the uniquely configured CAN message information 100 stored in a particular CAN database 110. For instance, the master ECU can define a plurality of database reference number calculation times, at each of which a new database reference number 140 must be calculated. In one example, the master ECU may be configured to define the database reference number calculation times according to fixed intervals (e.g., every 15 seconds, every 30 seconds, etc.) or any other suitable metric.
Then, the master ECU may be configured to transmit the defined plurality of database reference number calculation times to the slave ECUs. Once the slave ECUs have received the plurality of database reference number calculation times set by the master ECU, and a subsequent database reference number calculation time begins, the slave ECUs may be configured to calculate a new database reference number 140. (The master ECU may be configured to perform the calculation, as well.) Upon such calculation all ECUs 120 may perform CAN communication based upon the uniquely configured CAN message information 100 stored in the CAN database 110 newly identified by the database reference number 140.
In a third exemplary mode of operation, a master-slave relationship may again be established among the plurality of ECUs 120. Particularly, a given ECU 120 among the plurality of ECUs 120 in the CAN may be designated as a master ECU. The master ECU may be responsible for controlling one or more operations of the method for controlling CAN communication.
Meanwhile, the remaining ECUs 120 may operate as slave ECUs.
In contrast with the first and second modes of operation, only the master ECU may receive the measurement inputs from the plurality of sensors 130 in the third mode of operation. Using the received sensor inputs, the master ECU may be configured to calculate the database reference number 140 using an equation such as either of the example equations described above. In this case, the slave ECUs may not calculate the database reference number 140 and, as a result, the calculations may be limited to a single ECU (i.e., the master). Alternatively, the master ECU may be configured to transmit the measurement inputs to the slave ECUs, and the slave ECUs may also calculate the database reference number 140 using the measurement inputs received from the master ECU.
After calculating the database reference number 140, the master ECU may be configured to send the calculated database reference number 140 to the slave ECUs. This may allow all ECUs 120 to retrieve the same uniquely configured CAN message information 100 that is stored in the CAN database 110 corresponding to the database reference number 140. The ECUs 120 may then communicate with each other via the CAN bus 150 based upon the CAN message information 100.
Similar to the second exemplary mode of operation, the third exemplary mode of operation involves the master ECU establishing the plurality of periodic intervals during which each ECU 120 performs CAN communication based upon the uniquely configured CAN message information 100 stored in a particular CAN database 110. For instance, the master ECU may be configured to define a plurality of database reference number calculation times, at each of which a new database reference number 140 must be calculated. In one example, the master ECU may be configured to define the database reference number calculation times according to fixed intervals (e.g., every 15 seconds, every 30 seconds, etc.) or any other suitable metric.
Once a subsequent database reference number calculation time begins according to the master ECU's defined intervals, the master ECU may be configured to calculate a new database reference number 140, and transmit the same to the slave ECUs. All ECUs 120 may then perform CAN communication based upon the uniquely configured CAN message information 100 stored in the CAN database 110 newly identified by the database reference number 140.
In a fourth exemplary mode of operation, a rotating master-slave relationship may be established among the plurality of ECUs 120. That is, a given ECU 120 among the plurality of ECUs 120 in the CAN may be designated as a master ECU, in the same manner as described above, and new master ECUs may be designated at predefined times. The current master ECU may be responsible for designating a subsequent master ECU. Meanwhile, the remaining ECUs 120 may be configured to operate as slave ECUs.
Using the received sensor inputs, only the presently acting master ECU may calculate the database reference number 140 using an equation such as either of the example equations described above. In this case, the slave ECUs may not calculate the database reference number 140 and, as a result, the calculations are limited to a single ECU (i.e., the ECU presently acting as master).
After calculating the database reference number 140, the master ECU may send the calculated database reference number 140 to the slave ECUs. This may allow all ECUs 120 to retrieve the same uniquely configured CAN message information 100 that is stored in the CAN database 110 corresponding to the database reference number 140. The ECUs 120 may then communicate with each other via the CAN bus 150 based upon the CAN message information 100.
In the fourth exemplary mode of operation, the master ECU may be configured to establish the plurality of periodic intervals during which each ECU 120 performs CAN communication based upon the uniquely configured CAN message information 100 stored in a particular CAN database 110. For instance, the master ECU may be configured to define a plurality of database reference number calculation times, at each of which a new database reference number 140 must be calculated. In one example, the master ECU may define the database reference number calculation times according to fixed intervals (e.g., every 15 seconds, every 30 seconds, etc.) or any other suitable metric.
Once a subsequent database reference number calculation time begins according to the master ECU's defined intervals, the master ECU may be configured to calculate a new database reference number 140 and transmit the same to the slave ECUs. All ECUs 120 may then perform CAN communication based upon the uniquely configured CAN message information 100 stored in the CAN database 110 newly identified by the database reference number 140.
Moreover, as mentioned above, the master ECU may be configured to designate a new master ECU at predefined times according to fixed intervals (e.g., every 15 seconds, every 30 seconds, etc.) or any other suitable metric. Upon designating a new master ECU, the current master ECU may be configured to send a message to the new master ECU notifying of the master designation. The new master ECU may then be responsible for performing the functions listed above.
According to an exemplary embodiment, a system may be configured to perform the second, third, and fourth modes of operation on the same system, using a remote transmission request (RTR) using a CAN remote frame.
In this regard,
The identifier (ID) bit may comprise a suitable number of bits. As shown in
According to an exemplary embodiment, one or more of the least significant bits (LSBs) of the DLC may be used to determine a system mode of operation to be used (e.g., the second mode of operation 605, the third mode of operation 610, the fourth mode of operation 615, etc.).
According to an exemplary embodiment, the one or more of the LSBs of the DLC are compared against a database to determine the mode of operation. According to an exemplary embodiment, once the mode of operation is determined, one or more most significant bits (MSBs) of the DLC may be added to an end of the identifier generating an RTR message with an RTR request value comprising the identifier and the one or more MSBs of the DLC. According to an exemplary embodiment, the request value may be communicated through the CAN bus to be interpreted, resulting in the requested data being returned to the ECU 120 via the CAN bus. According to an exemplary embodiment, the RTR request value is associated with a requested answer value which is associated with the system mode of operation.
According to an exemplary embodiment, two MSBs may be added out of a 4-bit DLC to an 11-bit identifier (e.g., into a 2 LSB position of an 11-bit identifier) and, together, may form a 13-bit number whose range can extend along a range of possible values. According to an exemplary embodiment, the range of possible values may be from 1 to 8192.
As shown in
As shown in
As shown in
According to an exemplary embodiment, the RTR message, with the RTR request value, may be sent to and/or received by each ECU 120 in the system. Based on the one or more LSBs of the DLC, the system may shift the mode of operation. According to an exemplary embodiment, the system may be configured to perform each of the second, third, and fourth modes of operation, and switch between operation modes, providing additional security, e.g., in systems which have sets of common random inputs and sets of exclusive inputs for each ECU 120.
It should be understood that all of the exemplary modes of operation described above are non-limiting and provided for demonstration purposes only. Additional modes of operation are possible, and the modes of operation described above can be modified in any suitable manner in accordance with the present claims.
Referring now to
The hardware architecture of
Some or all components of the computing device 800 may be implemented as hardware, software, and/or a combination of hardware and software. The hardware may comprise, but is not limited to, one or more electronic circuits. The electronic circuits may comprise, but are not limited to, passive components (e.g., resistors and capacitors) and/or active components (e.g., amplifiers and/or microprocessors). The passive and/or active components may be adapted to, arranged to, and/or programmed to perform one or more of the methodologies, procedures, or functions described herein. According to an exemplary embodiment, one or more computational functions may be computed on a server or over the cloud, while maintaining the spirit and functionality of the present disclosure. For example, one or more computational functions may be computed on a server or over the cloud when one or more details of one or more actual implementations are not known.
As shown in
At least some of the hardware entities 814 may be configured to perform actions involving access to and use of memory 812, which may be a Random Access Memory (RAM), a disk driver and/or a Compact Disc Read Only Memory (CD-ROM), among other suitable memory types.
Hardware entities 814 may comprise a disk drive unit 816 comprising a computer-readable storage medium 818 on which may be stored one or more sets of instructions 820 (e.g., programming instructions such as, but not limited to, software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions 820 may also reside, completely or at least partially, within the memory 812 and/or within the CPU 806 during execution thereof by the computing device 800.
The memory 812 and the CPU 806 may also constitute machine-readable media. The term “machine-readable media”, as used here, refers to a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions 820. The term “machine-readable media”, as used here, also refers to any medium that is capable of storing, encoding, or carrying a set of instructions 820 for execution by the computing device 800 and that cause the computing device 800 to perform any one or more of the methodologies of the present disclosure.
Referring now to
As shown in
Operational parameter sensors that are common to both types of vehicles may comprise, for example: a position sensor 934 such as an accelerometer, gyroscope and/or inertial measurement unit; a speed sensor 936; and/or an odometer sensor 938. The vehicle system architecture 900 also may comprise a clock 942 that the system uses to determine vehicle time and/or date during operation. The clock 942 may be encoded into the vehicle on-board computing device 920, it may be a separate device, or multiple clocks may be available.
The vehicle system architecture 900 also may comprise various sensors that operate to gather information about the environment in which the vehicle is traveling. These sensors may comprise, for example: a location sensor 944 (for example, a Global Positioning System (GPS) device); object detection sensors such as one or more cameras 946; a LiDAR sensor system 948; and/or a RADAR and/or a sonar system 950. The sensors also may comprise environmental sensors 952 such as, e.g., a humidity sensor, a precipitation sensor, a light sensor, and/or ambient temperature sensor. The object detection sensors may be configured to enable the vehicle system architecture 900 to detect objects that are within a given distance range of the vehicle in any direction, while the environmental sensors 952 may be configured to collect data about environmental conditions within the vehicle's area of travel. According to an exemplary embodiment, the vehicle system architecture 900 may comprise one or more lights 954 (e.g., headlights, flood lights, flashlights, etc.).
During operations, information may be communicated from the sensors to an on-board computing device 920 (e.g., computing device 800 of
Geographic location information may be communicated from the location sensor 944 to the on-board computing device 920, which may then access a map of the environment that corresponds to the location information to determine known fixed features of the environment such as streets, buildings, stop signs and/or stop/go signals. Captured images from the cameras 946 and/or object detection information captured from sensors such as LiDAR 948 may be communicated from those sensors to the on-board computing device 920. The object detection information and/or captured images may be processed by the on-board computing device 920 to detect objects in proximity to the vehicle. Any known or to be known technique for making an object detection based on sensor data and/or captured images may be used in the embodiments disclosed in this document.
Accordingly, systems and methods are described herein for controlling CAN communication in a vehicle using a shifting CAN message reference that can enhance the security of communications between ECUs over the CAN bus. Because the formulae for calculating the database reference number are unknown to outside entities, it may be difficult for potential hackers to determine the CAN database being referenced by the ECUs. Moreover, the use of physical run time input from vehicle sensors can provide additional unpredictability to the CAN database switching logic to further thwart intrusions. In the event of a hacker attempting to inject harmful messages into the CAN, it may be detected by any ECU once the reference database changes since the hacker cannot predict the reference database change, and will be injecting old reference messages as a result. Also, even when a system is compromised (e.g., a hacker discovers all databases used in the CAN), a system breach may be detected faster because of the reference database switch, and a prevention mechanism can be promptly triggered.
The foregoing description has been directed to embodiments of the present disclosure. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. Accordingly, this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.
