CN110915170A

CN110915170A - Ecu

Info

Publication number: CN110915170A
Application number: CN201880047811.3A
Authority: CN
Inventors: 中园浩介
Original assignee: Bosch Corp
Current assignee: Bosch Corp
Priority date: 2017-05-18
Filing date: 2018-03-08
Publication date: 2020-03-24
Anticipated expiration: 2038-03-08
Also published as: JP6838147B2; CN110915170B; WO2018211790A1; DE112018002549T5; JPWO2018211790A1

Abstract

An ECU capable of avoiding complication and increase in cost of an on-vehicle network and realizing protection of safety is proposed. An ECU (10) connected to a CAN bus (20) is characterized in that a CPU (100) of the ECU (10) receives normal data (D1) through a communication bus (20) and then receives data (D2-D8) with the same ID as the normal data (D1), and when the number of times the data (D2-D8) with the same ID are received in a fixed period is more than a predetermined number of times (DC), the state is judged to be abnormal, and the state is shifted to a safe control state.

Description

ECU

Technical Field

The present invention relates to an ECU, and more particularly, to an invention preferably applied to an ECU provided in a vehicle-mounted network.

Background

In recent years, a vehicle-mounted Network (CAN Network) using a communication specification called CAN (Controller Area Network) has been widespread. The CAN network is configured by connecting a plurality of Electronic Control Units (ECUs) provided in the vehicle to a communication bus (CAN bus) using a CAN. The ECUs CAN communicate with each other (CAN communication) with other ECUs via the CAN bus.

The CAN bus connects the ECUs to each other so as to be able to communicate with each other, and is provided with a Data Link Connector (DLC). By connecting a dedicated device to the data link connector, it is possible to read a fault code generated by an On Board Diagnostics (OBD) provided in the ECU. By referring to the fault code, for example, a service engineer can easily specify the fault.

However, when the DLC is improperly used, specifically, when unauthorized data having the same ID as the legitimate data and different contents is transmitted from the outside to the CAN bus via the DLC, there is a possibility that the ECU connected to the CAN bus receives the unauthorized data and performs an erroneous operation. Therefore, from the viewpoint of security protection, a technique for protecting against such illegal data is required.

Further, a case where an unauthorized data is transmitted to the CAN bus from a device connected to the DLC via a wire, and a case where a device capable of wireless communication with the DLC is connected and an unauthorized data is transmitted to the CAN bus via the device via a wire are considered.

Patent document 1 discloses the following technique: for data transmitted to the CAN bus, a difference between a previous transmission timing and a current transmission timing is calculated as a transmission cycle, the transmission cycle is compared with a transmission cycle for judging unauthorized data stored in advance, and if the calculated transmission cycle is shorter than the transmission cycle for judging unauthorized data as a result of the comparison, the data transmitted this time is judged to be unauthorized data.

According to the technique described in patent document 1, one ECU monitors the CAN bus, and the other ECU CAN detect and invalidate unauthorized data before the reception of the data is completed. Thus, it is assumed that all ECUs connected to the in-vehicle network CAN be protected from spoofing attacks in which unauthorized data having the same ID and different contents from those of legitimate data intrudes into the CAN bus and causes erroneous operation of the ECU connected to the CAN bus.

Documents of the prior art

Patent document

Patent document 1: japanese patent laid-open No. 2014-236248.

Disclosure of Invention

Problems to be solved by the invention

However, the technique described in patent document 1 requires an additional device for constantly monitoring data transmitted to the CAN bus. Specifically, in addition to a normal communication line for connecting the ECU and the CAN bus, an additional communication line for connecting the ECU and the CAN bus in parallel therewith is necessary. In addition, additional processing such as processing for constantly monitoring data on the CAN bus, processing for determining whether the data is invalid data, and invalidation processing in the case of invalid data is necessary.

Therefore, the following problems occur: the hardware structure and the software structure of the in-vehicle network are complicated, and concomitantly, the cost for realizing the entire in-vehicle network increases.

The present invention has been made in view of the above circumstances, and provides an ECU capable of protecting safety while avoiding complication of an on-vehicle network and increase in cost.

Means for solving the problems

In order to solve the problem, in the ECU (10) connected to a CAN bus (20), the CPU (100) of the ECU (10) receives normal data (D1) through a communication bus (20), then receives data (D2-D8) with the same ID as the normal data (D1), and when the number of times the data (D2-D8) with the same ID are received within a fixed period is more than a predetermined number of times (DC), the ECU determines that the state is abnormal and shifts to a safe control state.

Effects of the invention

According to the present invention, it is possible to avoid complication and increase in cost of the in-vehicle network and realize protection of security.

Drawings

Fig. 1 is an overall configuration diagram of a vehicle-mounted network.

Fig. 2 is an internal structural view of the ECU.

Fig. 3 is a flowchart of the reception process.

Fig. 4 is a conceptual diagram of the reception process.

Detailed Description

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. The following description is merely one embodiment of the present invention, and the technical scope of the present invention is not limited thereto.

Fig. 1 shows the overall structure of an on-board network N1 in the vehicle 1. The in-vehicle Network N1 is a Network using a communication specification called CAN (Controller Area Network), and is configured to include an Electronic Control Unit (ECU) 10 and a CAN bus 20.

The ECU10 is a control device that controls various operations of the vehicle 1. The ECU10 is configured to include a CPU (Central Processing Unit), a RAM (Random Access Memory), a ROM (Read Only Memory), an input/output interface, and the like. Each ECU10 is connected to the CAN bus 20. Thus, the ECUs 10 are connected so as to be communicable with each other via the CAN bus 20.

Among the ECUs 10 connected to the CAN bus 20, an ECU10 called an engine ECU comprehensively controls the operation of the vehicle 1. Therefore, in the present embodiment, by applying the present invention to the engine ECU, it is intended to achieve protection of safety (security) particularly with respect to control related to traveling.

The CAN bus 20 is a communication bus using CAN, and each ECU10 is connected so as to be communicable with each other. The CAN bus 20 is provided with a Data Link Connector (DLC) 30. The DLC30 is a connection connector for connecting the scan tool (scan tool) 40 to the CAN bus 20 by wire or wirelessly.

When the scan tool 40 is connected to the DLC30 and a specific operation is performed On the scan tool 40, a trouble code generated by an On Board Diagnostics (On Board Diagnostics) provided in the ECU10 can be read. For example, a service engineer (service engineer) can specify a trouble spot of the vehicle 1 with reference to a trouble code displayed on the display screen of the scanning tool 40.

Here, a case where unauthorized data is transmitted from the outside of the vehicle 1 to the CAN bus 20 via the DLC30 is considered. The improper data referred to herein is data whose timing of transmission to the CAN bus 20 is different from that of the proper data.

For example, when the ID of one piece of normal data is "1" and is transmitted to the CAN bus 20 every "100 ms", the data having the ID of "1" and being transmitted to the CAN bus 20 every "120 ms" is handled as the illegal data in the present embodiment. In the relationship with the data having the ID "1", the data having different IDs or the data having the same ID but different contents are of course also the unauthorized data.

When such unauthorized data is transmitted to the CAN bus 20 via the DLC30 without any protection means, the ECU10 connected to the CAN bus 20 receives the unauthorized data and performs arithmetic processing. In particular, when the engine ECU receives and processes unauthorized data, there is a possibility that the control related to the traveling cannot be performed.

In the present embodiment, even when unauthorized data is transmitted to the CAN bus 20, the ECU10 excludes the unauthorized data from the object of arithmetic processing, and only authorized data is the object of arithmetic processing. When the number of times the ECU10 receives the unauthorized data via the CAN bus 20 increases, the ECU10 determines that the data is in an abnormal state and shifts to a safe control state.

In the safe control state, there are a state in which the engine is stopped (engine stall state), a state in which reception of data from the CAN bus 20 is rejected, a state in which the vehicle transitions to a limp home mode (limp home mode) in which travel using a minimum gear (gear stage) is maintained, and the like.

Fig. 2 shows the internal structure of the ECU 10. The ECU10 includes a memory or an input/output interface, not shown here, such as a RAM and a ROM, and the CPU 100. The CPU100 includes a program or a memory such as a data transmitting/receiving unit 101, a received data monitoring unit 102, a CAN buffer 103, a control determination unit 104, and an arithmetic unit 105.

The data transmitting/receiving unit 101 receives the normal or unauthorized data D0-D8 from the CAN bus 20 and outputs them to the received data monitoring unit 102. The data transceiver 101 transmits the calculation results D21 and D22 for the normal data among the data D0 to D8 or the fail-safe data (fail-safe data) D23 for shifting to the safe control state to the CAN bus 20.

The operation results D21, D22 and the fail-safe data D23 are then used for the operation of other ECUs 10 or other devices. In the case where the other ECU10 or other device receives the fail-safe data D23, safe control is performed without depending on the operation of the driver.

When the normal or unauthorized data D0 to D8 are inputted from the data transmitter/receiver 101, the received data monitoring unit 102 outputs the data to the CAN buffer 103, and counts the number of times the data D0 to D8 are received to determine whether the data are in an abnormal state.

Specifically, when receiving the normal data D0 serving as a reference, the received data monitoring unit 102 outputs the normal data D to the CAN buffer 103, and starts a timer T held in the CPU100 to start counting time.

The received data monitoring unit 102 refers to a predetermined time DT associated in advance for each ID, and outputs data D0-D8 received until the predetermined time DT has elapsed to the CAN buffer 103. The number of times of receiving the data D0-D8 is counted by a counter C. That is, the received data monitoring unit 102 counts the number of times of receiving data per unit time.

Then, the received data monitoring unit 102 refers to the predetermined number of times DC determined in advance, and determines whether or not the number of times of reception counted by the counter C is equal to or greater than the predetermined number of times DC. When the number of times of reception is equal to or greater than the predetermined number of times DC, the received data monitoring unit 102 determines that the state is abnormal. Then, the received data monitoring unit 102 outputs the monitoring result indicating the abnormal state to the control determination unit 104.

The CAN buffer 103 is a memory for storing data to be processed.

The control determination unit 104 determines whether to set the data stored in the CAN buffer 103 as an operation target or exclude it from the operation target based on the monitoring result from the received data monitoring unit 102. Then, the control and determination unit 104 outputs the determination result to the calculation unit 105.

The arithmetic unit 105 performs arithmetic processing on data received within a predetermined time (within a window) after the elapse of the predetermined time DT among the data D0 to D8 stored in the CAN buffer 103 based on the determination result from the control determination unit 104, and generates arithmetic results D21 and D22. Alternatively, the failure safety data D23 is generated by excluding the failure safety data from the object of arithmetic processing.

For example, when the ID of the data D0 is "1" and the predetermined time DT associated with the ID in advance is "100 ms", the arithmetic unit 105 performs arithmetic processing on the data with the ID of "1" received in a window of a period of 100ms to 110ms or 95ms to 105ms after the reception of the data D0, and generates arithmetic results D21 and D22.

On the other hand, when the state is abnormal, the arithmetic unit 105 excludes the data D0 to D8 stored in the CAN buffer 103 from the arithmetic target, and generates the failure safety data D23 for shifting to the safe control state. The arithmetic unit 105 outputs the generated arithmetic results D21 and D22 or the failure safety data D23 to the data transmission/reception unit 101.

Fig. 3 shows a flow chart of the reception process in the present embodiment. The reception process is started from the point in time at which the counter C is activated by the CPU100 of the ECU10, and is executed from time to time thereafter. The start timing of the counter C is assumed to be when the ECU10 is powered ON (ON), but is not necessarily limited to this.

Here, the description is given with a fixed period after receiving one normal piece of data serving as a reference. The IDs of the data described herein are all the same (for example, "1"). That is, the present process is performed for each ID. For convenience of explanation, the processing main body is explained as the CPU 100.

First, the CPU100 starts the counter C to start counting the number of receptions (S1). After that, when receiving a normal data from the CAN bus 20 (S2), the CPU100 starts the timer T to start counting the time (S3).

After the timer T is started, the CPU100 receives regular data in step S2, and therefore counts up the reception number i by +1 (S4). Then, the CPU100 judges whether the reception frequency i is i ≧ DC of a predetermined frequency (S5).

For example, when the predetermined number of times DC is determined to be "6", since the reception number i is "1" at the time when one normal data is received, the reception number i < the predetermined number of times DC, and a negative result is obtained in the determination of step S5.

When a negative result is obtained in the determination of step S5 (S5: no), the CPU100 outputs the received normal data to the CAN buffer 103 (S6). Then, the CPU100 determines whether there is data additionally received after the timer T is started (S7). When an affirmative result is obtained in the determination of step S7 (S7: yes), the CPU100 proceeds to step S4 and repeats the above-described processing.

On the other hand, if a negative result is obtained in the determination of step S7 (S7: no), the CPU100 determines whether or not the predetermined time DT has elapsed by referring to the predetermined time DT corresponding to the ID of the normal data received in step S2 and the count time at which counting was started in step S3 (S8).

If a negative result is obtained in the determination of step S8 (S8: no), the CPU100 proceeds to step S4 before the predetermined time DT has elapsed after the count time, and repeats the above-described processing. Then, when an affirmative result is obtained in the judgment of step S5 (S5: YES), the CPU100 judges the state as abnormal (S9). Then, the CPU100 shifts to a safe control state (S10), and ends the present process.

In contrast, when an affirmative result is obtained in the determination of step S8 (S8: yes), the CPU100 stops and restarts the counter C, thereby temporarily resetting the count number and restarting the count of the reception number (S12).

Next, the CPU100 determines whether or not there is data received within a predetermined time (within a window) from the elapse of the predetermined time DT among the data stored in the CAN buffer 103 (S13).

If a negative result is obtained in the determination of step S13 (S13: no), the CPU100 ends the present process without performing arithmetic processing on the data stored in the CAN buffer 103. On the other hand, if the CPU100 obtains a positive result (yes in S13), it performs arithmetic processing on data received in the window among the data stored in the CAN buffer 103 (S14), and ends the present processing.

Further, the CPU100 proceeds to step S4 for data having the same ID received thereafter, and repeats the above-described processing.

Fig. 4 shows a conceptual diagram of the reception process explained in fig. 3. The processing of the data D0-D8 will be described in time series.

At a timing of time t = t0, the normal data D0 serving as a reference is received by the data transmission/reception unit 101. The received data monitoring unit 102 starts a timer T and refers to a predetermined time DT. Further, the number of times of reception by the counter C is counted up by + 1.

After that, the data D0 is output to the CAN buffer 103. The data D0 stored in the CAN buffer 103 is determined as an operation target by the control determination unit 104 and then is subjected to an operation process by the operation unit 105. As a result, the operation result D21 is generated.

During the time t when t0 is not less than t < t1, the received data is monitored by the received data monitoring unit 102. Specifically, the time is counted by the timer T, and the number of receptions is counted by the counter C. Here, since only the data D0 is received, the number of times of reception is 1.

At a timing of time T = T1, the received data monitoring unit 102 stops and restarts the timer T and the counter C, thereby resetting the count time and the number of times of reception. After reset, the count is restarted. The timer T here restarts counting of time at a timing of time T = T2, and the counter C restarts counting of data immediately after being reset.

The period of time t1 < t.ltoreq.t 3 shows a period in which the received data is subjected to arithmetic processing. This period is referred to herein as the window W. The regular data D1 is data received at a timing of time t = t2, and is data received within the window W.

Therefore, the data D1 is output to the CAN buffer 103, determined as an operation target by the control determination unit 104, and then subjected to operation processing by the operation unit 105. As a result, the operation result D22 is generated.

During the period when the time t is t2 ≦ t < t5, the received data is monitored again. During this period, a plurality of unauthorized data D2-D7 are received. Every time the illegal data D2-D7 are received, the counter C counts up the number of times of reception by + 1.

At the timing of time t = t4, the number of receptions is shown to reach the prescribed number DC. In this case, the monitoring result from the received data monitoring unit 102 is output to the control determination unit 104, and the control determination unit 104 excludes the received data from the object of the arithmetic processing.

During the time t being t5 < t ≦ t7, the 2 nd time window W is set. In this manner, the window W is periodically set every time the predetermined time DT elapses. The normal data D8 is data received at the timing of time t = t6 and is data received in the window W, but is excluded from the object of arithmetic processing. Then, the failure safety data D23 is generated instead thereof.

As described above, according to the present embodiment, when the normal data D0 serving as a reference is received, the number of times of reception of data having the same ID as that of the data D0 among the data received later is counted, and when the number of times of reception in a fixed period does not reach the predetermined number of times DC, the data received later is subjected to arithmetic processing, and when the number of times of reception is equal to or more than the predetermined number of times DC, it is determined that the state is abnormal, and the state is shifted to the safe control state.

More specifically, the timer T is started at the time point when the regular data D0 is received, the number of times of reception of the data received until the counted time elapses the predetermined time DT is counted, and if the number of times of reception does not reach the predetermined number of times DC, the regular data D1 received in the window W thereafter is subjected to arithmetic processing, whereas if the number of times of reception reaches the predetermined number of times DC, the regular data D8 is excluded from the object of arithmetic processing, and the control state is shifted to the safe control state based on the generated regular data D23 instead.

Thus, it is possible to protect against unauthorized data only by software control without requiring an additional device as a protection means against spoofing attacks (spoofing attack) and without requiring complicated processing such as monitoring, determining, and invalidating unauthorized received data. Therefore, according to the present embodiment, it is possible to avoid complication and increase in cost of the in-vehicle network and to achieve protection of security.

Although the ID is associated with the predetermined time DT in advance in the present embodiment, the predetermined time DT may be associated with the window width (the time between time t1 and time t3 in fig. 4).

For example, if the ID is "1", the predetermined time DT is "99 ms" and the window width is "10 ms", and if the ID is "2", the predetermined time DT is "50 ms" and the window width is "5 ms". That is, the window width may be made variable according to the number of receptions per unit time.

In this case, the window width can be shortened for data having a large number of receptions per unit time, and thus, it is possible to easily exclude unauthorized data from the object of arithmetic processing. Therefore, the security can be more reliably protected.

In the present embodiment, the number of receptions is temporarily reset at the time point when the count time passes the predetermined time DT, but the present invention is not limited thereto, and the number of receptions may not be reset until the cumulative number of receptions reaches the predetermined number of times DC. That is, the reception count may be reset at a timing when the cumulative total of the reception counts of data received outside the range of the window W set periodically reaches the predetermined count DC after the counter C starts counting the reception counts.

In this case, since it is not necessary to reset the number of receptions every time the count time passes the predetermined time DT, the processing can be simplified. In addition, even when the unauthorized data is not received to the extent of the state determined to be abnormal, the unauthorized data can be stably received and can be determined to be abnormal.

Description of reference numerals

1 vehicle

10 ECU

20 CAN bus

30 DLC

40 scanning tool

100 CPU

101 data transmitting/receiving unit

102 received data monitoring unit

103 CAN buffer

104 control judgment part

105 a computing unit.

Claims

1. An ECU (10) connected to a communication bus (20), characterized in that,

the CPU (100) of the ECU (10) receives regular data (D1) via the communication bus (20), then receives data (D2-D8) having the same ID as the regular data (D1), and determines an abnormal state and shifts to a safe control state when the number of times the data (D2-D8) having the same ID are received within a fixed period is equal to or more than a predetermined number of times (DC).

2. The ECU of claim 1,

the CPU (100) sets data (D1) received in a window (W) set periodically as an object of arithmetic processing when the number of times data (D2-D8) having the same ID are received in a fixed period is less than the predetermined number of times (DC).

3. The ECU according to claim 1 or 2,

when the CPU (100) determines that the state is abnormal, the CPU excludes data (D8) received in a window (W) which is periodically set from the object of arithmetic processing, and generates failure safety data for shifting to a safe control state.

4. The ECU of claim 2 or 3,

the CPU (100) sets the window (W) periodically every time a predetermined time (DT) corresponding to the ID of the normal data (D1) has elapsed.

5. The ECU according to any one of claims 2 to 4,

the CPU (100) starts counting of time at the time of reception of the normal data (D1), and sets the window (W) periodically by setting the window (W) from a time point (t 5) when a predetermined time (DT) elapses from the counted time to a time point (t 7) when a predetermined time (DT) elapses.

6. The ECU according to claim 4 or 5,

the predetermined time (DT) differs for each ID of the regular data (D1).

7. The ECU according to any one of claims 2 to 6,

the width of the window (W) is different for each ID of the regular data (D1).

8. The ECU according to any one of claims 1 to 7,

when the CPU (100) determines that the vehicle is in an abnormal state, the control device shifts to a safe control state by executing any one of control for stopping the engine, control for rejecting reception of data from the communication bus (20), and control for maintaining travel using the minimum gear.