JP6969450B2 - Network system - Google Patents

Description

This disclosure relates to a network system.

An information processing device has been proposed in which a general-purpose processing CPU is configured to execute data encryption, decryption, authentication, etc. instead of the security processing CPU even if the security processing CPU fails (for example, a patent). See Document 1).

Japanese Unexamined Patent Publication No. 2015-119357

However, in the information processing apparatus described in Patent Document 1, if a part other than the security processing CPU in the cryptographic hardware fails, there is a possibility that data authentication or the like cannot be executed. For example, in the information processing device described in Patent Document 1, when the secure storage device fails, an error occurs in the access from the general-purpose processing CPU to the secure storage device, and the general-purpose processing CPU generates data. There is a risk that authentication etc. cannot be executed.

In one aspect of the present disclosure, it is desirable to provide a network system capable of executing data authentication by a method different from the above-mentioned prior art when data authentication fails.

One aspect of the disclosure is a network system. The network system includes a plurality of electronic devices (2A, 2B, 2C, 2D). The plurality of electronic devices are configured to function as nodes of the first network (1A) and also as nodes of the second network (1B) constructed independently of the first network. The plurality of electronic devices are configured to be able to communicate with the first network and external devices outside the second network via the first network.

At least one of the plurality of electronic devices is configured to be functional as a requesting device (2B). At least one of the plurality of electronic devices is configured to be functional as a requested device (2C). When one of the plurality of electronic devices functions as the requesting device, at least one electronic device different from the requesting device is configured to be able to function as the requesting device.

When the authentication target data to be authenticated is transmitted to the requesting device via the first network, the requesting device receives the authentication target data and executes the authentication processing for the authentication target data (the requesting device receives the authentication target data). S124, S142-S150). If the authentication is successful, the requesting device uses the content of the authentication target data in the processing after the successful authentication (S128). If the authentication fails, the requesting device sends proxy request data for requesting the requesting device to perform authentication processing to the requesting device via the second network, and is in a non-requested state. It is configured to shift to the request state from (S130-S134).

After receiving the proxy request data, the request destination device shifts from the non-proxy state to the proxy state (S204-S206, S222), and each time the authentication target data is transmitted to the request source device via the first network. , Receives the authentication target data (S302, S306, S308, S322, S324) and executes the authentication process for the authentication target data (S326). When the authentication is successful, the request destination device is configured to transmit the authenticated data including the contents of the authentication target data for which the authentication is successful to the request source device via the second network (S328, S330). ). When the request source device shifts to the request state, it is configured to receive the authenticated data (S402) and use the contents of the authentication target data included in the authenticated data (S406, S430).

The requesting device is configured to return from the requested state to the non-requested state when the proxy cancellation request data is transmitted from the external device (S108), if it is in the requested state (S110, S166, S172). , S421, S414, S442, S446, S448). The request destination device is configured to return from the proxy state to the non-proxy state when the proxy cancellation request data is transmitted from the external device (S208) (S208). S248).

According to the network system configured in this way, even if the authentication target data fails to be authenticated in the requesting device, if the authentication target data is successfully authenticated in the requesting device, the requesting device is included in the authenticated data. The authentication target data can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the requesting device, the requesting device can use the authenticated authentication target data. ..

In addition, after receiving the proxy request data, the request destination device receives the authentication target data and executes the authentication process for the authentication target data every time the authentication target data is transmitted to the request source device via the first network. Then, the authenticated data is sent to the requesting device. Therefore, the requesting device can continuously receive the authenticated data from the requesting device without transmitting the proxy request data to the requesting device each time the authentication target data is received. Therefore, the load on the requesting device can be reduced as compared with the case where the requesting device is configured to send the proxy request data to the requesting device each time it receives the authentication target data. In addition, the load on the network can be reduced as the frequency of transmission of proxy request data decreases.

Further, the requesting device returns from the requested state to the non-requested state if it is in the requested state when the proxy cancellation request data is transmitted from the external device. When the requesting device is in the proxy state when the proxy stop request data is transmitted from the external device, the request destination device returns from the proxy state to the non-proxy state. Therefore, when the cause of the need for proxy processing is resolved by repair, etc., the requesting device and the requesting device can be easily put into a normal state by transmitting the proxy stop request data from the external device. Can be returned to. As a result, the load caused by the proxy of the authentication process is not applied to the electronic device, and the load on the system can be reduced.

The above-mentioned authentication target data, proxy request data, authenticated data, and proxy cancellation request data may be data transmitted in one transmission unit, or may be divided into a plurality of transmission units and sequentially. It may be data to be transmitted. When the data is divided into multiple transmission units and transmitted sequentially, each time one unit of data is transmitted from the transmitting side to the receiving side, the data reception of one unit of data is completed from the receiving side to the transmitting side. Data indicating that this has been done may be transmitted. That is, other data may be transmitted between the start of transmission of the authentication target data, the proxy request data, and the authenticated data and the completion of transmission.

In addition, the reference numerals in parentheses described in this column and the scope of claims are described in order to make it easier to understand the correspondence with the specific configuration exemplified as one embodiment in the embodiment described later. The description does not mean that the technical scope of the present disclosure is limited to the same scope as the embodiments described below.

FIG. 1 is an explanatory diagram showing a network system. FIG. 2 is an explanatory diagram showing an ECU. FIG. 3 is an explanatory diagram showing the structure of data transmitted in the network. FIG. 4 is a flowchart of a process executed when the ECU, which is the requesting device, receives data from the global bus. FIG. 5 is a flowchart of processing corresponding to the authentication target data. FIG. 6 is a flowchart of the message authentication process. FIG. 7 is a flowchart of the process corresponding to the proxy cancellation request. FIG. 8 is a flowchart of processing executed when the ECU serving as the request destination device receives data from the local bus. FIG. 9 is a flowchart of the process corresponding to the proxy request data. FIG. 10 is a flowchart of the process corresponding to the authentication establishment notification in the first embodiment. FIG. 11 is a flowchart of a process executed when the ECU, which is the request destination device in the first embodiment, receives data from the global bus. FIG. 12 is a flowchart of processing corresponding to data addressed to another ECU. FIG. 13 is a flowchart of processing executed when the ECU, which is the requesting device, receives data from the local bus. FIG. 14 is a flowchart of the process corresponding to the authenticated data. FIG. 15 is a flowchart of the process corresponding to the notification of the proxy execution ID. FIG. 16 is a flowchart of the process corresponding to the authentication establishment notification in the second embodiment. FIG. 17 is a flowchart of a process executed when the ECU, which is the request destination device in the second embodiment, receives data from the global bus. FIG. 18 is a flowchart of the process corresponding to the proxy cancellation request.

Next, the above-mentioned network system will be described with reference to exemplary embodiments.
(1) First Embodiment [Network system configuration]
The network system 1 shown in FIG. 1 is, for example, an in-vehicle network system mounted on an automobile. The network system 1 has a plurality of ECUs 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H, CGW4, a plurality of global buses 5A, 5B, 5C, a local bus 6, and the like. ECU is an abbreviation for "Electronic Control Unit". CGW is an abbreviation for "Central Gateway".

The ECUs 3A, 3B, 2A, and 2B are connected to the global bus 5A. The ECUs 2C, 2D, 3C, and 3D are connected to the global bus 5B. The ECUs 3E, 3F, 3G, and 3H are connected to the global bus 5C. For example, ECUs functionally classified into the same system are connected to each of the global buses 5A to 5C. For example, a body ECU is connected to the global bus 5A. A control system ECU is connected to the global bus 5B. An information system ECU is connected to the global bus 5C.

The global buses 5A to 5C are connected to each other via CGW4. With these configurations, the ECUs 2A to 2D, the ECUs 3A to 3H, the CGW 4 and the global buses 5A to 5C constitute the first network 1A. The ECUs 2A to 2D are connected to the local bus 6. As a result, the ECUs 2A to 2D and the local bus 6 constitute the second network 1B. That is, the ECUs 2A to 2D are configured to function as the nodes of the first network 1A and also to function as the nodes of the second network 1B. The ECUs 2A to 2D configured in this way correspond to the electronic devices referred to in the present disclosure.

In the first network 1A and the second network 1B, data is transmitted by broadcast communication to the nodes constituting each network. However, the first network 1A and the second network 1B are independent networks. Therefore, for example, even when data is transmitted in the first network 1A, the data is not transmitted to the second network 1B. Similarly, even if data is transmitted in the second network 1B, the data is not transmitted to the first network 1A.

The CGW 4 intervenes between the global buses 5A to 5C and relays data from one of the global buses to the remaining global buses. Further, the CGW 4 is configured to be connectable to the external communication path 7, and relays data between the external communication path 7 and the global buses 5A to 5C. As a result, the ECUs 2A to 2D and the ECUs 3A to 3H can communicate with the external device (for example, the external tool 9 exemplified in FIG. 1) via the first network 1A. The external tool 9 is a device used when performing a vehicle failure diagnosis or the like in an automobile dealer or the like. In the present embodiment, it is used as a device for transmitting a command to the ECUs 2A to 2D and the like in the process described later. The second network 1B is not provided with a node that can be connected to an external communication path. Therefore, the node of the second network 1B cannot communicate with the external device via the second network 1B.

The external communication path 7 may be at least one of a wireless communication path and a wired communication path. Further, the external communication path 7 may be at least one of a communication path that can be connected to a single device and a communication path that can be connected to a plurality of devices. The communication path that can be connected to a plurality of devices may be, for example, a communication path that can be connected to an external network that includes a plurality of devices as nodes. The external communication path 7 may be entirely composed of a dedicated line or partially composed of a public line.

In this embodiment, the above three global buses 5A to 5C are illustrated, but the number of global buses is arbitrary. For example, the number of global buses may be two or less or four or more. In this embodiment, the above twelve ECUs 2A to 2D and ECUs 3A to 3H are exemplified, but the number of ECUs is arbitrary. For example, the number of ECUs may be 11 or less or 13 or more. In the present embodiment, the examples in which the ECUs 2A to 2D are connected to the local bus 6 are shown, but at least one of the ECUs 3A to 3H may be connected to the local bus 6. Alternatively, at least one of ECUs 3A to 3H may be connected to a local bus different from the local bus 6.

[ECU configuration]
Next, the internal configuration of the ECU will be described. In the following description, the ECU 2B shown in FIG. 2 will be taken as an example. However, in the present embodiment, the ECUs 2A, 2C, and 2D are configured in the same manner as the ECU 2B. Further, in the present embodiment, the ECUs 3A to 3H are different from the ECU 2B in that they are not connected to the second network 1B, but are configured in the same manner as the ECU 2B in other points.

As shown in FIG. 2, the ECU 2B includes a CPU 11, a RAM 12, a flash memory 13, a first communication unit 16, a second communication unit 17, and the like. The first communication unit 16 is a network interface for connecting to the global bus 5A. The second communication unit 17 is a network interface for connecting to the local bus 6. The various functions of the ECUs 2A to 2D are realized by the CPU 11 executing various processes according to a program stored in the non-transitional substantive recording medium. In this example, the flash memory 13 corresponds to a non-transitional substantive recording medium.

When the CPU 11 executes various processes according to the program, the program stored in the flash memory 13 may be configured to be loaded into the main memory configured by the RAM 12. In this case, the CPU 11 executes various processes according to the program stored in the main memory. When the CPU 11 executes various processes according to the program, the method corresponding to the program is executed, and various functions included in the ECUs 2A to 2D are realized. However, the method for realizing various functions included in the ECUs 2A to 2D is not limited to software, and some or all of the functions may be realized by using hardware in which a digital circuit, an analog circuit, or the like is combined.

Various storage areas are secured in the RAM 12 and the flash memory 13. As the main storage area related to the present embodiment, the reception data buffer 12A is secured in the RAM 12. A common key storage unit 13A and a CVN storage unit 13B are secured in the flash memory 13. The reception data buffer 12A is a buffer for temporarily storing data received via the first network 1A.

The received data is sequentially stored in the reception data buffer 12A, and when the storage area is full, new data is overwritten and stored in the area in which the oldest data is stored. The size of the reception data buffer 12A is such that at least a certain period of data (for example, 20 milliseconds) can be reliably stored in consideration of the situation where the amount of data received via the first network 1A is maximized. The size is secured.

The common key storage unit 13A stores a common key used when executing message authentication for received data in a process described later. The CVN storage unit 13B stores a list of CVNs required for confirming whether or not the data transmission source is a legitimate request destination device in the process described later. CVN is an abbreviation for "Calibration Verification Numbers". The CVN is a collation code generated based on software mounted on the ECU or the like.

It is obligatory by laws and regulations to equip the ECU mounted on the vehicle with a function of generating and outputting a CVN. When a plurality of ECUs mounted on a vehicle generate CVNs, different CVNs are generated for each ECU. In the present embodiment, the CVNs generated and output by the ECUs 2A to 2D are collected and listed at the time of vehicle production and stored in the CVN storage unit 13B.

When the software mounted on the ECU is updated or the software mounted on the ECU is tampered with, the CVN generated in the ECU changes. Therefore, the CVN stored in the CVN storage unit 13B at the time of vehicle production is compared with the CVN output from the ECU, and if the comparison results do not match, the ECU that outputs the CVN is replaced or the software is tampered with. I can suspect that it was there. When the software mounted on the ECU is properly updated, the CVN stored in the CVN storage unit 13B may be updated by the CVN output from the updated ECU.

[Overview of authentication process]
The node of the first network 1A can receive the data arriving via the external communication path 7. Therefore, it is important to take appropriate measures against such malicious data, assuming that malicious and unauthorized data may be transmitted from an unauthorized external device connected to the external communication path 7, for example. Become. Further, even when the program is falsified in the ECUs 2A to 2D and the ECUs 3A to 3H, or when the program is replaced with an illegal ECU, the illegal data transmitted from such an illegal ECU is dealt with. It is important to take appropriate measures.

Therefore, in the network system 1 of the present embodiment, the ECUs 2A to 2D and the ECUs 3A to 3H execute the authentication process when the data is received via the first network 1A, and confirm the validity of the data. In the present embodiment, the ECUs 2A to 2D and the ECUs 3A to 3H confirm the validity of the data by message authentication. As shown in FIG. 3, the data D1 transmitted in the first network 1A includes an ID, normal data, encrypted data, and the like. Although the data D1 includes control codes, data, and the like other than these, the description thereof will be omitted because they are not related to this processing.

The ID is an identifier that can include various information such as information indicating the type of data, information indicating the content of data, information indicating the node of the source, information indicating the node of the destination, and information indicating the priority during communication. Is. The data D1 transmitted from the source node to the first network 1A by broadcast communication is received by all the nodes other than the source node in the first network 1A. The node that has received the data D1 can determine whether or not the data should be processed based on the ID included in the data D1.

Normal data is the actual part of the data that the source node attempts to send to the destination node. The encrypted data is data obtained by encrypting normal data by a predetermined encryption method using a common key commonly used by the nodes of the first network 1A. The common key is stored in the above-mentioned common key storage unit 13A. The encrypted data included in the data D1 is obtained by encrypting normal data using a common key at a source node that transmits the data D1 and extracting a part of the encrypted data. The reason for extracting a part of the encrypted data is to reduce the amount of data. If it is not necessary to reduce the amount of data, all of the encrypted data may be used as encrypted data.

When performing message authentication on the node that has received the data D1 as described above, the normal data contained in the data D1 is taken out, the taken out normal data is encrypted by the same procedure as the source node, and the encryption is performed. Extract a part of the converted data. Since the encrypted data generated in the receiving node in this way is generated using the same common key as the source node, it usually matches the encrypted data contained in the data D1.

However, if the normal data is falsified during transmission or if the data is garbled, the encrypted data generated by the receiving node and the encrypted data contained in the data D1 will not match. Alternatively, if an unauthorized node that does not know the common key sends data, proper encrypted data cannot be generated, so the encrypted data generated by the receiving node and the encrypted data contained in the data D1 do not match. Become. Therefore, on the receiving side node, if the cryptographic data generated by the receiving side node and the cryptographic data contained in the data D1 match, it is determined that the authentication has been established. On the other hand, if the encrypted data generated by the receiving node and the encrypted data contained in the data D1 do not match, it is determined that the authentication has failed.

Further, in the network system 1 of the present embodiment, the ECUs 2A to 2D can transmit data via the second network 1B. However, unlike the first network 1A, the second network 1B is a network isolated from the outside of the second network 1B. Therefore, unlike the first network 1A, illegal data is not transmitted from at least the outside of the second network 1B.

Therefore, when the ECUs 2A to 2D receive the data via the second network 1B, they do not execute the authentication process unlike the case of the first network 1A. Therefore, as shown in FIG. 3, the data D2 transmitted in the second network 1B includes ID, normal data, and the like, but does not include encrypted data.

[Authentication agency mechanism]
When the authentication is successful in the above-mentioned authentication process, the ECUs 2A to 2D and the ECUs 3A to 3H use the above-mentioned data D1 in the process after the authentication is successful. To give a specific example, for example, normal data is taken out from the data D1, and arithmetic processing using the normal data as a variable, control based on the normal data, branch processing in which judgment is divided according to the normal data, and the like are executed. ..

On the other hand, among the ECUs 2A to 2D and the ECUs 3A to 3H, the ECUs 2A to 2D request the other ECU to perform the authentication on behalf of the other ECU when the authentication fails in the above-mentioned authentication process. This is because the authentication may have failed not because the data D1 is invalid but because of a failure of the ECU that executes the authentication process. The ECU that fails in authentication becomes the requesting device when the authentication fails.

Here, the description will be continued on the assumption that the ECU 2B fails in authentication in the authentication process and becomes the requesting device. The ECU 2B that has become the requesting device selects the requesting device from the ECUs 2A, 2C, and 2D (that is, an ECU other than the requesting device). Here, the description will be continued on the assumption that the ECU 2B selects the ECU 2C as the request destination device. The ECU 2B, which is the request source device, requests the proxy of the authentication process by transmitting data to the ECU 2C selected as the request destination device via the second network 1B.

In the following description, the data D1 that is received by the requesting device via the first network 1A and is the target of the authentication process is referred to as the authentication target data. Further, in order to request the proxy of the authentication process, the data transmitted from the request source device to the request destination device via the second network 1B is referred to as proxy request data. In the case of the present embodiment, the proxy request data and which ECU is selected as the request destination device are indicated by the ID in the proxy request data.

Specifically, as the ID indicating that the data is the proxy request data, a plurality of IDs associated with each of the ECUs 2A to 2D that can be selected as the request destination device are prepared. When requesting the ECU 2C to perform the authentication process on behalf of the user, an ID corresponding to the ECU 2C is selected, and the proxy request data including the ID is transmitted to the second network 1B by broadcast communication.

When the ECU 2C receives the proxy request data, it recognizes that the ECU 2C has been selected as the request destination device based on the ID included in the data, and executes the process as the request destination device as an opportunity. The ECUs 2A and 2D also receive the proxy request data transmitted from the ECU 2B. However, since it can be determined that the data does not need to be dealt with by the ECUs 2A and 2D based on the ID included in the data, the processing after the determination is not executed.

The ECU 2C, which is the request destination device, executes an authentication process by message authentication for the authentication target data. In the present embodiment, the ECU 2C has the reception data buffer 12A as described above, and stores the data received via the first network 1A in the reception data buffer 12A for a certain period of time. Therefore, when the ECU 2C receives the proxy request data, the ECU 2C searches for the target authentication target data from the received data buffer 12A based on the information contained in the proxy request data, and performs the authentication process for the authentication target data. Run. Instead of using the reception data buffer 12A as described above, the authentication target data may be provided from the ECU 2B to the ECU 2C.

When the authentication target data is successfully authenticated in the request destination device ECU 2C, the ECU 2C transmits the authenticated data including the content of the authentication target data that has been successfully authenticated to the ECU 2B via the second network 1B. The authentication data is indicated by the ID in the authenticated data. The ECU 2B, which is the requesting device, can recognize that the authentication at the requesting device has succeeded by receiving the authenticated data. Therefore, when the ECU 2B receives the authenticated data, the ECU 2B can execute the desired processing by using the authentication target data included in the authenticated data.

Therefore, according to the network system 1 configured in this way, even if the authentication of the authentication target data fails in the ECU 2B, if the authentication target data is successfully authenticated in the ECU 2C, the ECU 2B is the authentication target included in the authenticated data. Data can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the ECU 2B, the ECU 2B can use the authenticated authentication target data.

[Details of processing executed in the requesting device and the requesting device]
Next, the processes executed in the request source device and the request destination device described above will be described with reference to the flowcharts shown in FIGS. 4 to 15. Here, as in the example given above, the description will be continued assuming that the ECU 2B is the requesting device and the ECU 2C is selected as the requesting device. First, the processes shown in FIGS. 4 to 7 will be described. The processes shown in FIGS. 4 to 7 are processes executed when data is received from the global bus 5A in the ECU 2B.

As shown in FIG. 4, the ECU 2B receives data from the global bus 5A in S102. Subsequently, the ECU 2B determines in S104 whether or not the data received from the global bus 5A is the authentication target data. The authentication target data is data transmitted to the first network 1A by an ECU other than the ECUs 2B and 2C by broadcast communication. Here, as an example, it is assumed that the ECU 3H has transmitted the authentication target data, and the following description will be continued. When the ECU 3H transmits the authentication target data, the authentication target data reaches all the nodes other than the ECU 3H in the first network 1A. The node that has received the authentication target data determines whether or not the data should be processed based on the ID included in the authentication target data. Further, in the case of the present embodiment, at least in the ECUs 2A to 2D, when the authentication target data is received, the authentication target data is stored in the received data buffer 12A.

In S104, if the data is the authentication target data, it is determined as YES, and the process proceeds to S106. In S106, the ECU 2B executes the process corresponding to the authentication target data. Details of S106 are shown in FIG. When the process shown in FIG. 5 is started, in S122, the ECU 2B determines whether or not the proxy requested flag is off. The proxy request flag is a flag whose initial value is turned off and is turned on in S134 described later when the ECU 2B requests another ECU to perform authentication on behalf of the ECU 2B in the process described later. Here, the description will be continued assuming that the proxy requested flag is set to the initial value (that is, off).

If the proxy request flag is off, it is determined to be YES in S122, and the process proceeds to S124. In S124, the ECU 2B executes the message authentication process. The details of this message authentication process are shown in FIG. When the message authentication process is started, the ECU 2B retrieves the normal data and the encrypted data included in the data to be processed in S142 as shown in FIG. The data to be processed here is the authentication target data received in S102.

Subsequently, the ECU 2B encrypts the normal data with the common key in S144 to generate the encrypted data. The data encrypted here is normal data extracted from the data to be processed in S142. Subsequently, the ECU 2B determines in S146 whether or not the received encrypted data and the generated data match. If the received encrypted data and the generated data match, it is determined as YES in S146, and the process proceeds to S148.

If the process proceeds to S148, the authentication is established in the ECU 2B, the process shown in FIG. 6 is terminated, and the process proceeds to S126 of FIG. On the other hand, if the received encrypted data and the generated data do not match, NO is determined in S146, and the process proceeds to S150. If the process proceeds to S150, the authentication fails in the ECU 2B, the process shown in FIG. 6 is terminated, and the process proceeds to S126 of FIG.

The ECU 2B determines in S126 whether or not the authentication has been established. If the authentication is established in S148 described above, it is determined to be YES in S126, and the process proceeds to S128. In S128, the ECU 2B takes out the normal data included in the authentication target data and uses it in the subsequent processing. As the "subsequent processing" referred to here, various processing according to the function of the ECU 2B can be considered, but since the processing itself is not a main part in the present embodiment, further description thereof will be omitted. After the execution of S128, the process shown in FIG. 5 is terminated. As a result, S106 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated.

On the other hand, if the authentication fails in S150 described above, it is determined as NO in S126, and the process proceeds to S130. In S130, the ECU 2B takes out the ID included in the authentication target data and discards the other parts. Subsequently, the ECU 2B creates proxy request data including the extracted ID in S132, sets an ID for making an authentication proxy request to one request destination device in the proxy request data, and sets the proxy request data locally. Send to bus 6.

In the present embodiment, as described above, it is assumed that the ECU 2C is selected as the requested device. Therefore, in S132, an ID for making an authentication proxy request to the ECU 2C is set in the proxy request data. As the ID for making the authentication proxy request, a plurality of different IDs are prepared in advance for each ECU that can be the request destination device. As will be described in detail later, when the ECU 2B requests the ECU 2C to perform authentication on behalf of the ECU 2C in S132, the ECU 2B will receive the authenticated data from the ECU 2C thereafter.

After finishing S132, the ECU 2B subsequently turns on the proxy request flag in S134. The proxy request flag is turned on in S134 when the ECU 2B requests the ECU 2C to proxy authentication in S132. After the execution of S134, the process shown in FIG. 5 is terminated. As a result, S106 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated.

The process shown in FIG. 4 is executed in the ECU 2B each time the ECU 2B receives data from the global bus 5A. When the authentication target data is received multiple times while the process shown in FIG. 4 is executed multiple times, when the proxy requested flag is turned on in S134, the process shown in FIG. 4 is executed next. In that case, it is determined as NO in S122. In this case, the ECU 2B discards the received data in S136. When S136 is finished, the process shown in FIG. 5 is finished. As a result, S106 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated.

In S104, if the data is not the authentication target data, it is determined as NO, and the process proceeds to S108. However, since it is easier to understand S108 and S110 after explaining other parts, the explanation here is withheld and will be described in detail later. If NO is determined in S108, the process proceeds to S112. In S112, the ECU 2B executes a process corresponding to other received data. As the process executed in S112, various processes depending on the function of the ECU 2B can be considered, but since the process itself is not a main part in the present embodiment, further description thereof will be omitted. After the execution of S112, the process shown in FIG. 4 is terminated.

Next, the processes shown in FIGS. 8 to 10 will be described. The processes shown in FIGS. 8 to 10 are processes executed when data is received from the local bus 6 in the ECU 2C. As shown in FIG. 8, the ECU 2C receives data from the local bus 6 in S202. Subsequently, the ECU 2C determines in S204 whether or not the data received in the above S202 is the proxy request data addressed to the ECU 2C. Here, it can be determined that the data is a proxy request data and that the data is addressed to the ECU 2C based on the ID included in the received data. When the above-mentioned S132 is executed in the ECU 2B, the proxy request data is transmitted to the second network 1B by broadcast communication. Therefore, the proxy request data reaches all the nodes other than the ECU 2B in the second network 1B.

When the ECU 2C receives the proxy request data addressed to the ECU 2C, the ECU 2C determines YES in S204 and proceeds to S206. In S206, the ECU 2C executes a process corresponding to the proxy request data. Details of S206 are shown in FIG. When the process shown in FIG. 9 is started, the ECU 2C turns on the proxy continuation flag in S222. Subsequently, the ECU 2C acquires the authentication target data to be processed from the reception data buffer 12A in S224. As described above, when the ECU 2B creates the proxy request data in S132, the proxy request data including the ID extracted from the authentication target data is created. Therefore, in S224, the ECU 2C searches the received data buffer 12A for data having an ID matching the "ID extracted from the authentication target data" included in the proxy request data, and the data is processed. Acquire as authentication target data.

Subsequently, the ECU 2C executes a message authentication process for the authentication target data found from the received data buffer 12A in S226. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 6 have already been described, the repeated description will be omitted. When the message authentication process is executed in S226, the "data to be processed" in S142 of FIG. 6 is the authentication target data found from the received data buffer 12A in S224.

Subsequently, the ECU 2C determines in S228 whether or not the authentication has been established. If the authentication is established in S226, it is determined as YES in S228, and the process proceeds to S230. In S230, the ECU 2C takes out the normal data included in the authentication target data, creates the authenticated data including the normal data, adds the CVN to the authenticated data, and transmits the certified data to the local bus 6. The authentication data can be indicated by the ID contained in the authenticated data.

The CVN added to the authenticated data is a CVN generated in the ECU 2C. After the execution of S230, the process shown in FIG. 9 is terminated. As a result, S206 in FIG. 8 is terminated, and the process shown in FIG. 8 is terminated. On the other hand, if the authentication fails in S226, it is determined as NO in S228, and the process proceeds to S232. In S232, the ECU 2C transmits failure notification data indicating an authentication failure to the local bus 6. The failure notification data can be indicated by the ID included in the failure notification data. After the execution of S232, the process shown in FIG. 9 is terminated. As a result, S206 in FIG. 8 is terminated, and the process shown in FIG. 8 is terminated.

When the above-mentioned S230 is executed in the ECU 2C, the authenticated data is transmitted to the second network 1B by broadcast communication. Therefore, the authenticated data transmitted from the ECU 2C reaches all the nodes other than the ECU 2C in the second network 1B. When the above-mentioned S232 is executed in the ECU 2C, the failure notification data is transmitted to the second network 1B by broadcast communication. Therefore, the failure notification data transmitted from the ECU 2C reaches all the nodes other than the ECU 2C in the second network 1B.

If it is not the proxy request data in S204 described above, it is determined as NO in S204, and the process proceeds to S208. However, since it is easier to understand S208 and S210 after explaining other parts, the explanation here will be withheld and will be described in detail later. If NO is determined in S208, the process proceeds to S212. In S212, the ECU 2C executes a process corresponding to other received data. As the process executed in S212, various processes depending on the function of the ECU 2C can be considered, but since the process itself is not a main part in the present embodiment, further description will be omitted. After the execution of S212, the process shown in FIG. 8 is terminated.

Next, the processes shown in FIGS. 11 and 12 will be described. The processes shown in FIGS. 11 and 12 are processes executed when data is received from the global bus 5B in the ECU 2C. As shown in FIG. 11, the ECU 2C receives data from the global bus 5B in S302. Subsequently, the ECU 2C stores the received data in the received data buffer 12A in S304. By executing S304, as described above, the received data buffer 12A stores the data received via the first network 1A for the latest fixed period.

Subsequently, the ECU 2C determines in S306 whether or not the received data is addressed to another ECU. If the received data is addressed to another ECU, it is determined to be YES in S306, and the process proceeds to S308. In S308, the ECU 2C executes a process corresponding to data addressed to another ECU. Details of S308 are shown in FIG. When the process shown in FIG. 12 is started, the ECU 2C determines whether or not the proxy continuation flag is turned on in S322. When the proxy continuation flag is turned on, it is determined as YES in S322, and the ECU 2C determines in S324 whether the data is the authentication target data to be processed.

When the ECU 2B is the request source device for authentication agency and the ECU 2C is the request destination device for authentication agency, among the data received from the global bus 5B, the data addressed to ECU 2B and requiring authentication is the authentication target to be processed in S324. Corresponds to the data. If the data received by the ECU 2C in S302 is the data addressed to the ECU 2B, it is determined to be YES in S306. Further, when the proxy continuation flag is turned on in S222 described above, it is determined to be YES in S322. Then, when the data received by the ECU 2C in S302 is the authentication target data to be processed, it is determined as YES in S324, and the process proceeds to S326.

In S326, the ECU 2C executes a message authentication process for the authentication target data received by the ECU 2C in S302. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 6 have already been described, the repeated description will be omitted. When the message authentication process is executed in S326, the "data to be processed" in S142 of FIG. 6 is the authentication target data received by the ECU 2C in S302. Subsequently, the ECU 2C determines in S328 whether or not the authentication has been established.

If the authentication is established in S326, it is determined as YES in S328, and the process proceeds to S330. In S330, the ECU 2C takes out the normal data included in the authentication target data, creates the authenticated data including the normal data, adds the CVN to the authenticated data, and transmits the certified data to the local bus 6. The authentication data can be indicated by the ID contained in the authenticated data. S330 is the same processing step as S230 described above. After the execution of S330, the process shown in FIG. 12 is terminated. As a result, S308 in FIG. 11 is terminated, and the process shown in FIG. 11 is terminated.

On the other hand, if the authentication fails in S326 of FIG. 12, it is determined as NO in S328, and the process proceeds to S332. In S332, the ECU 2C transmits failure notification data indicating an authentication failure to the local bus 6. S332 is the same processing step as S232 described above. After the execution of S332, the process shown in FIG. 12 is terminated. As a result, S308 in FIG. 11 is terminated, and the process shown in FIG. 11 is terminated.

During the process shown in FIG. 12, if the surrogate continuation flag is not on (that is, is off) in S322 described above, it is determined to be NO in S322. In this case, since the authentication is not requested by another ECU, the received data is discarded in S334. After the execution of S334, the process shown in FIG. 12 is terminated. As a result, S308 in FIG. 11 is terminated, and the process shown in FIG. 11 is terminated.

Further, in the above-mentioned S324, if the data is not the authentication target data to be processed, it is determined as NO in S324. In this case, although the authentication is requested by another ECU, the received data is discarded in S334 because it is not the authentication target data to be processed. After the execution of S334, the process shown in FIG. 12 is terminated. As a result, S308 in FIG. 11 is terminated, and the process shown in FIG. 11 is terminated.

In S306 of FIG. 11, when the received data is not destined for another ECU (that is, the data is destined for ECU 2C), it is determined as NO in S306, and in that case, the ECU 2C is determined to be another received data in S310. Execute the process corresponding to. As the process executed in S310, various processes depending on the function of the ECU 2C can be considered, but since the process itself is not a main part in the present embodiment, further description thereof will be omitted. After the execution of S310, the process shown in FIG. 11 is terminated.

Next, the processes shown in FIGS. 13 to 15 will be described. The processes shown in FIGS. 13 to 15 are processes executed when data is received from the local bus 6 in the ECU 2B. As shown in FIG. 13, the ECU 2B receives data from the local bus 6 in S402. Subsequently, the ECU 2B determines in S404 whether or not the data received in S402 is authenticated data. Here, it can be determined that the data is authenticated based on the ID included in the received data. When the above-mentioned S230 or S330 is executed in the ECU 2C, the authenticated data is transmitted to the second network 1B by broadcast communication. Therefore, the authenticated data reaches all the nodes other than the ECU 2C in the second network 1B.

If the data is authenticated in S404 described above, it is determined to be YES in S404, and the process proceeds to S406. In S406, the ECU 2B executes the process corresponding to the authenticated data. Details of S406 are shown in FIG. When the process shown in FIG. 14 is started, the ECU 2B determines in S422 whether or not the spoofing confirmation OK flag is off. The spoofing confirmation OK flag is a flag that is turned on in S428 described later when the initial value is turned off and the spoofing confirmation is properly executed in S424 and S426 described later. Here, the description will be continued assuming that the spoofing confirmation OK flag is set to the initial value (that is, off).

If the spoofing confirmation OK flag is off, it is determined to be YES in S422. In that case, the ECU 2B executes spoofing confirmation for the authenticated data by executing S424 and S426. Specifically, the ECU 2B takes out the CVN added to the authenticated data in S424. Then, in S426, it is determined whether or not the CVN is appropriate. In S426, the CVN taken out from the received authenticated data is compared with the CVN stored in the CVN storage unit 13B. Since the CVNs generated and output by the ECUs 2A to 2D are stored in the CVN storage unit 13B, the CVN corresponding to the ECU 2C is selected as a comparison target in S426.

As a result of this comparison, if both are in agreement, the CVN is appropriate, and it is determined to be YES in S426, and the process proceeds to S428. If the process proceeds to S428, it means that the spoofing confirmation has been properly executed, and the ECU 2B turns on the spoofing confirmation OK flag. Then, in S430, the ECU 2B takes out the normal data included in the authenticated data and uses it in the subsequent processing. As the "subsequent processing" referred to here, various processing according to the function of the ECU 2B can be considered, but since the processing itself is not a main part in the present embodiment, further description thereof will be omitted. After the execution of S430, the process shown in FIG. 14 is terminated. As a result, S406 in FIG. 13 is terminated, and the process shown in FIG. 13 is terminated.

On the other hand, in S426 described above, if the comparison results do not match, there is a high possibility that the CVN extracted from the received authenticated data is inappropriate. In this case, there is a possibility that a node other than the ECU 2C impersonates the ECU 2C and transmits the authenticated data. Alternatively, the software of the ECU 2C may have been tampered with, or the ECU 2C may have been replaced. Therefore, under such a situation, even if the authenticated data is received, the reliability of the authenticated data itself is low.

Therefore, if the comparison results in S426 described above do not match, the CVN is inappropriate, it is determined to be NO in S426, and the process proceeds to S432. In S432, the ECU 2B discards the received authenticated data and uses the fail-safe data in the subsequent processing. The fail-safe data is data that is used as a substitute when the authentication target data or the authenticated data received by the ECU 2B cannot be used due to a problem.

Such fail-safe data may be stored in advance in, for example, the flash memory 13. Alternatively, if the data to be authenticated has been received for a long period of time longer than a certain period in the past, the average value, maximum value, minimum value, etc. are calculated over time and prepared so that it can be used as fail-safe data at any time. You may leave it. The form in which the fail-safe data is prepared may be optimized in consideration of the behavior of the control target by the ECU 2B and the like. After the execution of S432, the process shown in FIG. 14 is terminated. As a result, S406 in FIG. 13 is terminated, and the process shown in FIG. 13 is terminated.

The process shown in FIG. 13 is executed in the ECU 2B each time the ECU 2B receives data from the local bus 6. At that time, even if the process proceeds to S406 again, if the processing step of S424-S428 is executed once, it is considered that the authenticated data can be trusted even if it is not executed every time thereafter. Therefore, when the spoofing confirmation OK flag is not off (that is, when it is on), it is determined as NO in S422, and the process proceeds to S430 without executing S424-S428. As a result, the load on the ECU 2B can be reduced by the amount that S424-S428 is not executed.

Further, in the above-mentioned S404, if the data received in the above-mentioned S402 is not the authenticated data, it is determined as NO in the S404, and in that case, the ECU 2B determines in the S408 whether the data received in the above-mentioned S402 is the failure notification data. Judge whether or not. Here, it can be determined that the data is failure notification data based on the ID included in the received data. If it is the failure notification data, it is determined as YES in S408, and the process proceeds to S410. In S410, the ECU 2B discards the received authenticated data and uses the fail-safe data in the subsequent processing. S410 is the same process as S432 described above. After the execution of S410, the process shown in FIG. 13 is terminated.

If it is not the failure notification data in S408 described above, it is determined as NO in S408, and the process proceeds to S412. However, since it is easier to understand S412 and SS414 after explaining other parts, the explanation here is withheld and will be described in detail later. If NO is determined in S412, the process proceeds to S416. In S416, the ECU 2B executes a process corresponding to other received data. As the process executed in S416, various processes depending on the function of the ECU 2B can be considered, but since the process itself is not a main part in the present embodiment, further description thereof will be omitted. After the execution of S416, the process shown in FIG. 13 is terminated.

Next, in the above-mentioned explanation, the part where the explanation is withheld will be described. As described above, in the above-mentioned network system 1, the ECU 2B serves as the requesting device, the ECU 2C serves as the requesting device, and the ECU 2C executes the authentication process on behalf of the ECU 2B. However, when repairs or the like are carried out in an automobile dealer or the like and an environment in which the ECU 2B can execute the authentication process by itself is prepared, it is preferable that both the ECU 2B and the ECU 2C return to the original operating state.

Therefore, the network system 1 of the present embodiment is configured so that the ECU 2B and the ECU 2C can be returned to the original operating state by transmitting a message from the external tool 9 to the node of the network system 1. .. Specifically, the external tool 9 transmits a proxy cancellation request to the node of the network system 1 via the first network 1A.

At this time, the ECU 2B receives the proxy stop request from the global bus 5A in S102 of FIG. 4 described above. In this case, YES is determined in S108, and the process proceeds to S110. In S110, the ECU 2B executes a process corresponding to the proxy stop request. Details of S110 are shown in FIG. When the process shown in FIG. 7 is started, the ECU 2B executes the message authentication process in S162. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 6 have already been described, the repeated description will be omitted. When the message authentication process is executed in S162, the "data to be processed" in S142 of FIG. 6 is a proxy stop request received from the external tool 9.

Subsequently, the ECU 2B determines in S164 whether or not the authentication has been established. If the authentication is established in S162, it is determined as YES in S164, and the process proceeds to S166. In S166, the ECU 2B determines whether the processing state in the ECU 2B is "normal processing in progress", "fail-safe processing in progress", or "substitute request in progress". When "normal processing is in progress" in S166, the ECU 2B transmits "authentication establishment notification" and "request for notification of proxy execution ID" to the local bus 6 in S168.

The "authentication establishment notification" is data for notifying other nodes that the authentication for the proxy cancellation request received from the external tool 9 has been established. The "request for notification of the proxy execution ID" is data for requesting the other node to notify the ECU 2B of the ID for which the ECU 2B has requested the other node to act on behalf of the user in the past. When S168 is finished, the process shown in FIG. 7 is finished. As a result, S110 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated.

When "fail-safe processing is in progress" in S166, the ECU 2B changes the processing state in the ECU 2B from "fail-safe processing in progress" to "normal processing in progress" in S170. After finishing S170, the process shown in FIG. 7 is finished. As a result, S110 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated. If the status is "requesting for proxy" in S166, the ECU 2B transmits "notification of authentication establishment" and "request for notification of ID during proxy execution" to the local bus 6 in S172. Since S172 is the same processing step as S168, the description thereof is omitted here. Subsequently, in S174, the ECU 2B leaves the processing state in the ECU 2B as "on behalf of requesting" and ends the processing shown in FIG. 7. As a result, S110 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated. If the authentication fails in S162, it is determined to be NO in S164. In this case, the ECU 2B ends the process shown in FIG. 7. As a result, S110 in FIG. 4 is terminated, and the process shown in FIG. 4 is terminated.

When the authentication establishment notification is transmitted in S168 or S172, the ECU 2C receives the authentication establishment notification in S202 of FIG. 8, and in that case, it is determined to be YES in S208, and the process proceeds to S210. In S210, the ECU 2C executes a process corresponding to the authentication establishment notification. Details of S210 are shown in FIG. When the process shown in FIG. 10 is started, the ECU 2C determines in S242 whether the state of the process in the ECU 2C is “normal processing in progress” or “substitute execution in progress”. When "normal processing is in progress" in S242, the processing shown in FIG. 10 is terminated. As a result, S210 in FIG. 8 is terminated, and the process shown in FIG. 8 is terminated.

If it is "on behalf of execution" in S242, the ECU 2C transmits "notification of the substitute execution ID" to the local bus 6 in S244. The proxy execution ID is an ID for which authentication proxy has been requested by the ECU 2B. Subsequently, the ECU 2C turns off the proxy continuation flag in S246. Then, in S248, the ECU 2C changes the processing state in the ECU 2C from “on behalf of execution” to “normal processing in progress”. When S248 is finished, the process shown in FIG. 10 is finished. As a result, S210 in FIG. 8 is terminated, and the process shown in FIG. 8 is terminated. In the first embodiment, when the process shown in FIG. 8 is completed, the ECU 2C ends the authentication proxy process and returns to the normal state.

When the "notification of the proxy execution ID" is transmitted in S244, the ECU 2B receives the "notification of the proxy execution ID" in S402 of FIG. 13, in which case, it is determined to be YES in S412, and the process proceeds to S414. move on. In S414, the ECU 2B executes the process corresponding to the "notification of the proxy execution ID". Details of S414 are shown in FIG. When the process shown in FIG. 15 is started, the ECU 2B determines in S442 whether the state of the process in the ECU 2B is “normal processing in progress” or “substitute request in progress”.

When "normal processing is in progress" in S442, the ECU 2B notifies the external tool 9 of the status of the ECU 2B via the global bus 5A in S444. As a result, the external tool 9 can grasp that the ECU 2B is in the normal processing. The external tool 9 can display that the ECU 2B is in the normal processing and record a log that the ECU 2B is in the normal processing. After finishing S444, the process shown in FIG. 15 is finished. As a result, S414 of FIG. 13 is terminated, and the process shown in FIG. 13 is terminated.

If it is "on behalf of" in S442, the ECU 2B turns off the behalf of request flag in S446. Subsequently, in S448, the ECU 2B changes the processing state in the ECU 2B from "on behalf of" to "normal processing". After finishing S448, the process proceeds to S444, and the status of the ECU 2B is notified to the external tool 9 via the global bus 5A. As a result, the external tool 9 can grasp that the ECU 2B has been changed from the proxy request to the normal processing. The external tool 9 may display that the ECU 2B has been changed from the proxy request to the normal process, or may record a log that the ECU 2B has been changed from the proxy request to the normal process. can. After finishing S444, the process shown in FIG. 15 is finished. As a result, S414 of FIG. 13 is terminated, and the process shown in FIG. 13 is terminated.

[effect]
As described above, according to the network system 1, even if the authentication of the authentication target data fails in the ECU 2B, if the authentication target data is successfully authenticated in the request destination device ECU 2C, the request source device ECU 2B will be used. The content of the authentication target data included in the authenticated data can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the ECU 2B, the ECU 2B uses the contents of the authentication target data authenticated by the ECU 2C. Period processing can be executed.

Further, in the case of the present embodiment, the ECU 2C, which is the request destination device, turns on the proxy continuation flag in S222 after receiving the proxy request data. After that, the ECU 2C executes S306-S330 every time the authentication target data is transmitted to the requesting device ECU 2B via the first network 1A, and transmits the authenticated data to the ECU 2B. Therefore, the ECU 2B can continuously receive the authenticated data from the ECU 2C without transmitting the proxy request data to the ECU 2C each time the authentication target data is received. Therefore, the load applied to the ECU 2B can be reduced as compared with the case where the ECU 2B is configured to transmit the proxy request data to the ECU 2C each time the authentication target data is received. In addition, the load on the second network 1B can be reduced by the amount that the transmission frequency of the proxy request data is reduced.

Further, in the case of the present embodiment, when the proxy cancellation request is transmitted from the external tool, the ECU 2B returns from the requested state to the non-requested state if it is in the requested state. When the proxy cancellation request is transmitted from the external tool 9, the ECU 2C returns from the proxy state to the non-proxy state if it is in the proxy state. Therefore, when the cause of the need for proxy processing is resolved by repair or the like, the ECU 2B and ECU 2C can be easily returned to the normal state by transmitting a proxy stop request from the external tool 9. can. As a result, the load caused by the proxy of the authentication process is not applied to the ECU 2B and the ECU 2C, and the load applied to the network system 1 can be reduced.

Further, in the case of the present embodiment, after the repair is carried out, is it possible to execute the authentication process in the ECU 2B by executing the authentication process in the ECU 2B triggered by the transmission of the proxy stop request by the external tool 9? You can judge whether or not.

Further, in the case of the present embodiment, the ECU 2B transmits the result of the authentication process for the proxy stop request to the ECU 2C. Therefore, it is possible to notify the ECU 2C whether or not the authentication in the ECU 2B is established.

Further, in the case of the present embodiment, when the ECU 2C receives the result of the authentication process for the proxy stop request from the ECU 2B, the ECU 2C returns from the proxy state to the non-proxy state. Therefore, the reliability of the entire system is improved as compared with the case where the proxy is stopped only by the judgment of the ECU 2C side without grasping whether or not the authentication by the ECU 2B is established in the ECU 2C.

Further, in the case of the present embodiment, the ECU 2B notifies the external tool 9 whether it is in the requested state or the non-requested state after the proxy cancellation request is transmitted from the external tool 9. Therefore, in the external tool 9, it is possible to grasp whether the ECU 2B is in the requested state or the non-requested state. Therefore, for example, the external tool 9 can display the state of the ECU 2B, and the operator can easily know the state of the ECU 2B.

(2) Second Embodiment Next, the second embodiment will be described. The second embodiment corresponds to an embodiment in which a part of the configuration exemplified in the first embodiment is modified. Therefore, in the following description, the differences from the first embodiment will be mainly described, and the detailed description of the same parts as those of the first embodiment will be omitted.

[Details of processing executed in the requesting device and the requesting device]
The ECU 2C of the second embodiment executes the process shown in FIG. 16 instead of the process illustrated in FIG. 10 in the first embodiment. In the process shown in FIG. 16, each process step of S243, S247, S252, and S254 is added to the process shown in FIG. When the process shown in FIG. 16 is started, the ECU 2C determines in S242 whether the state of the process in the ECU 2C is “normal processing in progress” or “substitute execution in progress”. If it is "execution on behalf of" in S242, the ECU 2C determines whether or not the proxy stop request flag is on in S243. If the proxy cancellation request flag is on, it is determined to be YES in S243, and the ECU 2C transmits "notification of proxy execution ID" to the local bus 6 in S244. The proxy execution ID is an ID for which authentication proxy has been requested by the ECU 2B.

Subsequently, the ECU 2C turns off the proxy continuation flag in S246. Subsequently, the ECU 2C turns off the proxy stop request flag in S247. Then, in S248, the ECU 2C changes the processing state in the ECU 2C from “on behalf of execution” to “normal processing in progress”. After finishing S248, the process proceeds to S254, and the ECU 2C notifies the external tool 9 of the status of the ECU 2C via the global bus 5B. As a result, the external tool 9 can grasp that the state of the ECU 2C has been changed from the proxy execution to the normal processing. The external tool 9 displays that the status of the ECU 2C has been changed from the proxy execution to the normal processing, and records a log that the status of the ECU 2C has been changed from the proxy request to the normal processing. Can be done. When S254 is finished, the process shown in FIG. 16 is finished.

If the proxy stop request flag is off in S243, it is determined as NO, and the ECU 2C leaves the processing status in the ECU 2C as “substitute execution in progress” in S252. After finishing S252, the process proceeds to S254, and the ECU 2C notifies the external tool 9 of the status of the ECU 2C via the global bus 5B. As a result, the external tool 9 can grasp that the state of the ECU 2C is still being executed on behalf of the user. When S254 is finished, the process shown in FIG. 16 is finished. If the status is "normal processing" in S242, the process proceeds to S254, and the ECU 2C notifies the external tool 9 of the status of the ECU 2C via the global bus 5B. As a result, the external tool 9 can grasp that the state of the ECU 2C is in the normal processing. When S254 is finished, the process shown in FIG. 16 is finished.

The ECU 2C of the second embodiment executes the process shown in FIG. 17 instead of the process illustrated in FIG. 11 in the first embodiment. In the process shown in FIG. 17, each process step of S342 and S344 is added to the process shown in FIG. When the process shown in FIG. 17 is started, the ECU 2C executes each process step from S302 to S306. Since each processing step from S302 to S306 is the same as that of the first embodiment, the description in the second embodiment will be omitted. If the received data is not addressed to another ECU in S306 (that is, the data is destined for ECU 2C), it is determined as NO in S306, and in that case, the ECU 2C is a proxy transmitted from the external tool 9 in S342. Determine if it is a cancellation request.

If it is a proxy cancellation request, it is determined to be YES in S342, and in that case, the ECU 2C executes a process corresponding to the proxy cancellation request in S344. Details of S344 are shown in FIG. When the process shown in FIG. 18 is started, the ECU 2C executes the message authentication process in S352. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 6 have already been described, the repeated description will be omitted. When the message authentication process is executed in S352, the "data to be processed" in S142 of FIG. 6 is a proxy stop request received from the external tool 9.

Subsequently, the ECU 2C determines in S354 whether or not the authentication has been established. If the authentication is established in S352, it is determined as YES in S354, and the process proceeds to S356. In S356, the ECU 2C determines whether the processing state in the ECU 2C is "normal processing in progress" or "substitute execution in progress". When "normal processing is in progress" in S356, the processing shown in FIG. 18 is terminated. As a result, S344 shown in FIG. 17 is terminated, and the process shown in FIG. 17 is terminated.

On the other hand, in S356, when the state of the process in the ECU 2C is "execution on behalf of", the ECU 2C turns on the proxy stop request flag in S358 and ends the process shown in FIG. As a result, S344 shown in FIG. 17 is terminated, and the process shown in FIG. 17 is terminated. If the authentication fails in S352, it is determined as NO in S354, and the process shown in FIG. 18 is terminated. As a result, S344 shown in FIG. 17 is terminated, and the process shown in FIG. 17 is terminated.

[effect]
The network system 1 of the second embodiment described above also has the same operations and effects as those of the first embodiment. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the ECU 2B, the ECU 2B uses the contents of the authentication target data authenticated by the ECU 2C. Period processing can be executed.

Further, as in the first embodiment, the ECU 2B can continuously receive the authenticated data from the ECU 2C without transmitting the proxy request data to the ECU 2C each time the authentication target data is received.

Further, as in the first embodiment, when the proxy cancellation request is transmitted from the external tool, the ECU 2B returns from the requested state to the non-requested state if it is in the requested state. When the proxy cancellation request is transmitted from the external tool 9, the ECU 2C returns from the proxy state to the non-proxy state if it is in the proxy state. Therefore, when the cause of the need for proxy processing is resolved by repair or the like, the ECU 2B and ECU 2C can be easily returned to the normal state by transmitting a proxy stop request from the external tool 9. can. As a result, the load caused by the proxy of the authentication process is not applied to the ECU 2B and the ECU 2C, and the load applied to the network system 1 can be reduced.

Further, in the case of the second embodiment, when the proxy cancellation request is transmitted from the external tool 9, the ECU 2C receives the proxy cancellation request via the first network 1A and returns from the proxy state to the non-proxy state. Therefore, when the authentication agency in the ECU 2C is stopped, it is possible to return to the non-agent state without relying on the ECU 2B. Alternatively, when canceling the authentication agency in the ECU 2C, it is possible to receive the proxy cancellation request by itself and also receive the information regarding the agency cancellation from the ECU 2B. In this case, the reliability of the system is confirmed by double confirmation. It is possible to improve the sex. Which of these configurations should be adopted may be selected depending on whether the reduction of the load on the system is emphasized or the reliability improvement of the system is emphasized.

Further, in the case of the second embodiment, since the ECU 2C notifies the external tool 9 of the state of the ECU 2C, it is possible to grasp whether the ECU 2C is in the surrogate state or the non-substitute state in the external tool 9. Therefore, for example, the external tool 9 can display the state of the ECU 2C, and the operator can easily know the state of the ECU 2C.

(3) Other Embodiments Although the network system has been described above with reference to exemplary embodiments, the above-described embodiments are merely exemplified as one aspect of the present disclosure. That is, the present disclosure is not limited to the above-mentioned exemplary embodiments, and can be implemented in various forms within a range that does not deviate from the technical idea of the present disclosure.

For example, in the above embodiment, the ECU 2B is the requesting device and the ECU 2C is the requesting device, but any of the ECUs 2A to 2D may be the requesting device. Further, among the ECUs 2A to 2D, any of the ECUs other than the requesting device may be the requesting device. Further, the ECUs 3A to 3H may be connected to the local bus 6, and in that case, the ECUs 3A to 3H may be the requesting device or the requesting device.

Further, in the above embodiment, an example of performing authentication processing by message authentication is shown, but authentication may be performed by a method other than message authentication, or message authentication and a method other than message authentication may be used in combination. .. For example, in the above embodiment, the normal data and the encrypted data are transmitted, the normal data is encrypted on the receiving side, and the encrypted data and the encrypted data are compared to determine whether or not the authentication is successful. However, other authentication procedures can be adopted. For example, even if normal data and encrypted data are transmitted, the encrypted data is decrypted on the receiving side, and the decrypted data is compared with the normal data to determine whether or not authentication is successful. good.

Further, in the above embodiment, by transmitting the CVN when transmitting the authenticated data, the receiving side confirms whether or not the source of the authenticated data is an appropriate node. However, the authenticated data is transmitted. If an eigenvalue can be transmitted so that it can be confirmed whether or not the source of the node is an appropriate node, it is arbitrary whether or not the eigenvalue is CVN. Further, if a mechanism for confirming whether or not the source of the authenticated data is an appropriate node is separately provided in addition to the mechanism exemplified in the above embodiment, whether or not the node is an appropriate node exemplified in the above embodiment. You may omit the mechanism to confirm whether or not. Alternatively, even when it is sufficiently reliable that the source of the authenticated data is an appropriate node, the mechanism for confirming whether or not the node is an appropriate node exemplified in the above embodiment may be omitted.

Further, in the above embodiment, once it is confirmed whether or not the source of the authenticated data is an appropriate node, the confirmation is omitted from the second time onward, but the same confirmation is omitted from the second time onward. It may be carried out without.

Further, in the above embodiment, a plurality of global buses 5A, 5B, 5C are connected to each other by a single CGW 4, but if a plurality of global buses 5A, 5B, 5C are configured to be connectable to each other. , Multiple gateways may be adopted. For example, by connecting the global bus 5A and the global bus 5B at the first gateway and connecting the global bus 5B and the global bus 5C at the second gateway, the global bus 5A and the global bus 5C become two gateways. And may be configured to be communicable via the global bus 5B.

In addition to the above, the function realized by one component in each of the above embodiments may be configured to be realized by a plurality of components. Further, the function realized by a plurality of components may be configured to be realized by one component. Further, a part of the configuration of each of the above embodiments may be omitted. Further, at least a part of the configuration of each of the above embodiments may be added or replaced with respect to the configuration of the other embodiments. In addition, all aspects included in the technical idea specified from the wording described in the claims fall under the embodiment of the present disclosure.

In addition to the network system described above, an electronic device that can configure the network system of the present disclosure, a vehicle equipped with the network system of the present disclosure, a program for operating a computer as the electronic device of the present disclosure, and this program are recorded. The present disclosure can also be realized in various forms such as a recording medium.

(4) Supplement As is clear from the exemplary embodiments described above, the network system of the present disclosure may further include the following configurations.

First, in the network system of the present disclosure, the requesting device is configured to execute the authentication process for the proxy cancellation request data when the proxy cancellation request data transmitted from the external device is received (S110, S108). It may be (S110, S162).

According to the network system configured in this way, after the electronic device and the communication path are repaired, the requesting device executes the authentication process triggered by the transmission of the proxy stop request data by the external device. It is possible to determine whether or not the authentication process can be executed on the requesting device.

Further, in the network system of the present disclosure, the requesting device may be configured to transmit the result of the authentication process for the proxy cancellation request data to the requesting device (S172).

According to the network system configured in this way, it is possible to transmit to the requesting device whether or not the authentication in the requesting device is established.
Further, in the network system of the present disclosure, the request destination device is configured to return from the proxy state to the non-proxy state when the result of the authentication process for the proxy stop request data is received from the request source device (S202, S208). It may be (S210, S242-S248).

According to the network system configured in this way, when the request source device is in a state where authentication is established, the request destination device returns from the proxy state to the non-proxy state. Therefore, the reliability of the system as a whole is improved as compared with the case where the agency is stopped only by the judgment of the requesting device side without knowing whether or not the authentication of the requesting device is established in the requesting device.

Further, in the network system of the present disclosure, when the request destination device receives the substitute stop request data via the first network when the substitute stop request data is transmitted from the external device (S302, S342), the request destination device is in the substitute state. It may be configured to return to the non-substitute state from (S344, S352-S358).

According to the network system configured in this way, when the request destination device receives the proxy cancellation request data from the external device, the request destination device returns from the proxy state to the non-proxy state. Therefore, when the authentication agency of the requesting device is stopped, it is not necessary to put an extra load on the requesting device.

Further, in the network system of the present disclosure, the requesting device is configured to notify the external device whether it is in the requested state or the non-requested state after the proxy cancellation request data is transmitted from the external device. It may be (S444).

According to the network system configured in this way, it is possible to grasp whether the requesting device is in the requested state or the non-requested state in the external device. Therefore, for example, the status of the requesting device can be displayed on the external device, and the operator can easily know the status of the requesting device.

Further, in the network system of the present disclosure, the request destination device is configured to notify the external device whether it is in the proxy state or the non-proxy state after the proxy cancellation request data is transmitted from the external device. It may be (S254).

According to the network system configured in this way, it is possible to grasp whether the requested device is in the proxy state or the non-proxy state in the external device. Therefore, for example, the status of the requested device can be displayed on the external device, and the operator can easily know the status of the requested device.

1 ... Network system, 1A ... First network, 1B ... Second network, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H ... ECU, 5A, 5B, 5C ... Global Bus, 6 ... local bus, 7 ... external communication path, 11 ... CPU, 12 ... RAM, 12A ... received data buffer, 13 ... flash memory, 13A ... common key storage, 13B ... CVN storage, 16 ... first communication Department, 17 ... Second communication department.

Claims (7)

A plurality of electronic devices (2A, 2B) configured to function as a node of the first network (1A) and also as a node of the second network (1B) constructed independently of the first network. , 2C, 2D), including
The plurality of electronic devices are configured to be communicable with the first network and external devices outside the second network via the first network.
At least one of the plurality of electronic devices is configured to be functional as a requesting device (2B).
At least one of the plurality of electronic devices is configured to be functional as a requested device (2C).
When one of the plurality of electronic devices functions as the requesting device, at least one electronic device different from the requesting device is configured to be able to function as the requesting device.
When the authentication target data to be authenticated is transmitted to the request source device via the first network, the request source device receives the authentication target data and authenticates the authentication target data. The process is executed (S124, S142-S150), and if the authentication is successful, the content of the authentication target data is used in the process after the authentication is successful (S128), and if the authentication fails, the request is made. It is configured to transmit the proxy request data for requesting the destination device to perform the authentication process to the request destination device via the second network, and to shift from the non-request state to the request state (S130). -S134),
After receiving the proxy request data, the request destination device shifts from the non-proxy state to the proxy state (S204-S206, S222), and the authentication target data is sent to the request source device via the first network. Each time the data is transmitted, the authentication target data is received (S302, S306, S308, S322, S324), the authentication process for the authentication target data is executed (S326), and if the authentication is successful, the authentication is successful. It is configured to transmit the authenticated data including the contents of the authentication target data to the requesting device via the second network (S328, S330).
When the request source device shifts to the request state, the request source device is configured to receive the authenticated data (S402) and use the content of the authentication target data included in the authenticated data (S406). , S430),
The requesting device is configured to return from the requested state to the non-requested state when the requesting device is in the requested state when the proxy cancellation request data is transmitted from the external device (S108). , S166, S172, S421, S414, S442, S446, S448),
The request destination device is configured to return from the proxy state to the non-proxy state when the proxy stop request data is transmitted from the external device (S208), if the request destination device is in the proxy state. (S210, S242-S248)
Network system. The network system according to claim 1.
When the requesting device receives the proxy cancellation request data transmitted from the external device (S110, S108), the requesting device is configured to execute an authentication process for the proxy cancellation request data (S110, S162). )
Network system. The network system according to claim 2.
The requesting device is configured to transmit the result of the authentication process for the proxy cancellation request data to the requesting device (S172).
Network system. The network system according to claim 3.
The request destination device is configured to return from the proxy state to the non-proxy state when the result of the authentication process for the proxy cancellation request data is received from the request source device (S202, S208) (S202, S208). S210, S242-S248)
Network system. The network system according to any one of claims 1 to 4.
When the request destination device receives the substitute stop request data via the first network when the substitute stop request data is transmitted from the external device (S302, S342), the request destination device does not change from the substitute state. It is configured to return to the proxy state (S344, S352-S358).
Network system. The network system according to any one of claims 1 to 5.
The requesting device is configured to notify the external device whether it is in the requested state or the non-requested state after the proxy cancellation request data is transmitted from the external device ( S444)
Network system. The network system according to any one of claims 1 to 6.
The request destination device is configured to notify the external device whether it is in the proxy state or the non-proxy state after the proxy cancellation request data is transmitted from the external device ( S254)
Network system.

Images