ON-VEHICLE SYSTEM, PROGRAM, AND CONTROLLER

Abstract

In an on-vehicle system, the gateway is duplexed, and a countermeasure table is included. The countermeasure table defines a failure phenomenon occurring in communication, an identification method for identifying a factor on whether the failure phenomenon is caused by a failure of the gateway or caused by a security attack on the gateway, and a corresponding countermeasure method. When it is detected that a failure phenomenon has occurred is communication through the gateway, the on-vehicle system determines a factor of the detected failure phenomenon based on the identification method defined in the countermeasure table, and makes countermeasures in accordance with the corresponding countermeasure method.

Claims

1. An on-vehicle system comprising an electronic device, a gateway, and a controller enabling communication with the electronic device through the gateway, wherein the on-vehicle system has a countermeasure table, wherein the countermeasure table defines a failure phenomenon occurring in communication between the controller and the electronic device through the gateway, an identification method for identifying a factor on whether the failure phenomenon is caused by a failure of the gateway or by a security attack on the gateway, and a countermeasure method corresponding to the factor, wherein the on-vehicle system further includes another gateway, and when detected that the failure phenomenon has occurred in the communication between the controller and the electronic device through the gateway, determines the factor of the detected failure phenomenon and makes countermeasures in accordance with the countermeasure method corresponding to the determined factor, based on the identification method defined in the countermeasure table, replaces the gateway by the another gateway, when determined the factor of the failure phenomenon is caused by the failure of the gateway, and replaces the gateway by the another gateway, and disconnects the gateway from a communication path between the controller and the electronic device, when determined that the factor of the failure phenomenon is caused by a security attack on the gateway.

2. The on-vehicle system according to claim 1, wherein the countermeasure table includes a first identification method for controlling the gateway to execute self-diagnosis in accordance with the occurred failure phenomenon and for determining whether the factor of the failure phenomenon is the failure of the gateway or the security attack on the gateway, based on a result of the self-diagnosis.

3. The on-vehicle system according to claim 2, wherein the first identification method includes an identification method, for a failure phenomenon that reception. completion notification returned from the electronic device through the gateway cannot be received by the controller, for a packet transmitted from the controller to the electronic device through the gateway, for retransmitting the packet from the controller, for controlling the gateway to perform self-diagnosis in a first case where the reception completion notification has successfully been received, and for determining a failure of the gateway in a second case where the reception completion notification has not successfully been received.

4. The on-vehicle system according to claim 3, wherein the first identification method includes an identification method for counting a number of errors that the first case has occurred, continuing to use the gateway, when the number of errors does not exceed a predetermined number, if it is diagnosed that there is no problem in the gateway as a result of the self-diagnosis, and determining that there is a failure in the gateway, when the number of errors exceed a predetermined number, even if it is diagnosed that, there is no problem in the gateway as a result of the self-diagnosis.

5. The on-vehicle system according to claim 3, wherein the countermeasure table further includes a second identification method, and wherein the second identification method includes an identification method, for a failure phenomenon that reception completion notification returned from the electronic device through the gateway is received by the controller after a first predetermined time, for a packet transmitted from the controller to the electronic device through the gateway, for counting a number of delays that the failure phenomenon has occurred, and for determining that there is a failure in the gateway, when the number of delays exceeds a predetermined number, or when the reception completion notification is received beyond a second predetermined time later than the first predetermined time.

6. The on-vehicle system according to claim 1, wherein the controller is a controller for controlling a vehicle having the on-vehicle system mounted thereon to perform automatic traveling, and the electronic device is another controller for controlling various sensors mounted on the vehicle or another controller for controlling traveling of the vehicle.

7. A program, in an on-vehicle system including an electronic device, a first and a second gateways, and a controller enabling communication with the electronic device through the first or the second gateway, operable on a computer installed in the electronic device, the first or second gateway, the controller or another device, included in the on-vehicle system, wherein the program has a countermeasure table defining a failure phenomenon occurring in communication between the controller and the electronic device through the first gateway, an identification method for identifying a factor on whether the failure phenomenon is caused by a failure of the first gateway or a security attack on the first gateway, and a countermeasure method corresponding to the factor, and wherein, when it is detected that a failure phenomenon has occurred in communication between the controller and the electronic device through the first gateway, the program determines a factor of the detected failure phenomenon based on the identification method defined in the countermeasure table, and makes countermeasure in accordance with the countermeasure method corresponding, to the determined factor, replaces the first gateway by the second gateway, when it is determined the factor of the failure phenomenon is a failure in the first gateway, and replaces the first gateway by the second gateway, and disconnects the first gateway from a communication path between the controller and the electronic device, when it is determined that the factor of the failure phenomenon is a security attack on the first gateway.

8. The program according to claim 7, wherein the computer on which the program operates is installed in the controller.

9. The program according to claim 8, wherein the countermeasure table includes a first identification method for controlling the gateway to perform self-diagnosis in accordance with the occurred failure phenomenon, and for determining whether the factor of the failure phenomenon is a failure of the gateway or a security attack on the gateway, based on a result of the self-diagnosis.

10. The program according to claim 9, wherein the first identification method, for a failure phenomenon that reception completion notification returned from the electronic device through the gateway cannot be received by the controller, for a packet transmitted from the controller to the electronic device through the gateway, includes an identification method for retransmitting the packet from the controller, for controlling the gateway to perform self-diagnosis in a first case where the reception completion notification has successfully been received, and for determining that there is a failure in the gateway in a second case where the reception completion notification has not successfully been received.

11. The program according to claim 10, wherein the first identification method includes an identification method for counting a number of errors that the first case has occurred, continuing to use the gateway, when the number of errors does not exceed a predetermined number, if it is diagnosed that there is no problem in the gateway as a result of the self-diagnosis, and determining that there is a failure in the gateway, when the number of errors exceed the predetermined number, even if it is diagnosed that there is no problem in the gateway as a result of the self-diagnosis.

12. The program according to claim 10, wherein the countermeasure table further includes a second identification method, and wherein the second identification method includes an identification method, for a failure phenomenon that reception completion notification returned from the electronic device through the gateway is received by the controller after a first predetermined time, for a packet transmitted from the controller to the electronic device through the gateway, for counting a number of delays that the failure phenomenon has occurred, and for determining that there is a failure of the gateway, when the number of delays exceeds a predetermined number, or when the reception completion notification has been received beyond a second predetermined time later than the first predetermined time.

13. The program according to claim 8, wherein the controller is a controller for controlling a vehicle having the on-vehicle system mounted thereon to perform automatic traveling, and the electronic device is another controller for controlling various sensors mounted on the vehicle or another controller for controlling traveling of the vehicle, and wherein the program is executed on the computer installed in the controller, thereby performing the controlling for the vehicle to perform the automatic traveling.

14. A controller which can be mounted on an on-vehicle system and communicate with an electronic device in the on-vehicle system through the gateway or a replacement relay device for replacing the gateway, wherein the controller has a countermeasure table, wherein the countermeasure table defines a failure phenomenon occurring in communication between the controller and the electronic device through the gateway, an identification method for identifying a factor on whether the failure phenomenon is caused by a failure of the gateway or caused by a security attack on the gateway, and a countermeasure method corresponding to the factor, wherein, when it is detected that the failure phenomenon has occurred in communication between the controller and the electronic device through the gateway, the controller determines the factor of the detected failure phenomenon based on the identification method defined in the countermeasure table, and makes countermeasures in accordance with the countermeasure method corresponding to the determined factor, wherein, when the factor of the failure phenomenon is a failure of the gateway, the controller controls the gateway to be replaced by the replacement relay device, and wherein, when the factor of the failure phenomenon is a security attack on the gateway, the controller controls the gateway to be replaced by the replacement relay device, and disconnects the gateway from a communication path between the controller and the electronic device.

15. The controller according to claim 14, wherein the countermeasure table includes a first identification method for controlling the gateway to execute self-diagnosis in accordance with the occurred failure phenomenon, and for determining whether the factor of the failure phenomenon is the failure of the gateway or the security attack on the gateway, based on a result of the self diagnosis.

16. The controller according to claim 15, wherein the first identification method includes an identification method, for a failure phenomenon that reception completion notification returned from the electronic device through the gateway cannot be received by the controller, for a packet transmitted from the controller to the electronic device through the gateway, for controlling the gateway to perform self-diagnosis in a first case where the reception completion notification has successfully been received, after retransmission of the packet, and for determining that there is a failure of the gateway in a second case where the reception completion notification has not successfully been received by the controller.

17. The controller according to claim 16, wherein the first identification method includes an identification method for counting a number of errors that the first case has occurred, continuing to use the gateway, when the number of errors does not exceed a predetermined number, if it is diagnosed that there is no problem in the gateway as a result of the self-diagnosis, and determining that there is a failure in the gateway, when the number of errors does not exceed the predetermined number, even if it is diagnosed that there is no problem in the gateway as a result of the self diagnosis.

18. The controller according to claim 16, wherein the countermeasure table further includes a second identification method, and wherein the second identification method includes an identification method, for a failure diagnosis that reception completion notification returned from the electronic device through the gateway is received by the controller after elapse of a first predetermined time, for a packet transmitted from the controller to the electronic (device through the gateway, for counting a number of delays that the failure phenomenon has occurred, and determining that there is a failure in the gateway, when the number of delays exceeds a predetermined number, or when the reception completion notification has successfully been received beyond a second predetermined time later than the first predetermined time.

19. The controller according to claim 14, wherein the controller is a controller for controlling a vehicle with the on-vehicle system mounted thereon to perform automatic traveling, and the electronic device is another controller for controlling various sensors mounted on the vehicle or another controller for controlling traveling of the vehicle.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] FIG. 1 is an explanatory diagram schematically illustrating a configuration example of an on-vehicle system for realizing automatic traveling.

[0027] FIG. 2 is a flowchart illustrating a configuration example of a control flow for realizing automatic traveling in the on-vehicle system of FIG. 1.

[0028] FIG. 3 is a flow diagram illustrating an example of a complication flow for realizing automatic traveling in the on-vehicle system of FIG. 1.

[0029] FIG. 4 is an explanatory diagram illustrating an example in which an unauthorized controller is coupled to the on-vehicle system of FIG. 1.

[0030] FIG. 5 is an explanatory diagram for explaining an application example for the on-vehicle system with a countermeasure using CMAC.

[0031] FIG. 6 is a flow diagram illustrating an example of a communication flow of a case where no countermeasure is taken for the impersonation in the on-vehicle system.

[0032] FIG. 7 is a flow diagram illustrating an example of a communication flow of a case where a countermeasure is taken for the impersonation using the CMAC in the on-vehicle system.

[0033] FIG. 8 is an explanatory diagram schematically illustrating a configuration example of an on-vehicle system, according to an embodiment 1.

[0034] FIG. 9 is an explanatory diagram schematically illustrating an example of a countermeasure table mounted on the on-vehicle system of the embodiment 1.

[0035] FIG. 10 is a flowchart illustrating a self-diagnostic flow of a first gateway 21.

[0036] FIG. 11 is an explanatory diagram for explaining a problem in the on-vehicle system in which a non-duplexed gateway is mounted.

[0037] FIG. 12 is an explanatory diagram for explaining an effect that the gateway' mounted on the on-vehicle system is duplexed.

[0038] FIG. 13 is an explanatory diagram for explaining an example in which an unauthorized controller is coupled to the on-vehicle system of FIG. 8.

[0039] FIG. 14 is a flow diagram illustrating an example of a communication flow of a case where the on-vehicle system, is under a security attack.

[0040] FIG. 15 is a flow diagram illustrating an example of a communication flow of a case where a failure has occurred in a gateway 1 in the on-vehicle system.

[0041] FIG. 16 is a conceptual diagram of a security system with guaranteed functional safety, adopted in the embodiment 1.

[0042] FIG. 17 is a flowchart illustrating a configuration example of a control flow for automatic traveling, with a security manager function and a functional safety manager function embedded therein.

[0043] FIG. 18 is a flowchart illustrating a configuration example of failure diagnosis in the flow of FIG. 17.

DETAILED DESCRIPTION

[0044] Preferred embodiments will now be described. The same constituent elements are identified by the same reference numerals, and will not be described over and over.

Embodiment 1

[0045] FIG. 8 is an explanatory diagram schematically illustrating a configuration example of an on-vehicle system according to an embodiment 1. Though this system is the same as the on-vehicle system illustrated in FIG. 1, the only difference is that a gateway 2 is duplexed. In place of the gateway 2 of the on-vehicle system illustrated in FIG. 1, a first gateway 2_1 (gateway 1 in the illustration) and a second gateway 2_2 (gateway 2 in the illustration) are included. In addition, it configured that an automatic traveling controller 1 can communicate with not only various controllers inside the vehicle, but also the equipment and device outside the vehicle, through either of the first gateway and the second gateway 2_2. Other configurations are the same as those illustrated in FIG. 1, and thus will not specifically be described now. Because the gateway is duplexed, it is possible to keep a traveling operation in safety for a certain period, even when a failure has occurred in the gateway, or when the gateway cannot appropriately operate due to a security attack, such as DOS (Denial of Service).

[0046] FIG. 9 is an explanatory diagram schematically illustrating an example of a countermeasure table mounted on the on-vehicle system of the embodiment 1. The countermeasure table indicates policies that are referred by programs executed by a device in the on-vehicle system, though not particularly limited, for example, to a computer installed in the automatic traveling controller 1.

[0047] The countermeasure table defines a failure phenomenon occurring in communication between the automatic traveling controller 1 and an electronic device (for example, a sensor system controller 4) in the on-vehicle system through the first gateway 2 (the gateway 1 in the illustration) , an identification method for identifying a factor on whether the failure phenomenon is caused by a failure of the first gateway 2_1 or by a security attack, and a corresponding countermeasure method.

[0048] When it is detected that a failure phenomenon has occurred in communication between the automatic traveling controller 1 and the electronic device (for example, the sensor system controller 4) through the first gateway 21, the on-vehicle system determines a factor of the detected failure phenomenon, and carries out a countermeasure for the determined factor in accordance with a corresponding countermeasure method, based on the identification method defined in the countermeasure table. When it is determined that the factor of the failure phenomenon is a failure of the first gateway 2_1, the first gateway 2_1 is replaced by the second gateway 2_2 (the gateway 2 in the illustration). When it is determined that the factor of the failure phenomenon is a security attack on the first gateway 2_1, the first gateway 2_1 is replaced by the second gateway 2_2, and also the first gateway 2_1 is disconnected from a communication path between the automatic traveling controller 1 and the electronic device. In this case, the communication path is an on-vehicle network, for example, a CAN, the Ethernet, or FlexPay (registered trademark).

[0049] In this manner, the failure of the gateway and the security attack are distinguished, and suitable countermeasure methods are adopted respectively for the cases, thereby adequately securing the functional safety. When it is determined that the factor of the failure phenomenon is the security attack, the gateway doubted as infected with the virus by the security attack is disconnected from the on-vehicle system, thereby enabling to prevent the attack entirely on the on-vehicle system from this gateway.

[0050] FIG. 9 illustrates a specific example.

[0051] The countermeasure table includes three stages of identification methods. The third identification method is self-diagnosis by the first gateway 2_1. The on-vehicle system controls the first gateway 2_1 to carry out the self-diagnosis in accordance with the occurred failure phenomenon, determines whether the factor of the failure phenomenon is the failure of the gateway 2_1 itself or the security attack thereon or whether there is no problem thereon, based on the result of the self-diagnosis, and adopts a corresponding method based on the diagnostic result.

[0052] As a result, the factor of the failure phenomenon can accurately be determined, and the countermeasure method can adequately be determined, thereby adequately securing the functional safety.

[0053] The countermeasure table of FIG. 9 exemplarily shows a failure phenomenon that reception completion notification returned from the electronic device cannot be received by the automatic traveling controller 1 and a failure phenomenon of large delay in the reception. This notification represents that a packet (s) transmitted from the electronic device (for example, the sensor system controller 4) from the automatic traveling controller 1 through the first gateway 2_1 is completely received.

[0054] In the case of the failure phenomenon that the reception completion notification cannot be received, the automatic traveling controller 1 retransmits the packet. Upon reception of reception completion notification in response to the retransmission, the first gateway 2_1 carries out self-diagnosis. Even when reception completion notification cannot be received in response to the retransmission, it is determined that there is a failure in the first gateway 2_1 (identification method 1).

[0055] As a result of this, the failure and the security attack can be distinguished by the self-diagnosis of the gateway, without carrying out the countermeasure immediately for the failure, even without reception of the reception completion notification. This enables to adequately secure the functional safety.

[0056] Further in the above example, when reception completion notification for the first packet cannot be received, and when the reception completion notification for the retransmission packet is successfully received, the number of errors (Nerror) is counted as the error, and the countermeasure policy is changed in accordance with the number of errors.

[0057] When the number of errors (N1max) does not exceed (Nerror≦max) predetermined number (N1max), if it is diagnosed that there is no problem in the first gateway 2_1 as a result of the self-diagnosis, the number of errors (Nerror) is counted up, and the first gateway 2_1 is continuously used. As a result of the self-diagnosis, when it is diagnosed that there is a failure in the first gateway 2_1, the first gateway 1 is replaced by the second gateway 2_1 (the gateway 2 in the illustration), and a packet is transmitted through the second gateway 2_2. As a result of the self-diagnosis, when diagnosed that there is a security attack, the first gateway is replaced by the second gateway 2_2, and further the first gateway is disconnected from the communication path between the automatic traveling controller 1 and the above-described electronic device.

[0058] On the other hand, when the number of errors exceeds (Nerror>N1max) the predetermined number (N1max), even if it is diagnosed that there is no problem in the first gateway 2_1 as a result of the self-diagnosis, it is determined that there is a failure in the first gateway 2_1, and the first gateway 2_1 is replaced by the second gateway 2_2. In the case of a failure in the first gateway 2_1 and a security attack as a result of the self-diagnosis, the countermeasure method is the same as that applied for the case where the above-described number of errors does not exceed the predetermined number (N1max) (Nerror≦N1max)

[0059] As a result, until the number of (times of) errors that the reception completion notification cannot be received reaches a predetermined number, it is possible to continue the use of the gateway, as long as there is not found any problem in the gateway as a result of the self-diagnosis.

[0060] The countermeasure table of FIG. 9 exemplifies a failure phenomenon of a large delay in reception of the reception completion notification returned from the electronic device, in addition to the failure phenomenon that the notification cannot be received by the automatic traveling controller 1. More specifically, it defines a failure phenomenon that the reception completion notification returned from the electronic device through the first gateway 2_1 is delayed than a first predetermined time (non-illustrated T0max) and received by the automatic traveling controller 1. In this case, this notification is returned from the electronic device (for example, the sensor system controller 4) through the first gateway 2_1, for a packet transmitted from the automatic traveling controller 1. That is, when the delay time (Tdelay) is greater than the first predetermined time (T0max) and lower than a second predetermined time (Tmax) (T0max<Tdelay≦Tmax), the number of (times of) delays (Ndelay) is counted. When the number of delays (Ndelay) does not exceed a predetermined number of times (N2max) (Ndelay≦N2max), it is determined that there is no failure, the number of delays (Ndelay) is counted up (Ndelay=Ndelay+1), and the first gateway is continuously used. On the contrary, when the number of delays (Ndelay) exceeds the predetermined number of times (N2max) (Ndelay>N2max), or when the delay time (Tdelay) is greater than the second predetermined time (Tmax) (Tdelay>Tmax), it is determined that there is a failure in the first gateway 2_1, and the first gateway 2_1 is replaced by the second gateway 2_2.

[0061] As a result, even when the reception completion notification for the transmitted packet is largely delayed and received, the countermeasure is not performed immediately for a failure, and the failure of the gateway and the communication error are distinguished, thereby enabling to adequately secure the functional safety.

[0062] The countermeasure table of FIG. 9 exemplifies a case that the self-diagnosis of the first gateway 2_1 is not carried out, when the corresponding reception completion notification is not returned after the retransmission of the packet retransmission, and when it is largely delayed. Even in the cases, it is possible to make a change in that the self-diagnosis of the gateway 2_1 is carried out.

[0063] FIG. 10 is a flowchart illustrating a self-diagnostic flow in the first gateway 2_1 (gateway 1). The first gateway 2_1 carries out security self-diagnosis (S31) and safety self-diagnosis (S32) at the activation of the device. It determines (S33) whether there is a problem in the result of the self-diagnosis. When there is no problem, the timer starts (S39), and it waits for a self-diagnosis request from the automatic traveling controller 1 (S40 to S42)

[0064] On the contrary, when there is a problem in the result of the self-diagnosis, it informs the automatic traveling controller 1 of the result of the self-diagnosis (S34), and receives a countermeasure policy from the automatic traveling controller 1 (S35). A determination is made as to whether the received countermeasure policy includes the stop of the first gateway 2_1 (S36). If the stop is included, a stop process of the first gateway 2_1 is executed in accordance with the countermeasure policy (S37). If the received countermeasure policy does not include the stop of the first gateway 2_1, the timer starts (S39) after the process is executed in accordance with the countermeasure policy, and at waits for a self-diagnosis request from the automatic traveling controller 1 (S40 to S42).

[0065] In this case, the timer is a timer which measures the elapsed time since the self-diagnosis is executed last. In the self-diagnostic flow, a normal function process (S41) is continued, until the timer reaches a prescribed value (S42), or until a self-diagnosis request is sent from the automatic traveling controller 1 (S40). That is, when the timer reaches a prescribed value (S42), or if a self-diagnosis request is sent from the automatic traveling controller 1 (S40), the security self-diagnosis (S31) and the functional safety self-diagnosis (S32) are executed. As a result, normally, the self-diagnosis is executed at a constant period managed by the timer based on the prescribed value. If the self-diagnosis request is sent from the automatic traveling controller 1, the self-diagnosis is immediately executed even if before reaching the period.

[0066] The flow of FIG. 10 is configured with a determination (S40) as to whether the self-diagnosis request is sent from the automatic traveling controller 1, in the loop of S40 to S42. However, it may be configured with execution of the self-diagnosis in response to an interruption request from the automatic traveling controller 1.

[0067] FIG. 11 and FIG. 12 are explanatory diagrams for explaining an effect that the gateway mounted on the on-vehicle system is duplexed. FIG. 11 illustrates an on-vehicle system on which a non-duplexed gateway is mounted, while FIG. 12 illustrates an example in which the gateway is duplexed.

[0068] The automatic traveling controller 1 transmits a normal packet with an added CMAC or a dummy packet for inspection to traveling control system controllers 4 to 6 through the gateway 2, to identify that the gateway 2 and the traveling control system controllers 4 to 6 appropriately operate for reception. The traveling control system controllers 4 to 6 exemplarily represent controllers for performing some kind of communication with the automatic traveling controller 1. The controllers 4 to 6 include, for example, the sensor system controller 4, the brake/handle system controller 5, and the engine/motor system, controller 6, illustrated in FIG. 1. When the traveling control system controllers 4 to 6 are appropriately receiving the normal packet with the added CMAC or the dummy packet for inspection, another packet with an added CMAC, as packet reception completion. notification, is returned to the automatic traveling controller 1, thereby identifying the reception completion. When this packet reception completion notification is not returned or is delayed, the automatic traveling controller 1 can identify that there is some kind of problem in the communication path or in the traveling control system controllers 4 to 6 of a communication partner.

[0069] As illustrated in FIG. 11, when the gateway 2 is a single system (not duplexed), it is possible only to detect the security attack or failure. However, the traveling operation cannot be maintained, because communication with the traveling control system controllers 4 to 6 stops. As illustrated in FIG. 12, even when the gateway is duplexed, if a failure has occurred in the first gateway 2_1, or if there is a security attack thereon, the communication path is switched to the second gateway 2_2. This enables to continue the communication with the traveling control system controllers 4 to 6. Thus, the traveling operation can continue at least for a certain period of time.

[0070] FIG. 8 and FIG. 12 illustrate examples of the duplexed gateway. However, the gateway may further be multiplexed. When the first gateway is a regular system, while the second gateway is a standby system, the standby system gateway may be replaced by a replacement relay device (for example, a simple hub) having the minimum required data relay function. Even when the relay function of the replacement, relay device is inferior to the regular system, and when it has poor performance to realize the automatic traveling, it is possible to suppress the minimum required vehicle traveling control to a possible extent. By the configuration with replacement by the replacement relay device with poor performance, it is possible to suppress an increase in the cost due to the duplication. Even when the replacement is made, the minimum required vehicle traveling function is included, thereby securing the functional safety.

[0071] Descriptions will now further specifically be made to an operation of the on-vehicle system in which the gateway is duplexed, in the embodiment 1.

[0072] FIG. 13 is an explanatory diagram illustrating an example in which the unauthorized controller 9 is coupled to the on-vehicle system of FIG. 8. Though it has the same configuration as that of FIG. 8, the unauthorized controller 9 is coupled. In FIG. 13, it is coupled directly to the first gateway 1 (gateway 1). However, in fact, it is coupled to an on-vehicle network coupling, for example, the sensor system controller 4 and the first gateway 2_1. Alternatively, there is considered an attack that sends unauthorized software from the maintenance connector 3 to the already-coupled ECU. In this example, it is assumed that the attack is made by impersonation, like the case of FIG. 4.

[0073] FIG. 14 is a flow diagram illustrating an example of a communication flow of a case in which there is a security attack on the on-vehicle system. Before it is under a security attack, the automatic traveling controller 1 transmits a packet 1 to the traveling control system controllers 4 to 6 through the first gateway 2_1 (gateway 1). Then, reception completion notification of the packet 1 is returned from the traveling control system controller 4 to 6 to the automatic traveling controller 1 through the first gateway 2_1. Let it be assumed that the first gateway 2_1 is malfunctioned due to the security attack from the unauthorized controller 9, reception completion notification is not returned, because a packet 2 transmitted by the automatic traveling controller 1 is not transmitted to a normal destination from the first gateway 2_1. After this, though the automatic traveling controller 1 retransmits the packet 2, no reception completion notification is returned yet. Now, the automatic traveling controller 1 requests the first gateway 2_1 to execute self-diagnosis. As a result of the self-diagnosis by the first gateway 2_1, if it reports that the virus has been detected, the automatic traveling controller 1 transmits a disconnection instruction of the first gateway 21 to the traveling control system controllers 4 to 6 as the communication partners through the first gateway and the second gateway to disconnect the first gateway from the network. After this, the automatic traveling controller 1 transmits the packet 2 to the traveling control system controllers 4 to 6 through the second gateway as a replacement of the first gateway 2_1. Then, traveling control is restarted, upon returning of reception completion notification from the traveling control system controllers 4 to 6 through the second gateway 2_2.

[0074] FIG. 15 is a flow diagram illustrating an example of a communication flow of a case where a failure has occurred in the gateway 1 in the on-vehicle system. Until occurrence of a failure in the first gateway 2_1 (gateway 1), like the case of FIG. 14, the automatic traveling controller 1 transmits the packet 1 to the traveling control system controllers 4 to 6 through the first gateway 2_1, and then reception completion notification of the packet. 1 is returned from the traveling control system controllers 4 to 6 to the automatic traveling controller 1 through the first gateway 2_1. Upon occurrence of a failure in the first gateway 2.sub.≦1, no reception completion notification is returned, because the packet 2 transmitted by the automatic traveling controller 1 is not transmitted to a normal destination from the first gateway 2_1. After this, though the automatic traveling controller 1 retransmits the packet 2, no reception completion notification is returned yet. Now, the automatic controller 1 requests the first gateway 2_1 to execute self-diagnosis. As a result, of the self-diagnosis by the first gateway 2_1, if it reports that a failure has occurred, the automatic traveling controller 1 transmits the packet 2 to the traveling control system controllers 4 to 6 through the second gateway 2_2 as a replacement of the first gateway 2l. Then, traveling control is restarted, upon returning of reception completion notification from the traveling control system controllers 4 to 6 through the second gateway 2_2. Unlike the case of the security attack illustrated in FIG. 14, the automatic traveling controller 1 does not transmit a disconnection instruction for disconnecting the first gateway from the network.

[0075] Accordingly, in the embodiment 1, the security attack and the failure are distinguished, the countermeasure policies are defined appropriately for both cases, and the countermeasure methods are executed in accordance with them.

[0076] FIG. 16 is a conceptual diagram of a security system with guaranteed functional safety, adopted in the embodiment 1. A security policy and a safety policy correspond to the countermeasure table illustrated in FIG. 9. A security manager function (“security function” in the illustration) is for determining it from a viewpoint of security. A functional safety manager function (“safety function” in the illustration) is for determining it from a viewpoint of functional safety. The first and second gateways 2_1 and 2_2 (the gateway 1 and the gateway 2) and the traveling control system. controllers 4 to 6 include both the security manager function (“security function”) and the functional safety manager function (“safety function”). However, the automatic traveling controller 1 in the high rank includes only the functional safety manager function (“safety function”).

[0077] As a result, the failure of the gateway and the security attack can be distinguished. It is also possible to adopt an adequate countermeasure method for each case, thereby appropriately securing the functional safety.

[0078] The security manager function and the functional safety manager function are provided in the form of programs, operating on a computer, for example, a micro controller installed in the devices. The functions are realized by referring to the security policy or the safety policy stored in the memory unit in the form of the countermeasure table as illustrated, for example, in FIG. 9.

[0079] In the embodiment 1, the functional safety manager function in the high rank is mounted on the automatic traveling controller 1. However, the functional safety manager function in the high rank may be mounted on another electronic device. For example, it may be mounted on both the duplexed gateways 2_1 and 2_2. One of the functional safety manager functions may be configured to stop with replacement from one to the other, and to be replaced by the functional safety manager function in the high rank, included in the other getaway.

[0080] In the embodiment 1, the automatic traveling controller 1 has been described as one including only the functional safety manager function, by way of example. However, the automatic traveling controller 1 may be configured to include the security manager function and the functional safety manager function in the low rank, and may further include the functional safety manager function in the high rank.

Embodiment 2

[0081] In the automatic traveling control flow in the automatic traveling controller 1, the security manager function and the functional safety manager function may be embedded.

[0082] FIG. 17 is a flowchart illustrating a configuration example of a control flow for the automatic traveling, with the security manager function and the functional safety manager function embedded therein. FIG. 18 is a flowchart illustrating a configuration example of failure diagnosis in the flow of FIG. 17.

[0083] When an automatic traveling function is selected, like the case of FIG. 2, the automatic traveling controller 1 activates the function of camera/peripheral object sensor/GPS, and establishes coupling to the external information server 20 (S1). Next, it detects the position, the speed, and the peripheral object of the own vehicle, based on data collected from the camera 11, the peripheral sensor 12, and the speed sensor 13 and information supplied from the external information server (S2). The automatic traveling controller 1 executes the following controlling based on the information items, thereby realizing the automatic traveling. That is, it, determines whether there is an obstacle (S3) When determined that there is an obstacle, it executes coins ion avoidance control for avoiding the obstacle, by slowing down the vehicle and the handle operation (S4). It calculates the distance to the preceding vehicle, and determines whether the distance between the vehicles is sufficiently secured (S5). When the distance is not sufficiently secured, it executes an inter-vehicle distance securing control for slowing down the vehicle (S6). It obtains the speed of the own vehicle, and determines whether the speed is within a set speed range (S7). When it determines that the speed is outside the set speed range, it executes speed control for slowing down or accelerating the vehicle (S8). It determines whether the own vehicle is adequately travelling in the lane, based on the peripheral images of the own vehicle which are obtained by the camera 11 (S9). When it determines that the own vehicle is outside the lane or may possibly be outside the lane, it executes lane returning control by handle operation (S10).

[0084] Unlike the case of FIG. 2, the assumption is made to a case where it is not possible to normally execute the collision avoidance control (S4), the inter-vehicle distance securing control (S6), the speed control (S8), and the lane returning control (S10).

[0085] In spite that the collision avoidance control (S4) has been performed, when determined that it is not possible to avoid collision (S11), emergency stop control for stopping the vehicle is performed by making an emergency brake operation (S12). Even when determined that it is not possible to avoid collision (S11), it may be configured to execute the emergency stop control (S12), only if it is not possible to avoid collision after retrying the collision avoidance control (S4) repeatedly a few times, instead of performing the emergency stop control (S12) immediately after that. Also in the case where there is made no clear determination about the possibility of the avoidance in S11, the emergency stop control (S12) may be performed, only if it is easily possible to avoid collision after retrying the collision avoidance control (S4) repeatedly a few times.

[0086] In spite that the inter-vehicle distance securing control (S6) is performed, when determined that it is not possible to slow down (S13), the failure diagnosis (S20) is performed. This failure diagnosis (S20) may be started immediately after the determination that the slowing down is impossible, or the failure diagnosis (S20) may be performed only if the slowing down is impossible after the retry of slowing down a few times. Though the slowing down is operated, when it is not sufficient, the failure diagnosis (S20) may be performed only if the slowing down is not sufficiently performed after the retry of slowing down a few times.

[0087] In spite that the speed control (S8) is performed, also when the determination (S14) is made that the speed is outside the range of the set speed, the failure diagnosis (S20) is performed. This failure diagnosis (S20) may be started immediately after the determination that the sped is outside the range of the set speed, or may be performed (S20) only if the speed is still outside the set speed after the retry is performed repeatedly a few times. Though the acceleration of or slowing down the vehicle is performed by the speed control (S8), also when the variation speed ratio is not sufficient, the failure diagnosis (S20) may be performed only if the speed is outside the range of the set speed after the retry is performed repeatedly a few times.

[0088] In spite that the lane returning control (S10) is performed, when determined that the vehicles in the desired lane for traveling (S15), the failure diagnosis (S20) is performed. This failure diagnosis (S20) may be started immediately after the determination that the vehicle is outside the lane, or may be performed only if it is still outside the lane even after the retry is performed repeatedly a few times. Though the vehicle is controlled to a direction for returning back to the target lane for traveling by the lane returning control (S10), when no improvement is recognized in an evaluation value (lane out-range value) representing an extent that the vehicle is outside the lane, the failure diagnosis (S20) may immediately be performed. When the improvement is recognized, though not enough, the failure diagnosis (320) may be performed only if the vehicle is outside the lane after the retry is performed repeatedly a few times.

[0089] Further, the failure diagnosis (S20) is executed also when. another failure is suspected (S16). The case where another failure is suspected (S16) implies a case where the failure is suspected by the same simple failure diagnosis as the case where the automatic traveling control is not performed. A simple self-diagnosis function is included in each of the units mounted on the on-vehicle system, for example, the sensor system controller 4, the brake/handle system controller 5, and the engine/motor system controller 6. This simple self-diagnosis function is realized by the semiconductor chip (for example, a micro controller and a semiconductor memory) mounted on each controller. In S16, a determination is made as to whether the failure diagnosis (S20) is performed, in consideration of not only the result of the simple self-diagnosis result, but also the function impossibility information from each controller, or the diagnosis result by a source control IC (Integrated Circuit) or the off-chip sensor including a temperature sensor.

[0090] In the failure diagnostic process illustrated in FIG. 18, the failure diagnosis is performed (S21). Specifically, for example, specific diagnosis including BIST (Built In Self-Test) is performed to specify any of those failure positions. Further, it is performed by a virus checker in each controller, and a check periodically made whether there is a secure boot function of the programs and whether there is suspicious data stored in the memory.

[0091] As a result of the failure diagnosis (S21), when it is determined that there is no problem to such an extent of disturbing the automatic traveling (S22), the automatic traveling control continues (S25). When determined that there is a problem, it requests the driver to cancel the automatic traveling function (S23). After this, a predetermined cancellation waiting time is waited, and it is determined whether the automatic traveling function is cancelled (S24). When the cancellation is made, it is returned to the normal traveling (S26). When the cancellation is not made, the vehicle is brought to an emergency stop (S27). The emergency stop includes, for example, controlling of the vehicle to stop on the road shoulder by an emergency brake operation, and to stop the engine.

[0092] In the determination (S16) as to whether there is another failure, the traffic (that is, the number of packets) in the communication path (for example, the CAN) in the on-vehicle system is monitored in, for example, the background. Also in the case where the number of packets is out of an assumed range, the failure diagnosis (S20) may be performed. In the failure diagnosis (S21), the unauthorized program is eliminated, and its result is judged. When it is not possible to return to the normal state, the flow may proceed to the cancellation request (S23) for requesting the next driver to cancel the automatic traveling function.

[0093] Accordingly, the descriptions have specifically been made to the present invention made by the present inventors. However, needless to say, the present invention is not limited to the above, and various changes may be made without departing from the scope thereof.