Service intermediary device, service intermediary method, and program

Abstract

A service intermediation device (300) of a service providing system in which a server unit provides a client unit with a service by service-oriented communication comprises: a communication control unit (301) that is connected to each of the server unit and the client unit and receives a frame to be used for providing the service from the server unit or the client unit; and a service management unit (302) that determines whether a combination of an identifier of the service, an identifier indicating a transmission source or destination of the frame, and a type of the frame, which are included in the frame received by the communication control unit (301), is appropriate or not, and outputs the result of determination.

Description

Technical Field

[0001] The present disclosure relates to a service mediation apparatus, a service mediation method, and a program.

Background Art

[0002] In recent years, a large number of devices called electronic control units (hereinafter, ECU: Electronic Control Unit) have been arranged in automobiles. There is a method of using encrypted communication to prevent communication by unauthorized nodes against the threat of spoofing in communication between ECUs.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, when using encrypted communication, there is a problem that encryption or decryption processing by the transmitting and receiving nodes is required, resulting in overhead.

[0005] Therefore, the present disclosure provides a service mediation method for appropriately performing access control of communication related to service provision.

Means for Solving the Problems

[0006] A service intermediary device according to one aspect of the present disclosure is a service provision system that provides services from a server unit to a client unit by service-oriented communication, and comprises a communication control unit connected to the server unit and the client unit respectively, which receives frames used for providing the service from the server unit or the client unit, and a service management unit which determines whether the combination of a service identifier included in the frame received by the communication control unit, an identifier indicating the source or destination of the frame, and the type of the frame is appropriate, and outputs the result of the determination.

[0007] These comprehensive or specific embodiments may be implemented as a system, method, integrated circuit, computer program, or recording medium such as a computer-readable CD-ROM, or as any combination of a system, method, integrated circuit, computer program, and recording medium. [Effects of the Invention]

[0008] According to this disclosure, access control for communications related to service provision can be appropriately implemented. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows the overall configuration of the in-vehicle network system in the embodiment. [Figure 2] Figure 2 shows the message format of SOME / IP SD in the embodiment. [Figure 3] Figure 3 shows an example of a SOME / IP SD message in the embodiment. [Figure 4] Figure 4 shows the configuration of the server ECU in the embodiment. [Figure 5] Figure 5 shows the configuration of the intermediary ECU in the embodiment. [Figure 6A]Figure 6A shows a first example of application authentication information in the embodiment. [Figure 6B] Figure 6B shows a second example of application authentication information in the embodiment. [Figure 6C] Figure 6C shows a third example of application authentication information in the embodiment. [Figure 7] Figure 7 shows an example of a service policy in an embodiment. [Figure 8A] Figure 8A shows an example of service information in an embodiment. [Figure 8B] Figure 8B shows an example of access control information in the embodiment. [Figure 9] Figure 9 shows an example of the vehicle state in the embodiment. [Figure 10] Figure 10 shows the service information registration sequence of the intermediary ECU in the embodiment. [Figure 11A] Figure 11A shows the communication sequence of a service that performs only SD mediation in an embodiment. [Figure 11B] Figure 11B shows the communication sequence of the proxy transmission service in the embodiment. [Figure 12] Figure 12 shows the sub-server registration sequence of the intermediary ECU in the embodiment. [Figure 13] Figure 13 shows the communication sequence of proxy transmission by the intermediary ECU in the embodiment. [Figure 14] Figure 14 shows the communication sequence for proxy transmission in the event of an abnormality in the embodiment. [Figure 15] Figure 15 shows the switching sequence to the sub-server in the event of an abnormality in the embodiment. [Figure 16] Figure 16 is a flowchart showing the processing of SD messages by the intermediary ECU in the embodiment. [Figure 17]FIG. 17 is a flowchart showing the processing of SOME / IP messages by the mediation ECU in the embodiment. [Figure 18] FIG. 18 is a flowchart showing the server switching process when a communication abnormality of the main server is detected in the embodiment. [Figure 19A] FIG. 19A is a diagram showing the configuration of the service mediation device in a modification of the embodiment. [Figure 19B] FIG. 19B is a flowchart showing the service mediation device in a modification of the embodiment. [Figure 19C] FIG. 19C is a decision flowchart of the service mediation method by the mediation ECU in another modification. [Figure 20] FIG. 20 is a diagram showing an example of a log notified at the time of abnormality detection in another modification.

Embodiments of the Invention

[0010] (Knowledge underlying the present invention) The present inventor has found that the following problems occur with respect to the service mediation device and the like described in the "Background Art" section.

[0011] In an in-vehicle network connecting ECUs in an automobile, there are many communication protocol standards, and among them, one of the most mainstream standards is Controller Area Network (hereinafter, CAN (registered trademark)).

[0012] In CAN, an ECU broadcasts and transmits information such as sensor values, and an ECU that wants to acquire information such as sensor values receives the information such as sensor values broadcast and transmitted.

[0013] Furthermore, with the spread of autonomous driving or connected cars, an increase in in-vehicle network traffic is expected, and thus the spread of in-vehicle Ethernet (registered trademark) as a communication protocol is also progressing.

[0014] In automotive Ethernet (registered trademark), service-oriented communication is being introduced as an alternative to, or in conjunction with, signal-oriented communication such as CAN, enabling a more efficient development process.

[0015] As a method for realizing service-oriented communication, Service Oriented Middleware Over IP (SOME / IP) is defined in AUTomotive Open System ARchitecture (AUTOSAR).

[0016] The threat of impersonation attacks by malicious nodes in CAN is equally threatening in SOME / IP communications. To counter such threats, there are methods that use encrypted communication, which have been used in Internet Protocol (IP) communications, to prevent communication by malicious nodes (see Non-Patent Document 1 or Non-Patent Document 2).

[0017] Furthermore, in control networks that control systems including sensors and actuators, not just in-vehicle networks, ensuring security is important, but also ensuring real-time performance and reliability. Since the important elements differ depending on the characteristics of the service, it is desirable to be able to set appropriate security policies and QoS (Quality of Service), such as real-time performance, according to the service.

[0018] Thus, as vehicles become networked and ECUs become more complex, there is a possibility of impersonation attacks where attackers exploit vulnerabilities in the ECUs to compromise the system.

[0019] However, the methods described in Non-Patent Document 1 or Non-Patent Document 2 use encrypted communication, which necessitates encryption or decryption processing by the transmitting and receiving nodes, resulting in overhead.

[0020] Therefore, this disclosure provides a service intermediation method for appropriately controlling access to communications related to service provision.

[0021] More specifically, this disclosure provides a flexible mediation method that, based on a service policy, controls access to services or switches service providers in the event of a failure, through an intermediary ECU that mediates communication between ECUs performing service-oriented communication in an in-vehicle network.

[0022] A service intermediary device according to one aspect of the present disclosure is a service provision system that provides services from a server unit to a client unit by service-oriented communication, and comprises a communication control unit connected to the server unit and the client unit respectively, which receives frames used for providing the service from the server unit or the client unit, and a service management unit which determines whether the combination of a service identifier included in the frame received by the communication control unit, an identifier indicating the source or destination of the frame, and the type of the frame is appropriate, and outputs the result of the determination.

[0023] This enables the service intermediary device to detect fraudulent communications in service-oriented communications, such as those impersonating server or client units, and to prevent inappropriate access to server or client units. In this way, the service intermediary device can appropriately control access to communications related to service provision.

[0024] For example, the communication control unit may further receive a service provision frame from the server unit, which includes first service information indicating the service to be provided, before providing the service, and a service search frame from the client unit, which includes second service information indicating the target of the service search, before providing the service. The service management unit may further transmit the service provision frame, which includes the same first service information as the second service information included in the service search frame received by the communication control unit, to the client unit that was the source of the received service search frame, via the communication control unit.

[0025] According to the above embodiment, the service intermediary device appropriately mediates service provision frames and service discovery frames between the server unit and the client unit. This prevents service provision frames and service discovery frames from being received by devices unrelated to the provision or enjoyment of the service, and effectively prevents impersonation of the server unit or client unit. In this way, the service intermediary device can appropriately control access to communications related to service provision.

[0026] For example, the service provision frame includes first authentication information indicating that the server unit has the authority to act as a server providing the service indicated by the first service information included in the service provision frame, and the service discovery frame includes second authentication information indicating that the client unit has the authority to act as a client receiving the service indicated by the second service information included in the service discovery frame. The service management unit may further determine that the service provision frame is valid if the verification of the first authentication information included in the service provision frame is successful, and that the service discovery frame is valid if the verification of the second authentication information included in the service discovery frame is successful. If the service provision frame and the service discovery frame are determined to be valid, the communication control unit may transmit the service provision frame to the client unit.

[0027] According to the above embodiment, the service intermediary device uses authentication information to determine whether the server unit has the authority to provide services as a server, and whether the client unit has the authority to receive services as a client, and then controls the server unit to provide services to the client unit. This prevents devices without server authority from providing services, and devices without client authority from receiving services. Therefore, the service intermediary device can appropriately control access to communications related to service provision.

[0028] For example, the communication control unit may, upon receiving a first frame used for providing the service from the server unit providing the service, transmit the first frame to the client unit receiving the service, and upon receiving a second frame used for providing the service from the client unit receiving the service, transmit the second frame to the server unit providing the service.

[0029] According to the above embodiment, the service intermediation device appropriately mediates the frames used to provide the service between the server unit and the client unit. This prevents the frames used to provide the service from being received by devices unrelated to the provision or enjoyment of the service, and effectively prevents impersonation of the server unit or client unit. In this way, the service intermediation device can appropriately control access to communications related to service provision.

[0030] For example, the service intermediary device includes a proxy transmission unit that performs proxy transmission processing, and the proxy transmission processing may include, when the communication control unit receives the first frame, the process of changing the source information contained in the first frame to an identifier of the service intermediary device and then transmitting the first frame to the client unit, or when the communication control unit receives the second frame, the process of changing the source information contained in the second frame to an identifier of the service intermediary device and then transmitting the second frame to the server unit.

[0031] According to the above embodiment, when the service intermediation device intermediaries a frame used to provide a service, it changes the source of the frame to its own identifier. As a result, the server unit can provide services without obtaining the client unit's identifier, and the client unit can receive services without obtaining the server unit's identifier. This further reduces the opportunity for other devices to obtain the identifiers of the server unit and the client unit, thereby effectively preventing impersonation of the server unit or the client unit. In this way, the service intermediation device can appropriately control access to communications related to service provision.

[0032] For example, the server unit, the client unit, and the service intermediary device are mounted in a vehicle, and the service intermediary device further includes a vehicle state holding unit that holds state information indicating the state of the vehicle, and the proxy transmission unit may control whether or not to execute the proxy transmission process according to the state information held by the vehicle state holding unit.

[0033] According to the above embodiment, the service intermediary device controls whether or not to perform proxy transmission depending on the vehicle status. The reliability and real-time requirements for service provision differ depending on the service. Therefore, by the service intermediary device controlling whether or not to perform proxy transmission depending on the vehicle status, the decision to perform proxy transmission is controlled according to the reliability and real-time requirements for service provision. Thus, the service intermediary device can appropriately control access to communications related to service provision through controlling proxy transmission according to the reliability and real-time requirements for service provision.

[0034] For example, the server unit includes a first server unit and a second server unit, and when the communication control unit receives the service provision frame from the first server unit, it enters a standby state for a predetermined period of time, and when it receives the service provision frame from the second server unit during the standby state, it may transmit either of the two received service provision frames to the client unit.

[0035] According to the above embodiment, the service intermediary device provides redundancy for the server unit in the service delivery system. This allows the service intermediary device to maintain communication compatible with the case where the service delivery system has a single server unit, while contributing to the realization of a more robust system configuration. Therefore, the service intermediary device can appropriately control access to communications related to service provision while increasing the robustness of the system.

[0036] For example, if the communication control unit does not receive the service provision frame from the second server unit in the standby state, it may transmit the service provision frame received from the first server unit to the client unit and perform predetermined processing to be performed when an abnormality occurs in the second server unit.

[0037] According to the above embodiment, the service intermediary device maintains the redundant configuration of the server units by contributing to the provision of services by the other server unit when a failure occurs in one of the redundant server units. Therefore, the service intermediary device can appropriately control access to communications related to service provision while enhancing the robustness of the system.

[0038] For example, if the communication control unit does not receive the service provision frame from the second server unit in the standby state, it may control whether or not to transmit the service provision frame received from the first server unit to the client unit, depending on the type of service.

[0039] According to the above embodiment, the service intermediary device controls the provision of services by the other server unit in the event of a failure in one of the redundant server units, according to the type of service. Since the reliability and real-time requirements for service provision differ depending on the type of service, the service intermediary device's control contributes to controlling the provision of services by the other server unit in accordance with the reliability and real-time requirements for service provision. Therefore, by controlling service provision in the redundant configuration according to the reliability and real-time requirements for service provision, the service intermediary device can appropriately control access to communications related to service provision.

[0040] For example, the server unit, the client unit, and the service intermediary device are mounted on a vehicle, and the service intermediary device further includes a vehicle state holding unit that holds state information indicating the state of the vehicle, and the communication control unit may, in the standby state, control whether or not to transmit the service provision frame received from the first server unit to the client unit, according to the state information held by the vehicle state holding unit, if it does not receive the service provision frame from the second server unit.

[0041] According to the above embodiment, the service intermediary device controls the provision of services by the other server unit in the event of a malfunction in one of the redundant server units, according to the vehicle's status. Since the reliability and real-time requirements for service provision differ depending on the vehicle's status, the service intermediary device's control contributes to controlling the provision of services by the other server unit in accordance with the reliability and real-time requirements for service provision. Therefore, by controlling service provision in the redundant configuration in accordance with the reliability and real-time requirements for service provision, the service intermediary device can appropriately control access to communications related to service provision.

[0042] For example, the server unit includes a first server unit and a second server unit, and when the communication control unit receives the service discovery frame from the client unit, it may transmit the received service discovery frame to both the first server unit and the second server unit.

[0043] According to the above embodiment, the service intermediation device appropriately mediates service discovery frames when the server units are configured redundantly. Therefore, the service intermediation device can appropriately control access to communications related to service provision while enhancing the robustness of the system.

[0044] For example, the server unit may include a plurality of server units, and the service management unit may maintain communication status information indicating whether the plurality of server units are in a communication-enabled state, and may transmit the maintained communication status information to the client unit.

[0045] According to the above embodiment, the service intermediary device appropriately allows the client unit to obtain information indicating the server unit capable of providing services. This enables the service intermediary device to appropriately control access to communications related to service provision while improving the security and robustness of the in-vehicle network system.

[0046] For example, if the service management unit detects that one of the multiple server units is in a communication-unavailable state, it may refer to the communication status information and transmit the service provision frame received from a server unit that is in a communication-available state to the client unit.

[0047] According to the above embodiment, the service intermediary device can allow client units to obtain information about alternative server units when it becomes difficult for one server unit to continue providing services. This enables the service intermediary device to appropriately control access to communications related to service provision while further improving the security and robustness of the in-vehicle network system.

[0048] For example, the output of the determination result may include displaying information indicating the determination result on a display screen, or transmitting information indicating the determination result to an external device via a network.

[0049] According to the above embodiment, the service intermediary device can more easily output information indicating the determination result by displaying the information on a screen or transmitting it to an external device. Therefore, the service intermediary device can appropriately control access to communications related to service provision.

[0050] These comprehensive or specific embodiments may be implemented as a system, method, integrated circuit, computer program, or recording medium such as a computer-readable CD-ROM, or as any combination of a system, method, integrated circuit, computer program, or recording medium.

[0051] The embodiments will be described in detail below with reference to the drawings.

[0052] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples only and are not intended to limit this disclosure. Furthermore, among the components in the following embodiments, those not described in the independent claim representing the highest-level concept will be described as optional components.

[0053] (Embodiment) This embodiment describes a service intermediary device that appropriately controls access to communications related to service provision. More specifically, it describes a service intermediary method in an in-vehicle network system in which multiple electronic control units (ECUs) perform service-oriented communication via Ethernet®. The in-vehicle network system is an example of a service provision system. Other examples of service provision systems include control network systems such as robot control network systems or mobility control network systems.

[0054] [1.1 Overall Configuration of the In-Vehicle Network System] Figure 1 shows the overall configuration of the in-vehicle network system in this embodiment. The in-vehicle network system comprises server ECUs 100a and 100b, client ECUs 100c and 100d, and an intermediary ECU 200.

[0055] Server ECU 100a is a device that provides services to client ECU 100c or 100d. Server ECU 100b is a device that provides services similar to Server ECU 100a. Server ECUs 100a and 100b are also called server units.

[0056] Client ECU100c is a device that receives services from server ECU100a or 100b. Client ECU100d is a device that receives services, similar to client ECU100c. Client ECU100c and 100d are also referred to as client units.

[0057] The service includes, for example, providing information such as sensor values, or performing predetermined calculations upon request and outputting the calculation results.

[0058] The intermediary ECU 200 is a device that mediates the provision of services from the server ECU 100a or 100b to the client ECU 100c or 100d. The intermediary ECU 200 is communicated via Ethernet with the server ECUs 100a and 100b, as well as the client ECUs 100c and 100d.

[0059] Server ECUs 100a and 100b and client ECUs 100c and 100d communicate using SOME / IP, thereby contributing to the realization of vehicle functions.

[0060] In this embodiment, for the sake of simplicity, the vehicle network system is configured to consist only of server ECUs 100a and 100b, client ECUs 100c and 100d, and an intermediary ECU 200; however, other ECUs or networks may also be present.

[0061] [1.2 SOME / IP Message Format] SOME / IP defines four types of communication methods: Request / Response, Fire / Forget, Events, and Get / Set / Notifier. Server ECUs 100a and 100b, and client ECUs 100c and 100d, combine these communication methods to achieve service-oriented communication. SOME / IP also provides a method for establishing a session with a communication partner, which is called Service Discovery (SD).

[0062] Figure 2 shows the message format used in SOME / IP SD in this embodiment.

[0063] The message format in Figure 2 is stored in the Ethernet payload. In Figure 2, each line is 32 bits long, with the first half being the SOME / IP header and the second half being the SOME / IP SD payload.

[0064] The SOME / IP header includes the fields Message ID, Length, Request ID, Protocol Version, Interface Version, Message Type, and Return Code.

[0065] The Message ID stores the identifier of the message. In the case of SOME / IP SD, the Message ID is 0xFFFF8100.

[0066] The Length field stores the number of bytes of data after the Length field.

[0067] The Request ID is a numerical value that combines the Client ID and Session ID.

[0068] For Service Discovery, the Protocol Version is set to 0x01, the Interface Version to 0x01, the Message Type to 0x02, and the Return Code to 0x00.

[0069] The payload of the SOME / IP SD includes the fields Flags, Reserved, Length of Entries Array in Bytes, Entries Array, Length of Options Array in Bytes, and Options Array.

[0070] Figure 3 shows an example of a SOME / IP SD message in this embodiment. The SOME / IP SD message in Figure 3 is an example of a message indicating that the service with service ID 0x1000 is available.

[0071] The Flags field is set to 0x80, indicating that the Reboot Flag is set. The Reserved field is set to 0.

[0072] The "Length of Entries Array in Bytes" field stores the number of bytes in each entry, which is set to 16 bytes in Figure 3.

[0073] The Type can be set to 0x00 or 0x01. 0x00 means Find, and 0x01 means Offer. Find is used when a client ECU receiving a service requests the provision of the necessary service. Offer is used when a server ECU providing a service notifies the server of the services it can provide. In Figure 3, the Type is 0x01, and the message shown in Figure 3 is a message from the server ECU notifying the server of the services it can provide.

[0074] The Index 1st options indicates the position of the first option. In Figure 3, the Index 1st options is set to 0, meaning that the first option is located at the beginning of the option area.

[0075] The Index 2nd options indicates the position of the second option. In Figure 3, the Index 2nd options is set to 0. Note that, as will be explained later, option 2 is not used in the message shown in Figure 3, so the value set in Index 2nd options is not used.

[0076] #of opt1 indicates the number of option 1s. In Figure 3, #of opt1 is stored as 1.

[0077] #of opt2 indicates the number of options 2. In Figure 3, #of opt2 contains 0, indicating that option 2 is not used.

[0078] The Service ID indicates the type of service. In Figure 3, the Service ID is stored as 0x1000.

[0079] The Instance ID is an ID that identifies an instance of the service, and in Figure 3, it indicates that the instance is 0x0001.

[0080] The Major Version is information used for service version control, and in Figure 3, it is set to 0x01.

[0081] TTL is a field that sets the service's expiration time in seconds, and in Figure 3, it is set to 0xFFFF. Setting TTL to 0xFFFF means that the service will be valid until the next ECU startup.

[0082] Minor Version is information used for service version control, and in Figure 3, it is set to 0x00000002.

[0083] Next, the Option area includes the fields Length of Options Array in Bytes, Length, Type, Reserved, IPv4 Address, Reserved, L4-Proto, and Port Number.

[0084] The Length of Options Array in Bytes indicates the length of the Option area. Figure 3 shows that the Length of Options Array in Bytes is 12 bytes.

[0085] Length indicates the number of bytes in this option area. The value of Length is determined by the type of option.

[0086] The `Type` field indicates the type of this option area.

[0087] The Reserved area stores 0.

[0088] Figure 3 shows an example of communication using IPv4, where Length is set to 9, Type to 0x04, and Reserved area to 0x00.

[0089] The IPv4 address indicates the server's IP address. In Figure 3, the IPv4 address is set to 192.168.0.1.

[0090] The Reserved area stores 0.

[0091] L4-Proto indicates the Layer 4, or transport layer protocol. L4-Proto stores the value 0x11, indicating the use of the User Datagram Protocol (UDP).

[0092] The port number indicates the transport layer port number being used. In Figure 3, the port number is shown to be port 35000.

[0093] [1.3 Server ECU100a Configuration] Figure 4 shows the configuration of the server ECU 100a in this embodiment. The server ECU 100a is implemented by a computer equipped with, for example, a processor, memory, and a communication interface, and is configured to include a communication unit 101, an application unit 102, an application authentication information storage unit 103, and a service policy storage unit 104.

[0094] Note that the server ECU100b, client ECU100c, and client ECU100d have the same configuration as the server ECU100a, so their descriptions will be omitted.

[0095] The communication unit 101 is a communication interface that communicates with other ECUs. For example, the communication unit 101 is an Ethernet communication interface, and in this case, it is connected to the intermediary ECU 200 via Ethernet. The communication unit 101 receives messages from Ethernet and notifies the application unit 102. The communication unit 101 also sends messages to Ethernet in response to requests from the application unit 102.

[0096] The application unit 102 executes applications that realize the main functions of the server ECU 100a. For example, in the case of server ECU 100a or ECU 100b, the application unit 102 includes applications that provide service-oriented communication services. For example, in the case of client ECU 100c or ECU 100d, the application unit 102 includes applications that receive services.

[0097] Furthermore, the application unit 102 refers to the information stored in the application authentication information storage unit 103 and sends information to the mediating ECU 200 to authenticate its access rights to its own service. In addition, the application unit 102 refers to the service policy storage unit 104 and notifies the mediating ECU 200 of the service policy.

[0098] The application authentication information storage unit 103 stores information regarding service authorization certificates that prove the access rights to the services held by the application unit 102. Details of the application authentication information will be described later.

[0099] The service policy storage unit 104 stores information indicating the security policy, real-time or reliability policy for the service. Details of the service policy will be described later.

[0100] [1.4 Configuration of the Intermediary ECU200] Figure 5 shows the configuration of the intermediary ECU 200 in this embodiment.

[0101] In Figure 5, the intermediary ECU 200 is configured to include a communication control unit 201, a service management unit 202, a proxy transmission unit 203, an abnormality monitoring unit 204, a service information holding unit 205, and a vehicle state holding unit 206.

[0102] The communication control unit 201 is a communication interface that communicates with other ECUs. The communication control unit 201 has, for example, four Ethernet ports, each Ethernet port being connected to the server ECUs 100a and 100b, and the client ECUs 100c and 100d for communication. The communication control unit 201 transmits or receives Ethernet frames to and from the server ECUs 100a and 100b, and the client ECUs 100c and 100d.

[0103] Furthermore, the communication control unit 201 receives messages contained in frames flowing through the network, notifies the service management unit 202, and, upon receiving a transmission request from the service management unit 202, transmits the frame containing the message to the Ethernet. The communication control unit 201 also acts as an Ethernet switch, forwarding messages to the appropriate port according to the destination contained in the received message.

[0104] If the server ECUs 100a and 100b are configured to be redundant, the communication control unit 201 may, upon receiving a service provision frame from server ECU 100a, enter a standby state for a predetermined period of time, and if it receives a service provision frame from server ECU 100b while in standby mode, it may send one of the two received service provision frames to client ECU 100c or ECU 100d.

[0105] Furthermore, if server ECUs 100a and 100b are configured in a redundant configuration, when a service discovery frame is received from client ECU 100c or ECU 100d, the received service discovery frame may be sent to both server ECUs 100a and 100b.

[0106] Furthermore, if server ECUs 100a and 100b are configured redundantly, for example, server ECU 100a corresponds to the first server unit or main server, and server ECU 100b corresponds to the second server unit or sub-server.

[0107] The service management unit 202 performs service mediation for received service-oriented communication messages based on the service policy stored in the service information storage unit 205 and the vehicle status stored in the vehicle status storage unit 206. Service mediation refers to the process of relaying (or forwarding) service provision frames between the server ECU and the client ECU, thereby enabling service provision from the server ECU to the client ECU.

[0108] The service management unit 202, in mediating services, determines whether the combination of the service identifier included in the frame received by the communication control unit 201, the identifier indicating the source or destination of the frame, and the type of the frame is appropriate, and outputs the result of the determination. The processing related to service mediation will be explained in detail later.

[0109] If the service mediation method is "with proxy transmission," the service management unit 202 provides the proxy transmission unit 203 with a message related to the service that supports proxy transmission. In addition, in accordance with the transmission request from the proxy transmission unit 203, the service management unit 202 requests the communication control unit 201 to transmit the message.

[0110] Furthermore, the service management unit 202 notifies the anomaly monitoring unit 204 of a message to monitor whether any abnormalities have occurred in the service communication.

[0111] The service management unit 202 maintains communication status information indicating whether or not server ECUs 100a and 100b are in a communication-enabled state, and may transmit the maintained communication status information to client ECUs 100c and 100d.

[0112] In this case, if the service management unit 202 detects that one of the server ECUs 100a and 100b is in a communication-unavailable state, it may refer to the communication status information and send the service provision frame received from the server ECU that is in a communication-available state to the client ECUs 100c and 100d.

[0113] Furthermore, the output of the judgment result performed by the service management unit 202 may include displaying information indicating the judgment result on a display screen, or transmitting information indicating the judgment result to an external device via a network. The external device is a device outside the in-vehicle network system and is connected to the in-vehicle network system via a network.

[0114] The proxy transmission unit 203 performs a proxy transmission process, which is the process of transmitting a communication frame on behalf of the server ECU 100a or ECU 100b, or the client ECU 100c or ECU 100d.

[0115] When the service policy mediation method is set to "enabled," the proxy transmission unit 203 has the mediating ECU 200 take over the role of sending and receiving messages on behalf of the server ECU 100a or ECU 100b. Specifically, when the proxy transmission unit 203 receives an Offer message containing service provision information from the server ECU 100a or ECU 100b, it forwards the Offer message containing the service provision information to the client ECU 100c or ECU 100d, with the mediating ECU 200 acting as the service provider on behalf of the server ECU 100a or ECU 100b.

[0116] Furthermore, when the proxy transmission unit 203 receives a service request message from client ECU100c or ECU100d, it forwards the message to server ECU100a or ECU100b, designating the intermediary ECU200 as the service recipient on behalf of client ECU100c or ECU100d.

[0117] Furthermore, when the proxy transmission unit 203 receives a reply or notification message from server ECU 100a or ECU 100b, the intermediary ECU 200 acts as the sender on behalf of server ECU 100a or ECU 100b and forwards the reply or notification message to client ECU 100c or ECU 100d.

[0118] In this way, when the service policy mediation method is set to "proxy transmission enabled," the mediating ECU200 acts as a client ECU100c or ECU100d for server ECU100a or ECU100b, and acts as server ECU100a or ECU100b for client ECU100c or ECU100d, thereby performing mediation.

[0119] To improve service reliability, if server ECU100a and ECU100b are configured redundantly, the proxy transmission unit 203 forwards messages from client ECU100c or ECU100d to server ECU100a or ECU100b. For messages from server ECU100a or ECU100b, the proxy transmission unit 203 may forward messages from the main server, or it may forward messages from the sub-server. Furthermore, the proxy transmission unit 203 may wait for messages from both the main and sub-servers to be received, compare both received messages, and then forward the appropriate message to client ECU100c or ECU100d. The forwarding of messages from server ECU100a or ECU100b is determined according to the service policy.

[0120] The proxy transmission unit 203 may control whether or not to execute the proxy transmission process according to the status information held by the vehicle status holding unit 206.

[0121] The anomaly monitoring unit 204 checks whether an anomaly has occurred in the service-oriented communication. Specifically, the anomaly monitoring unit 204 determines whether communication from server ECU 100a or ECU 100b, or client ECU 100c or ECU 100d has been interrupted for a predetermined period of time, and whether it has detected a message from server ECU 100a or ECU 100b, or client ECU 100c or ECU 100d indicating the termination of service provision or subscription, a communication error, an anomaly alert from the intrusion detection system, or an inconsistency in output between the main server and the sub-server when the sub-server is started. If the anomaly monitoring unit 204 determines that it has detected any of these events, it determines that an anomaly has occurred in ECU 100a or ECU 100b, and based on the service policy stored in the service information holding unit 205 and the vehicle status stored in the vehicle status holding unit 206, it determines whether to switch to the sub-server in order to safely continue providing the service.

[0122] The service information storage unit 205 stores information about the server ECU 100a or ECU 100b and the client ECU 100c or ECU 100d for each service, as well as the service policy. Details of the service information will be described later.

[0123] The vehicle state holding unit 206 holds state information indicating the state of the vehicle. The vehicle state holding unit 206 holds information related to vehicle operation, which is an example of state information, to determine whether the service should be safely continued or stopped, depending on the characteristics of the service. Details of the vehicle state will be described later.

[0124] [1.5 An example of app authentication information stored in the app authentication information storage unit] Figure 6A shows a first example of application authentication information stored in the application authentication information storage unit 103. Specifically, the application authentication information shown in Figure 6A is the application authentication information stored in the application authentication information storage unit 103 of the main server, server ECU 100a.

[0125] As shown in Figure 6A, the application authentication credentials contain confidential information indicating that the user has access rights to the service (in other words, the authority to act as a server providing the service).

[0126] The main server's public key is used to verify the signature generated by the main server's private key. Using this key, the application unit 102 generates a signature for the sub-server's public key, and the intermediary ECU 200 verifies the generated signature, thereby allowing the main server to grant privileges to the redundant sub-server.

[0127] The session key is shared with the intermediary ECU200 and used to encrypt the payload.

[0128] The sub-server public key and sub-server private key are generated or pre-existing by the main server and are used to grant the sub-server access rights to the services provided by the main server.

[0129] Furthermore, if the sub-server already possesses both the sub-server public key and the sub-server private key, it is not necessary for the application authentication information storage unit 103 of the main server, server ECU 100a, to store the sub-server public key and the sub-server private key.

[0130] Service authorization certificates are created by application vendors or vehicle manufacturers, etc., and each service ID contains information about the access rights to the service.

[0131] In Figure 6A, the main server public key is 0x123456789..., the main server private key is 0xabcdefabcdef..., the session key is 0xa787c89de989..., the sub-server public key is 0x1a2b3c4d5e6f..., and the sub-server private key is 0xfedcba.... The service authorization certificate describes the server authorization (also called "authorization as a server") for the service with service ID 10. This can also be said to be a description indicating that the application vendor or vehicle manufacturer has certified that server ECU100a has the authority to provide the above service as a server.

[0132] In this embodiment, the case where the application authentication information is stored in plain text is shown as an example, but the application authentication information may be stored encrypted. Furthermore, the application authentication information may be stored in secure memory that cannot be directly read from the application unit 102.

[0133] Figure 6B shows a second example of application authentication information stored in the application authentication information storage unit 103 in this embodiment. Specifically, the application authentication information shown in Figure 6B is the application authentication information stored in the application authentication information storage unit 103 of the server ECU 100b, which is a sub-server.

[0134] The application authentication information shown in Figure 6B includes the information from the application authentication information shown in Figure 6A, excluding the main server public key and the main server private key.

[0135] The information included in the app authentication information shown in Figure 6B is the same as that included in the app authentication information shown in Figure 6A, so a detailed explanation is omitted.

[0136] Furthermore, the client ECU also holds the same application authentication information as the server ECU.

[0137] Figure 6C shows a third example of application authentication information in this embodiment. Specifically, the application authentication information shown in Figure 6C is the application authentication information held by the client ECU 100c or 100d.

[0138] As shown in Figure 6C, application authentication credentials contain confidential information indicating that the user has access rights to the service (in other words, the rights to be a client receiving the service).

[0139] The information included in the application authentication information shown in Figure 6C is the same as that included in the application authentication information shown in Figure 6A, but differs in that it includes the client public key and client private key, respectively, instead of the main server public key and main server private key. In addition, the service authorization certificate contains the client authorization (also called "client authorization") for the service with service ID 10. This can be said to be a statement indicating that the application vendor or vehicle manufacturer has certified that client ECU 100c or 100d has the authorization to receive the above service as a client.

[0140] [1.6 An example of a service policy stored in the service policy storage unit] Figure 7 shows an example of a service policy stored in the service policy holding unit 104. For each service ID, the service policy includes a switching policy that indicates whether or not there are sub-server candidates and their addresses, whether or not proxy transmission is performed, the switching method in the event of an abnormality in a redundant sub-server configuration, the vehicle status and switching method at the time of switching, and a security policy.

[0141] We will now describe the service with the service ID 0x10 shown in Figure 7.

[0142] For service ID 0x10, there is a candidate for a sub-server, indicating that the ECU with the address 192.168.1.XX is a candidate for the sub-server. Proxy transmission is enabled, and the switching method is hot standby, meaning that switching is possible when the sub-server is running at the same time as the main server. The switching policy is "always possible," allowing the server ECU providing the service to switch regardless of the vehicle's running status. The security policy includes mediation and monitoring of SD messages.

[0143] The mediation of SD messages as a security policy is performed by the mediating ECU200. The mediating ECU200 terminates Offer messages, which are normally sent by broadcast, and verifies the appropriate server ECU and client ECU, thereby preventing attackers on the network from illegally obtaining service ID information. The mediating ECU200 performs access control so that only client ECUs that can access the service can send Find messages to the mediating ECU200 and obtain information from the appropriate server ECU after authentication.

[0144] The intermediary ECU200 may encrypt the Offer message payload using a pre-shared session key when mediating SD messages. This prevents the leakage of information related to the service ID even if an attacker illegally obtains messages on the network.

[0145] Security policy monitoring involves checking for any abnormalities in messages associated with the relevant service ID. Because Ethernet (registered trademark) generates faster and larger-capacity communication compared to CAN, narrowing the monitoring target reduces the processing load on the intermediary ECU200 while efficiently monitoring messages that could affect security.

[0146] Next, regarding the service ID 0x20, there is a candidate for the subserver (192.168.1.20), proxy transmission is not enabled, the switching method is any (i.e., both hot standby and cold standby are possible), and the switching policy allows only hot standby when the vehicle is running. In addition, the security policy is set to only allow SD mediation.

[0147] Next, regarding service ID 0x30, there is a candidate for the sub-server (192.168.1.XX), but no proxy transmission is enabled. The switching method is cold standby, and the switching policy allows server ECU switching only when the vehicle is stopped. Additionally, the security policy is set to allow SD mediation only during the initial registration.

[0148] The intermediary ECU200 is configured to mediate SD transmission only during the initial registration, eliminating the need to go through the intermediary ECU200 for SD transmission after the initial registration. Therefore, with the above configuration, the server ECU and client ECU can directly exchange service discovery messages, improving the real-time nature of communication. On the other hand, this increases the risk of impersonation by malicious ECUs, making it a suitable configuration for services where security is not required or where real-time performance is critical.

[0149] [1.7 An example of service information stored in the service information storage unit] Figure 8A shows an example of service information stored in the service information holding unit 205 of the intermediary ECU 200. As shown in Figure 8A, the service information is set based on the information contained in the service policy notified from the server ECU or client ECU. For each service ID, the service information includes the address and status of the main server, the address and status of the sub-server, whether or not there are any abnormalities occurring in the service, the address of the client ECU, and the service policy received from the server ECU (whether or not proxy transmission is being performed, the switching policy, the security policy). The service policy is shared between the server ECUs 100a and 100b and the intermediary ECU 200, and other information may change depending on the network status.

[0150] In Figure 8A, the main server address for the service with service ID 0x10 is 192.168.1.10, the main server status is active, the sub-server address is 192.168.1.20, the sub-server status is active, there are "no" errors, and the client ECU is 192.168.1.30. The service policy is the same as in Figure 7, so its explanation and description are omitted.

[0151] Next, the main server address for the service with service ID 0x20 is 192.168.1.10, the main server status is active, the sub-server address is 192.168.1.20, the sub-server status is stopped, there are "no" abnormalities, and the client ECU is 192.168.1.31. The service policy is omitted.

[0152] The main server address for the service with service ID 0x30 is 192.168.1.10, and the main server status is active. The sub-server address is 192.168.1.20, and the sub-server status is stopped. There are "no" abnormalities reported, and there are no specific client ECUs. Since the service can be received without requiring authentication, this indicates that the intermediary ECU 200 does not manage the client ECUs. The service policy is omitted.

[0153] [1.8 Example of access control information] Figure 8B shows an example of access control information held by the service management unit 202 of the mediating ECU 200. The access control information shown in Figure 8B is used by the service management unit 202 to determine whether it is appropriate to mediate a frame received by the communication control unit 201. As an example, the access control information shown in Figure 8B shows a combination of a service identifier, an identifier indicating the source or destination, and a type for the frame to be mediated. The service management unit 202 permits mediation of frames that match any of the combinations shown in the access control information, and prohibits mediation of frames that do not match any of the combinations shown in the access control information.

[0154] The access control information shown in Figure 8B indicates the combination of the service identifier, the source or destination identifier, and the type for the frame to be mediated for the service with service ID 0x10.

[0155] For example, a frame with a source address of 192.168.1.10 (i.e., the main server's address) and a frame type of Offer message is indicated to be mediated. A frame with a source address of 192.168.1.20 (i.e., the sub-server's address) and a frame type of Offer message is indicated to be mediated. A frame with a destination address of 192.168.1.30 (i.e., the client ECU's address) and a frame type of Offer message is indicated to be mediated.

[0156] Furthermore, it is indicated that frames with a source address of 192.168.1.30 (i.e., the client ECU's address) and a frame type of Find message should be mediated. It is also indicated that frames with a destination address of 192.168.1.10 (i.e., the main server's address) and a frame type of Find message should be mediated. Finally, it is indicated that frames with a destination address of 192.168.1.20 (i.e., the sub-server's address) and a frame type of Find message should be mediated.

[0157] In addition, in the access control information shown in Figure 8B, the field labeled "any" indicates that any address is acceptable.

[0158] Furthermore, access control information can also be used to indicate a combination of a service identifier, a source or destination identifier, and a type for frames that should not be intermediated. In this case, the service management unit 202 prohibits the intermediation of frames that fall under any of the combinations indicated in the access control information, and permits the intermediation of frames that do not fall under any of the combinations indicated in the access control information.

[0159] Although access control information is presented in table format here, it is not limited to table format. Any information that provides the basis for the service management unit 202 to make the same determination as described above may be in other formats, such as being expressed as an algorithm.

[0160] [1.9 An example of vehicle status stored in the vehicle status retention unit] Figure 9 shows an example of a vehicle state stored in the vehicle state holding unit 206 of the intermediary ECU 200. As shown in Figure 9, the vehicle state stores the state of the vehicle equipped with the in-vehicle network.

[0161] Figure 9 shows that the vehicle is in motion. The vehicle's driving status can be notified to the intermediary ECU 200 from other ECUs via the in-vehicle network.

[0162] By having the intermediary ECU200 understand the vehicle status, it becomes possible to mediate service-oriented communication messages according to the characteristics of the service, or to control the timing of switching to the sub-server.

[0163] In this embodiment, an example of the vehicle being in motion is shown, but the vehicle state is not limited to this. The vehicle state may include, for example, whether the vehicle is stopped, in motion, or traveling at high speed. In addition, the vehicle state may include whether a specific function is operating. Examples of functions include autonomous driving, cruise control, automatic parking, or emergency automatic braking. Furthermore, states related to power, such as whether the vehicle is charging or discharging, may also be included.

[0164] For example, if the vehicle state is autonomous driving, the importance of real-time (or security) of certain services increases, so the intermediary ECU 200 can improve real-time or security by switching whether or not proxy transmission is enabled. Specifically, by setting proxy transmission to "off," the intermediary ECU 200 can improve real-time by allowing the server ECU and client ECU to communicate directly. Alternatively, by setting proxy transmission to "on," the intermediary ECU 200 can improve security by having the intermediary ECU 200 verify the message.

[0165] Furthermore, some services require continuous operation, and even if a failure occurs in the main server, having a backup server on standby allows for seamless switching to the backup server, enhancing robustness. In such services, to prioritize safety, the intermediary ECU200 may be configured to switch to the backup server only when the vehicle is stopped or when specific functions are disabled.

[0166] [1.10 Service Information Registration Sequence for Intermediary ECU] Figure 10 shows the service information registration sequence of the intermediary ECU 200 in this embodiment.

[0167] Figure 10 shows the sequence of events from when the intermediary ECU 200 mediates communication between the server ECU 100a and the client ECU 100c until service detection is performed. During this time, the intermediary ECU 200 updates the service information.

[0168] Specifically, the intermediary ECU200 performs the following processes:

[0169] Specifically, the communication control unit 201 receives an Offer message from the server ECU 100a containing first service information indicating the service to be provided, before providing the service. The communication control unit 201 also receives a Find message from the client ECU 100c containing second service information indicating the target of the service search, before providing the service. The service management unit 202 sends an Offer message containing the same first service information as the second service information contained in the Find message received by the communication control unit 201 to the client ECU 100c, the source of the received Find message, via the communication control unit 201. Here, the Offer message corresponds to a service provision frame, and the Find message corresponds to a service search frame.

[0170] The above process will be explained in detail below.

[0171] In step S101, the server ECU 100a sends an Offer message (also simply referred to as "Offer") to the intermediary ECU 200 that contains information indicating the services it provides. At this time, the server ECU 100a sends a service authorization certificate (see Figure 6A) indicating access rights related to the service, and information regarding the service policy, along with the Offer message.

[0172] In step S102, the intermediary ECU 200 receives the Offer message sent by the server ECU 100a in step S101, verifies the service authorization certificate, and confirms that the server ECU 100a has server authorization for the service. If the verification is successful, the intermediary ECU 200 determines that the Offer frame is valid.

[0173] In step S103, the intermediary ECU 200 updates the service information based on the information about server ECU 100a (IP address, port number, etc.) and the service policy included in the Offer message sent by server ECU 100a in step S101.

[0174] In step S104, the client ECU 100c sends a Find message (also simply referred to as "Find") containing information about the service it wishes to receive to the intermediary ECU 200. At this time, the client ECU 100c also sends a service authorization certificate (see Figure 6C) in the Find message, indicating that it has client authorization for the service it wishes to receive.

[0175] In step S105, the intermediary ECU 200 receives the Find message sent by the client ECU 100c in step S104, verifies the service authorization certificate, and confirms that the client ECU 100c has client authorization for the service. If the verification is successful, the intermediary ECU 200 determines that the Find frame is valid.

[0176] In step S106, the intermediary ECU 200 adds the client's information to the service information.

[0177] In step S107, the intermediary ECU 200 sends an Offer message to the client ECU 100c. If proxy transmission for the service is enabled, the intermediary ECU 200 sends the Offer message to the client ECU 100c as the service provider. If proxy transmission is disabled, the server ECU 100a sends the Offer message to the client ECU 100c as the service provider.

[0178] In step S108, the client ECU 100c receives the Offer message sent by the mediating ECU 200 in step S107 and registers server information based on the received Offer message.

[0179] [1.11 Communication sequence when only SD mediation is performed by the mediating ECU200] Figure 11A shows the communication sequence of a service that performs only SD mediation in this embodiment.

[0180] Figure 11A shows an example of a communication sequence when the mediating ECU 200 is set to SD mediation only in the security policy and proxy transmission is set to "none". Note that the sequence shown in Figure 11A is the sequence after the SD mediation shown in Figure 10 is completed.

[0181] In step S109, the client ECU 100c sends a Subscribe message to the server ECU 100a based on the registered server information. The sent Subscribe message is received by one port of the communication control unit 201 of the intermediary ECU 200 and transmitted from another port, thereby forwarding it to the server ECU 100a. In this way, messages sent from the client ECU 100c to the server ECU 100a via the intermediary ECU 200 are forwarded by reception and transmission via the ports of the communication control unit 201 of the intermediary ECU 200. The same applies thereafter.

[0182] In step S110, the server ECU 100a receives the Subscribe message sent by the client ECU 100c in step S109 and sends a SubscribeAck message back to the client ECU 100c. The sent SubscribeAck message is received by one port of the communication control unit 201 of the intermediary ECU 200 and transmitted from another port, thereby forwarding it to the client ECU 100c. In this way, messages sent by the server ECU 100a to the client ECU 100c are forwarded by reception and transmission via ports of the communication control unit 201 of the intermediary ECU 200. The same applies thereafter.

[0183] In step S111, the server ECU100a sends a SOME / IP message to the client ECU100c to provide service.

[0184] In step S112, the client ECU100c receives the SOME / IP message sent by the server ECU100a in step S111.

[0185] In step S113, the server ECU 100a sends a SOME / IP message after a predetermined period of time has elapsed since receiving the SOME / IP message in step S112.

[0186] In step S114, the client ECU 100c receives the message sent by the server ECU 100a in step S113. After step S114, communication between the server ECU 100a and the client ECU 100c continues.

[0187] [1.12 Communication sequence when using the intermediary ECU200 for proxy transmission] Figure 11B shows the communication sequence of the proxy transmission service in this embodiment.

[0188] Figure 11B shows an example of a communication sequence when the mediating ECU 200 is set to "enabled" for proxy transmission. Note that the sequence shown in Figure 11B is the sequence after the SD mediation shown in Figure 10 is completed.

[0189] In Figure 11B, the same reference numerals are used for processes that are the same as those in Figure 11A, and detailed explanations are omitted.

[0190] In step S121, the proxy transmission unit 203 of the intermediary ECU 200 receives the Subscribe message sent by the client ECU 100c in step S109, changes the sender of the received Subscribe message (i.e., the service recipient) to the IP address of the intermediary ECU 200, and sends the modified Subscribe message to the server ECU 100a. Note that in step S121, the server's IP address may be changed while the client's IP address remains unchanged. Alternatively, in step S121, the client's IP address may be changed while the server's IP address remains unchanged. Note that an arbitrary identifier may be used instead of an IP address. The same applies hereafter.

[0191] In step S122, the proxy transmission unit 203 of the intermediary ECU 200 receives the SubscribeAck message sent by the server ECU 100a in step S110, changes the source (i.e., service provider) of the received SubscribeAck message to the IP address of the intermediary ECU 200, and sends the modified SubscribeAck message to the client ECU 100c.

[0192] In step S123, the proxy transmission unit 203 of the intermediary ECU 200 receives the message sent by the server ECU 100a in step S111, changes the source of the received message (i.e., the service provider) to the intermediary ECU 200, and sends the modified message to the client ECU 100c.

[0193] In step S124, the proxy transmission unit 203 of the intermediary ECU 200 receives the message sent by the server ECU 100a in step S113, changes the source of the received message (i.e., the service provider) to the intermediary ECU 200, and sends the modified message to the client ECU 100c.

[0194] [1.13 Registration sequence when a sub-server initiates hot standby] Figure 12 shows the sub-server registration sequence of the intermediary ECU 200 in this embodiment. Figure 12 shows the sub-server registration sequence when the server ECU 100b, which is a sub-server, is in hot standby mode.

[0195] Furthermore, the process shown in Figure 12 can also be described as the process that occurs when server ECUs 100a and 100b begin to adopt a redundant configuration.

[0196] In step S201, the main server, server ECU100a, sends a sub-server startup message to the sub-server, server ECU100b. At this time, server ECU100a includes a sub-server certificate in the sub-server startup message, indicating that the sub-server has been granted authority over the service by the main server.

[0197] In step S202, server ECU 100b receives the sub-server startup message sent by server ECU 100a in step S201 and starts the application that provides the service corresponding to the received sub-server startup message.

[0198] In step S203, the sub-server, server ECU100b, sends an Offer message to the intermediary ECU200. At this time, server ECU100b sends authentication information indicating that it has the authority of a sub-server in the Offer message.

[0199] In step S204, the intermediary ECU 200 receives the Offer sent by the server ECU 100b in step S203 and verifies the service information and authentication information contained in the received Offer message.

[0200] In step S205, the intermediary ECU200 actively updates the status of the sub-server in the service information and registers the sub-server's address.

[0201] [1.14 Communication sequence when proxy transmission is enabled] Figure 13 shows the communication sequence for proxy transmission by the intermediary ECU 200 in this embodiment. Figure 13 shows the communication sequence for a service where proxy transmission by the intermediary ECU 200 is enabled. Note that the sequence shown in Figure 13 is the sequence after the service information registration sequence in Figure 10 and the sub-server startup sequence in Figure 12 have been completed.

[0202] In Figure 13, server ECUs 100a and 100b are configured in a redundant configuration.

[0203] Furthermore, it is assumed that a session between client ECU100c and intermediary ECU200, and a session between server ECU100a and server ECU100b and intermediary ECU200 are established when client ECU100c sends a Subscribe message to intermediary ECU200, and intermediary ECU200 sends a Subscribe message to server ECU as a client ECU.

[0204] In step S206, the main server, server ECU100a, sends a message with service ID 10 to the intermediary ECU200. The intermediary ECU200 receives the message and enters a waiting state for a predetermined period of time.

[0205] In step S207, the sub-server, server ECU100b, sends a message with service ID 10 to the intermediary ECU200, as described above.

[0206] In step S208, the intermediary ECU 200 compares the message received in step S206 from the main server, server ECU 100a, with the message received in step S207 from the sub-server, server ECU 100b. The message comparison by the intermediary ECU 200 verifies, for example, whether the payloads contained in the messages match, or whether the differences are within a predetermined error range.

[0207] In step S209, the intermediary ECU 200, acting as a server ECU, sends a message with service ID 10 to the client ECU 100c. The message sent at this time may be a forwarded message received from the main server, server ECU 100a. Alternatively, the message may be a forwarded message received from the sub-server, server ECU 100b. However, if there is an inconsistency in the message received from server ECU 100a, the intermediary ECU 200 may discard the message. Furthermore, if messages are received only from the main server or sub-server within a predetermined period, the intermediary ECU 200 may forward the payload contained in the received message as is. Details are explained in Figure 14.

[0208] In step S210, the client ECU 100c receives the message sent by the mediating ECU 200 in step S209.

[0209] [1.15 Communication sequence when an abnormality occurs during proxy transmission] Figure 14 shows the communication sequence for proxy transmission in the event of an abnormality in this embodiment. Figure 14 shows the communication sequence when a communication abnormality occurs for a service where proxy transmission by the intermediary ECU 200 is enabled. Note that the sequence shown in Figure 14 is the sequence after the service information registration sequence in Figure 10 and the sub-server startup sequence in Figure 12 have been completed.

[0210] Furthermore, it is assumed that a session between client ECU100c and intermediary ECU200, and a session between server ECU100a and server ECU100b and intermediary ECU200 are established when client ECU100c sends a Subscribe message to intermediary ECU200, and intermediary ECU200, as well as server ECU100a and server ECU100b, sends a Subscribe message to server ECU200.

[0211] In Figure 14, server ECUs 100a and 100b are configured in a redundant configuration.

[0212] In step S211, the server ECU 100b sends a message with service ID 10 to the intermediary ECU 200. The intermediary ECU 200 receives the sent message and enters a waiting state for a predetermined period of time.

[0213] In step S212, the intermediary ECU 200 detects a loss of communication with the main server, server ECU 100a. The intermediary ECU 200 detects a loss of communication with the main server by detecting that it has not received any messages from the main server, server ECU 100a, during a predetermined standby period.

[0214] In step S213, the intermediary ECU200 sends a message with service ID 10 to the client ECU100c based on the message from the sub-server, server ECU100b.

[0215] The intermediary ECU 200 may control whether or not to send the above message depending on the type of service. Furthermore, the intermediary ECU 200 may control whether or not to send the above message depending on status information indicating the vehicle's status.

[0216] In step S214, the intermediary ECU 200 updates the service information to "Anomaly occurred" and updates the status of the main server to "Stopped". The intermediary ECU 200 may also perform predetermined processing to be performed when an anomaly occurs in the sub-server. The above update processing may be included in the above predetermined processing.

[0217] In step S215, the client ECU100c receives a message.

[0218] [1.16 Switching sequence to sub-server in case of an anomaly] Figure 15 shows the switching sequence to the sub-server in the event of an abnormality in this embodiment. Figure 15 shows the sequence when the mediating ECU 200 detects an abnormality in the server ECU 100a and switches to the sub-server to continue providing the service. Note that the sequence shown in Figure 15 is the sequence after the SD mediation shown in Figure 10 is completed. The vehicle status is assumed to be "stationary".

[0219] In Figure 15, server ECUs 100a and 100b are configured in a redundant configuration.

[0220] In step S301, when the server ECU100a stops providing the service for any reason, it broadcasts a StopOffer message (also simply referred to as "StopOffer") to the client ECU100c for reception.

[0221] In step S302, the client ECU 100c stops receiving the service in response to receiving StopOffer in step S301.

[0222] In step S303, the intermediary ECU 200 detects that an abnormality has occurred in the main server, server ECU 100a, based on the receipt of the StopOffer message.

[0223] In step S304, the intermediary ECU200 obtains the current vehicle status in order to perform a server switchover.

[0224] In step S305, if the vehicle status is "stationary", the intermediary ECU 200 determines that server switching is possible and sends a startup message to the server ECU 100b, which is a message that starts the sub-server based on the service information. If the vehicle status is "driving", the intermediary ECU 200 determines that server switching is not possible and terminates the process.

[0225] In step S306, the server ECU 100b, upon receiving a startup message sent by the intermediary ECU 200, starts an application to provide the service with service ID 30.

[0226] In step S307, the server ECU100b notifies the client ECU100c of the server information by broadcasting an Offer message.

[0227] In step S308, the client ECU100c updates the server information to the sub-server, server ECU100b, in response to receiving the Offer message in step S307. This allows the client ECU100c to once again receive the service for service ID 30, which was stopped in step S301.

[0228] [1.17 Flowchart of SD Processing for Intermediate ECU] Figure 16 is a flowchart showing the processing of SD messages by the intermediary ECU200.

[0229] In step S400, the intermediary ECU 200 receives a message from either the server ECU 100a or 100b, or from either the client ECU 100c or 100d.

[0230] In step S401, the intermediary ECU 200 determines whether the message received in step S400 is an Offer message for a service. If it is determined to be an Offer message, the intermediary ECU 200 executes step S402; otherwise, it executes step S410.

[0231] In step S402, the intermediary ECU 200 determines whether the service information related to the Offer message received in step S400 is a service already registered in its own service information storage unit 205. If it is a registered service, the intermediary ECU 200 executes step S403. Otherwise, the intermediary ECU 200 executes step S407.

[0232] In step S403, if the service related to the Offer message received in step S400 is already registered in the service information storage unit 205, the mediating ECU 200 checks whether SD mediation is available for the corresponding service stored in the service information storage unit 205. If SD mediation is available, the mediating ECU 200 executes step S405. Otherwise, the mediating ECU 200 executes step S404.

[0233] In step S404, the intermediary ECU 200 forwards the Offer message received in step S400 according to the header information.

[0234] In step S405, the intermediary ECU 200 determines whether the information contained in the Offer message received in step S400 matches the service information stored in the service information holding unit 205. Specifically, the intermediary ECU 200 determines whether the service ID contained in the Offer message matches the service ID of the server contained in the service information.

[0235] If the intermediary ECU 200 determines that the information contained in the offer message is consistent with the service information, it executes step S406; otherwise, it executes step S408.

[0236] In step S406, the intermediary ECU 200 updates the service information based on the information contained in the Offer message received in step S400, and then terminates the process.

[0237] In step S407, the intermediary ECU 200 verifies the authentication information contained in the Offer message received in step S400 and determines whether the verification is successful or not. If the authentication information is successfully verified, the intermediary ECU 200 executes step S409; otherwise, it executes step S408.

[0238] In step S408, the intermediary ECU 200 discards the Offer message received in step S400.

[0239] In step S409, the intermediary ECU 200 updates the service information stored in the service information holding unit 205 based on the service policy included in the Offer message received in step S400, and then terminates the process.

[0240] In step S410, the intermediary ECU 200 determines whether the message received in step S400 is a Find message. If it is determined to be a Find message, the intermediary ECU 200 executes step S411; otherwise, it terminates the process.

[0241] In step S411, the intermediary ECU 200 determines whether the information of the client ECU that sent the Find message received in step S400 is registered in the service information holding unit 205. If it determines that the client ECU information is registered, the intermediary ECU 200 executes step S412; otherwise, it executes step S413.

[0242] In step S412, the intermediary ECU 200 sends an Offer message containing server information to the client ECU based on the service information, and then terminates.

[0243] In step S413, the intermediary ECU 200 verifies the authentication information contained in the Find message received in step S400 and determines whether the verification is successful or not. If the authentication information verification is successful, the intermediary ECU 200 executes step S414; otherwise, it executes step S415.

[0244] In step S414, the intermediary ECU 200 registers client information in the service information stored in the service information holding unit 205 and executes step S412.

[0245] In step S415, the intermediary ECU 200 discards the Find message received in step S400.

[0246] In this embodiment, the server information is updated when the service information consistency check is successful (step S406). However, instead of checking the service information consistency (step S405), authentication information verification (step S407) may be performed, and the server information may be updated when the verification is successful.

[0247] [1.18 Flowchart of message transmission process by intermediary ECU] Figure 17 is a flowchart showing the processing of SOME / IP messages (more specifically, SOME / IP messages other than SD messages) by the intermediary ECU 200 in this embodiment.

[0248] In step S501, the mediating ECU200 receives a SOME / IP message other than an SD message.

[0249] In step S502, the intermediary ECU 200 determines whether the service corresponding to the message received in step S501 is a service to be monitored. If it is determined to be a service to be monitored, the intermediary ECU 200 executes step S503; otherwise, the intermediary ECU 200 executes step S505.

[0250] In step S503, the intermediary ECU 200 determines whether the message received in step S501 matches the service information stored in the service information holding unit 205. Specifically, if the message received in step S501 is a message sent from a server (Notification or Response), the intermediary ECU 200 determines whether the source of the message matches the registered server information and whether the destination of the message matches the registered client information. If the message received in step S501 is a message sent from a client (Request or Request no Response), the intermediary ECU 200 determines whether the source of the message matches the registered client information and whether the destination of the message matches the registered server information. If the intermediary ECU 200 determines that the message matches the service information, it executes step S504; otherwise, it executes step S506.

[0251] In step S504, the intermediary ECU 200 obtains whether or not the target service is being transmitted by proxy by referring to the service information stored in the service information holding unit 205. If there is "no" proxy transmission, the intermediary ECU 200 executes step S505. If there is "yes" proxy transmission, the intermediary ECU 200 executes step S507.

[0252] In step S505, the intermediary ECU200 forwards the received message.

[0253] In step S506, the intermediary ECU 200 discards the received message.

[0254] In step S507, the intermediary ECU 200 determines whether the type of the received message is a Request, if the service of the received message is "proxy transmission enabled". If the type of the received message is a Request, the intermediary ECU 200 executes step S508. If the type of the received message is not a Request, the intermediary ECU 200 executes step S509.

[0255] In step S508, the intermediary ECU 200 refers to the service information stored in the service information holding unit 205, forwards the received Request message to the active server, and terminates processing. At this time, the intermediary ECU 200 rewrites the sender included in the Request message to the intermediary ECU 200 and forwards the Request message.

[0256] In step S509, the intermediary ECU 200 determines whether there are other active servers for the target service, assuming that the message received in step S501 was sent from a server. At this time, the intermediary ECU 200 makes the above determination by referring to the service information stored in the service information holding unit 205. If it is determined that there are no other active servers, the intermediary ECU 200 executes step S511. If there are active servers, the intermediary ECU 200 executes step S510.

[0257] In step S510, the intermediary ECU 200 determines whether it has already received a message from another active server. Message reception confirmation is performed, for example, by pre-registering received messages from servers for a predetermined period and determining whether a message from the relevant server exists among the stored messages. If a message has been received from another active server ECU, the intermediary ECU 200 executes step S511; otherwise, it executes step S513.

[0258] In step S511, the intermediary ECU 200 selects a message. Possible methods for selecting a message include, for example, prioritizing the selection of messages from the main server, prioritizing the selection of messages received more recently, and comparing multiple messages and prioritizing the selection of the message that is the median or close to the median.

[0259] In step S512, the intermediary ECU200 sends the message on behalf of the other party.

[0260] In step S513, the intermediary ECU 200 waits for a predetermined period of time and determines whether or not to receive a message from another active server ECU.

[0261] In step S514, the intermediary ECU 200 detects that an abnormality has occurred in the server and updates the server information in the service information holding unit 205 to stopped for servers that were active and had not received any messages.

[0262] [1.19 Switchover flowchart when a communication anomaly is detected on the main server] Figure 18 is a flowchart showing the server switching process when a communication anomaly is detected on the main server in this embodiment.

[0263] In step S601, the intermediary ECU 200 detects a communication anomaly in the main server and updates the main server information and anomaly detection information among the service information stored in the service information holding unit 205. A communication anomaly in the main server can be detected, for example, by notification of an error message from the main server, notification of a StopOffer message, or a communication interruption for a predetermined period of time.

[0264] In step S602, the mediation ECU 200 refers to the service information stored in the service information storage unit 205 and determines whether the sub-server is active. If it is determined that the sub-server is active, the mediation ECU 200 executes step S603. Otherwise, the mediation ECU 200 executes step S606.

[0265] In step S603, the mediation ECU 200 refers to the vehicle state stored in the vehicle state storage unit 206 and the service policy among the service information, and determines whether the vehicle state matches the switching policy (hot standby). If it is determined that the vehicle state matches the switching policy, the mediation ECU 200 executes step S604. Otherwise, the mediation ECU 200 ends the process without doing anything.

[0266] In step S604, the mediation ECU 200 acquires whether proxy transmission of the target service is available. If proxy transmission of the target service is "yes", the mediation ECU 200 ends without doing anything, that is, the service is continued by the sub-server. If proxy transmission of the target service is "no", the mediation ECU 200 executes step S605.

[0267] In step S605, the mediation ECU 200 notifies the client ECU of the switch of the server ECU by transmitting an Offer message including the information of the sub-server as the service provider, and ends the process.

[0268] In step S606, the mediation ECU 200 checks whether the vehicle state matches the switching policy (cold standby). If the vehicle state matches the switching policy (cold standby), the mediation ECU 200 executes step S607. Otherwise, the mediation ECU 200 ends the process.

[0269] In step S607, the mediation ECU 200 starts the sub-server. The start of the sub-server is performed, for example, by transmitting a message requesting the start of an application that provides the service to the sub-server.

[0270] In step S608, the mediation ECU 200 verifies the authentication information based on the Offer message transmitted after the sub-server is started, and acquires the server information, thereby updating the service information in the service information holding unit 205.

[0271] In step S609, the mediation ECU 200 transmits an Offer message including the information of the sub-server as the service provider to the client ECU.

[0272] [1.20 Effects of the Embodiment] In the in-vehicle network system according to the embodiment, the mediation ECU 200 verifies the authentication information regarding SOME / IP SD communication to authenticate whether it is a legitimate server or client. Thereby, it becomes possible to manage the access right to the service by an unauthorized ECU, prevent spoofing by an unauthorized ECU, and enhance security.

[0273] Furthermore, the mediation ECU 200 changes the mediation method of service-oriented communication according to the service policy. Thereby, for messages that require high security, by performing monitoring and proxy transmission by the mediation ECU 200, it becomes possible to monitor the messages regarding the service while concealing the server information. Also, for messages that require high real-time performance, by performing mediation only when the service is detected, it becomes possible to maintain real-time performance while enhancing security.

[0274] Furthermore, the intermediary ECU200 selects a method to switch to a sub-server if an abnormality occurs at the service provider, depending on the service policy and vehicle status. This makes it possible to enhance the robustness of the service while considering the impact that the service has on vehicle operation, depending on the type of service.

[0275] (Modified example of the embodiment) In this embodiment, another form of a service intermediary device that appropriately controls access to communications related to service provision will be described.

[0276] Figure 19A shows the configuration of the service intermediary device 300 in this modified example. The service intermediary device 300 corresponds to the intermediary ECU 200 in the above embodiment.

[0277] As shown in Figure 19A, the service intermediary device 300 comprises a communication control unit 301 and a service management unit 302.

[0278] The communication control unit 301 is connected to both the server unit and the client unit in a service provision system that provides services from a server unit to a client unit via service-oriented communication, and receives frames used for service provision from either the server unit or the client unit. The communication control unit 301 corresponds to the communication control unit 201 in the above embodiment.

[0279] The service management unit 302 determines whether the combination of the service identifier included in the frame received by the communication control unit 301, the identifier indicating the source or destination of the frame, and the type of frame is appropriate, and outputs the result of the determination. The service management unit 302 corresponds to the service management unit 202 in the above embodiment.

[0280] The service intermediary device 300 may also include a proxy transmission unit 303 that corresponds to the proxy transmission unit 203 provided in the intermediary ECU 200 of the above embodiment.

[0281] Furthermore, the service intermediary device 300 may also include a vehicle state holding unit 304, which corresponds to the vehicle state holding unit 206 provided in the intermediary ECU 200 of the above embodiment.

[0282] Figure 19B is a flowchart showing the processing of the service intermediary device 300 in this modified example.

[0283] In step S1, the communication control unit 301 receives a frame used to provide the service from the server unit or client unit.

[0284] In step S2, the service management unit 302 determines whether the combination of the service identifier included in the frame received by the communication control unit 301 in step S1, the identifier indicating the source or destination of the frame, and the type of frame is appropriate.

[0285] In step S3, the service management unit 302 outputs the result of the determination in step S2.

[0286] Through the above series of processes, the service intermediary device 300 appropriately controls access to communications related to service provision.

[0287] (Other variations) Although this disclosure has been described based on the embodiments described above, it goes without saying that this disclosure is not limited to the embodiments described above. The following cases are also included in this disclosure.

[0288] (1) In the above embodiment, the processing operation was described as an example of SOME / IP communication, but it is not limited to this and may be other service-oriented communication or Publish / Subscribe type communication. For example, it may be Data Distribution Service (DDS) communication.

[0289] (2) In the above embodiment, processing examples of Offer and Find in the processing of SD messages are shown in FIG. 16, but other types of SD messages may be processed. For example, for Subscribe as well, confirmation of client information may be performed. This expands the scope of message monitoring and can be expected to improve security.

[0290] (3) In the above embodiment, as an in-vehicle network system, the types of ECUs are divided into server ECUs and client ECUs, but actually, the server ECU may be a client ECU, or the client ECU may play the role of the server ECU. In this embodiment, it is merely called a server ECU or a client ECU by focusing on a specific service.

[0291] (4) In the above embodiment, the ECU notifies the application authentication information and the mediation ECU 200 verifies the authentication information, but the mediation ECU 200 may hold the authentication information in advance. Or, at the first startup during the factory assembly stage, the notified authentication information may be verified and held in the non-volatile memory. This eliminates the need to verify the authentication information every time the vehicle is started, and is effective in reducing the communication volume of the in-vehicle network and the processing load of the mediation ECU 200.

[0292] (5) In the above embodiment, the application authentication information was held in plain text, but it may be held in an encrypted form. Similarly, the service policy may also be held in an encrypted form.

[0293] (6) In the above embodiment, an example where the mediation ECU 200 has an Ethernet switch with multiple ports and each ECU communicates via the mediation ECU 200 is shown, but the mediation ECU 200 may not have an Ethernet switch. For example, the server ECU and the client ECU may provide services by communicating only with the mediation ECU 200. This enables the mediation of services regardless of the physical arrangement of the mediation ECU 200.

[0294] (7) In the above embodiment, although not described, the public keys of the car manufacturer and the application vendor are held and the validity of the application authentication information is verified.

[0295] (8) In the above embodiment, Ethernet communication is assumed to be conducted in plain text, but encrypted communication such as IPsec, MACsec, or TLS may be used. Alternatively, the payload may be encrypted using a pre-shared session key. This makes it possible to conceal information about the service from attackers who access the network and eavesdrop, which is effective.

[0296] (9) In the above embodiment, an example was shown in which all networks are connected, but they may be logically separated by a Virtual LAN (VLAN). This increases the security strength and is effective.

[0297] (10) In the above embodiment, an example was shown in which a session key is held as an example of application authentication information, but a session key is not a required configuration.

[0298] (11) In the above embodiment, an example of service information was shown in which the IP address and state are stored as the main state, but the information to be stored is not limited to this. For example, the port number of the service provider may be included. Similarly, the port number may be included as client information. This makes it possible to detect, for example, when a malicious application is running on a server with a legitimate IP address and communication is coming from a malicious port number, which is effective in improving security.

[0299] (12) In the above embodiment, whether or not proxy transmission is performed was determined by the service policy, but it may also be determined in combination with the vehicle status. For example, for services where the requirement for real-time performance changes depending on the vehicle status, the presence or absence of proxy transmission may be switched depending on the vehicle status.

[0300] (13) In the above embodiment, the presence or absence of proxy transmission was determined by the service policy, but it may also be determined according to the type of message. Figure 19C shows a flowchart in which the service mediation method is determined by the mediation ECU 200. Figure 19C shows an example in which the mediation method is determined based on attributes set for each service. The service attributes may be the type of service (status notification, control signal, diagnosis, update) or the attributes of the status signal (public / private, control decision information, user notification information).

[0301] In step S701, the intermediary ECU200 receives the service attributes. The service attributes may be included in the Offer message, exchanged through means other than the SOME / IP message, or described in a pre-existing manifest file for each service.

[0302] In step S702, the intermediary ECU 200 determines whether the service type is a status notification. If it determines that the service is a status notification, the intermediary ECU 200 executes step S703. If it is not a status notification service, it executes step S710.

[0303] In step S703, the intermediary ECU 200 determines whether the attributes of the service status signal are public information. If it determines that the attributes of the service status signal are public information, the intermediary ECU 200 executes step S704. If it determines that the attributes of the service status signal are not public information, the intermediary ECU 200 executes step S705.

[0304] Here, a service status signal refers to a status notification sent by a service. Status signals have attributes. For example, if a status signal is information that can be obtained by all ECUs participating in the network system, it is assigned the attribute "public information". Also, if a control ECU performs control based on a status signal, it is assigned the attribute "control instruction information (command information)" or "control decision information (sensor information)". Furthermore, signals that are not directly related to the control of the control ECU but are used to notify users such as drivers via voice or screen are assigned the attribute "user notification information". Depending on the attributes of these status signals, the security level (i.e., whether or not there is service mediation or proxy transmission) may be determined.

[0305] In step S704, the mediating ECU200 determines that it does not matter which client the service is provided to, and therefore sets the mediation method for the service to "no service mediation" and "no proxy transmission," and terminates the process.

[0306] In step S705, the intermediary ECU 200 determines whether the attributes of the service status signal are information used for control decisions. If it determines that the attributes of the service status signal are information used for control decisions, the intermediary ECU 200 executes step S707. If it determines that the attributes of the service status signal are not information used for control decisions, the intermediary ECU 200 executes step S708.

[0307] In step S707, the mediating ECU200, given the requirement for real-time performance, sets the mediation method for the service to "no proxy transmission" and "intermediation of service" and terminates processing.

[0308] In step S708, the intermediary ECU 200 determines whether the attribute of the service status signal is user notification information. If it determines that the attribute of the service status signal is user notification information, it executes step S709. If the status is not user notification information, the intermediary ECU 200 executes step S710.

[0309] In step S709, the intermediary ECU 200, prioritizing information reliability over real-time performance, sets the service's intermediation method to "proxy transmission enabled" and "service intermediation enabled," and then terminates the process.

[0310] In step S710, the mediating ECU200 sets the service mediation method to "enabled" and "disabled" as the default settings for the service.

[0311] (14) In the above embodiment, access rights were managed by the intermediary ECU 200 verifying authentication information, but it is not necessary to verify the authentication information.

[0312] (15) In the above embodiment, when an inconsistency in service information occurred, the intermediary ECU 200 discarded the message. However, the processing when an inconsistency in service information occurs is not limited to discarding the message. For example, the intermediary ECU 200 may save information about the inconsistency as a log or notify an external party. Figure 20 shows an example of a log that is notified externally. The log that is notified externally may be displayed on a display for visualization.

[0313] Figure 20 shows that the log ID, which is the serial ID of the anomaly detection log, is 100200, and the anomaly code indicating the type of anomaly is 0x10 (service policy violation). Further details of the detection indicate that an anomaly was detected in the access source information of the service with service ID 0x10. The original packet that detected the anomaly is also included in the log, and the actions taken at the time of the anomaly detection include discarding the original packet and attempting to switch to a sub-server, but the vehicle status did not meet the conditions of the switching policy, resulting in a non-switched state.

[0314] (16) In the above embodiment, the process of the intermediary ECU 200 switching to a sub-server when an abnormality is detected in the main server was shown, but the intermediary ECU 200 may also switch to a sub-server at times other than when an abnormality is detected. For example, the intermediary ECU 200 may perform load balancing by switching to a sub-server in response to an increase in the processing load or communication bandwidth of the main server. Alternatively, a sub-server may be selected according to the vehicle status. For example, the server load may be maintained for each vehicle status, and the intermediary ECU 200 may switch to the server with the lowest load. Alternatively, a server priority may be set, and the intermediary ECU 200 may select a server according to the server priority. For example, the intermediary ECU 200 may calculate a priority according to the vehicle status, communication bandwidth, server load, and function in operation, and select an appropriate server according to the priority.

[0315] (17) In the above embodiment, an example was shown in which there is one subserver, but there may be multiple subservers.

[0316] (18) In the above embodiment, when sending a message on behalf of others, the intermediary ECU 200 waited for messages from multiple servers to be received, but it may also forward the first message it receives to the client. This reduces communication delay and is effective. After forwarding the message, the intermediary ECU 200 may also detect the occurrence of abnormal communication by comparing it with messages from other servers. This makes it possible to detect malicious communication and is effective in improving security.

[0317] (19) Specifically, each device in the above embodiment is a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is stored in the RAM or hard disk unit. Each device achieves its function by operating the microprocessor in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to the computer in order to achieve a predetermined function.

[0318] (20) In the above embodiments, each device may have some or all of its constituent components made up of a single system LSI (Large Scale Integration). The system LSI is a multi-functional LSI manufactured by integrating multiple components onto a single chip, and specifically, it is a computer system comprising a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its function by operating the microprocessor in accordance with the computer program.

[0319] Furthermore, each component of the above-mentioned device may be individually integrated into a single chip, or some or all of the components may be integrated into a single chip.

[0320] Furthermore, while we refer to it as a system LSI here, depending on the degree of integration, it may also be called an IC, LSI, super LSI, or ultra LSI. Also, the method of integrated circuit implementation is not limited to LSIs; it may be implemented using dedicated circuits or general-purpose processors. After LSI manufacturing, FPGAs (Field Programmable Gate Arrays) that can be programmed, or reconfigurable processors that allow for the reconfiguration of the connections and settings of circuit cells within the LSI, may also be used.

[0321] Furthermore, if advancements in semiconductor technology or other derived technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, it would be possible to use those technologies to integrate functional blocks. The application of biotechnology, for example, is a possibility.

[0322] (21) Some or all of the components constituting each of the above devices may consist of a removable IC card or a standalone module. The IC card or module is a computer system consisting of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned multi-functional LSI. The IC card or module achieves its function by the operation of the microprocessor in accordance with the computer program. The IC card or module may be tamper-resistant.

[0323] (22) The disclosure may also be the methods described above. Alternatively, it may be a computer program that implements these methods using a computer, or a digital signal consisting of a computer program.

[0324] Furthermore, this disclosure may also refer to a computer program or digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray® Disc), semiconductor memory, etc. Alternatively, it may refer to a digital signal recorded on such a recording medium.

[0325] Furthermore, this disclosure may also include the transmission of computer programs or digital signals via telecommunications lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.

[0326] Furthermore, this disclosure may also describe a computer system comprising a microprocessor and memory, wherein the memory stores the computer program, and the microprocessor operates in accordance with the computer program.

[0327] Alternatively, the program or digital signal may be implemented by another independent computer system by recording it on a recording medium and transferring it, or by transferring the program or digital signal via a network or the like.

[0328] (23) In the above embodiment, the security measures for cyber-physical systems were described for automobiles, but the scope of application is not limited to this. Therefore, the scope of application is not limited to user interfaces (UIs) for visualizing attacks on automobiles. It may be applied not only to automobiles, but also to mobility such as construction machinery, agricultural machinery, ships, railways, and airplanes, and may also be applied to communication networks used in industrial control systems such as factories and buildings, and to communication networks for controlling embedded devices.

[0329] (24) In the above embodiment, the security measures for a cyber-physical system were described for automobiles, but the judgment results and output results of each process of the security function may be displayed as a user interface (UI) for visualizing attacks in the cyber-physical system. The measures may be applied not only to automobiles, but also to mobility such as construction machinery, agricultural machinery, ships, railways, and airplanes, and may also be applied to communication networks used in industrial control systems such as factories and buildings, or to communication networks for controlling embedded devices.

[0330] (25) The above embodiments and the above modified examples may be combined. [Industrial applicability]

[0331] This disclosure describes how, in an in-vehicle network employing service-oriented communication, an intermediary can verify authentication information even if an attacker transmits a malicious frame. Furthermore, by providing an intermediary method tailored to the service policy and vehicle status, it becomes possible to achieve service-specific security and real-time performance, making it highly effective. [Explanation of symbols]

[0332] 100a, 100b Server ECU 100c, 100d Client ECU 101 Communications Department 102 App Department 103 App Authentication Information Storage Unit 104 Service policy holding section 200 Intermediary ECU 201, 301 Communication Control Unit Rooms 202 and 302, Service Management Department 203, 303 Proxy Transmission Section 204 Abnormality monitoring section 205 Service Information Storage Unit 206, 304 Vehicle state retention unit 300 Service Intermediary Device

Claims

1. A service intermediary device in a service provision system that provides services from a server unit to a client unit via service-oriented communication, wherein the device is connected to both the server unit and the client unit, The aforementioned service intermediary device, A communication control unit that receives frames used for providing the service from the server unit or the client unit, The system includes a service management unit that, based on access control information that defines pre-stored communication combinations, determines whether the combination of the service identifier included in the frame received by the communication control unit, the identifier indicating the source or destination of the frame, and the type of the frame is appropriate, and outputs the result of the determination. The aforementioned communication control unit further, Prior to providing the aforementioned service, the server unit receives a service provision frame containing first service information indicating the service to be provided. Prior to providing the aforementioned service, the client unit receives a service discovery frame, which includes a second service information indicating the target of the service discovery. The aforementioned service management department further, The communication control unit transmits the service provision frame, which includes the same first service information as the second service information included in the service discovery frame received by the communication control unit, to the client unit that was the source of the received service discovery frame. Service intermediary device.

2. The service provision frame indicates that the server unit has the authority to act as a server providing the service indicated by the first service information included in the service provision frame. Includes the primary authentication information shown, The service discovery frame includes second authentication information indicating that the client unit has the authority to receive the service indicated by the second service information included in the service discovery frame, The aforementioned service management department further, If the verification of the first authentication information included in the service provision frame is successful, the service provision frame is determined to be valid. If the verification of the second authentication information included in the service discovery frame is successful, the service discovery frame is determined to be valid. If the service provision frame and the service discovery frame are determined to be valid, the communication control unit transmits the service provision frame to the client unit. The service intermediary device according to claim 1.

3. The communication control unit, When the server unit providing the service receives a first frame used to provide the service, the server unit transmits the first frame to the client unit receiving the service. When the client unit receiving the service receives the second frame used to provide the service, it transmits the second frame to the server unit providing the service. The service intermediary device according to claim 1 or 2.

4. The service intermediary device includes a proxy transmission unit that performs proxy transmission processing, The aforementioned proxy transmission process is: When the communication control unit receives the first frame, it performs the following process: change the source information contained in the first frame to the identifier of the service intermediary device, and then transmit the first frame to the client unit, or When the communication control unit receives the second frame, the process includes changing the source information contained in the second frame to the identifier of the service intermediary device, and then transmitting the second frame to the server unit. The service intermediary device according to claim 3.

5. The server unit, the client unit, and the service intermediary device are mounted in a vehicle. The service intermediary device further includes a vehicle state holding unit that holds state information indicating the state of the vehicle, The proxy transmission unit controls whether or not to execute the proxy transmission process according to the state information held by the vehicle state holding unit. The service intermediary device according to claim 4.

6. The aforementioned server unit includes a first server unit and a second server unit. The communication control unit, When the service provision frame is received from the first server unit, the server enters a waiting state for a predetermined period of time. If the service provision frame is received from the second server unit in the standby state, one of the two received service provision frames is transmitted to the client unit. The service intermediary device according to claim 1 or 2.

7. The communication control unit, If the service provision frame is not received from the second server unit in the standby state, the service provision frame received from the first server unit is sent to the client unit, and a predetermined process is executed in case of an abnormality in the second server unit. The service intermediary device according to claim 6.

8. The communication control unit, If the service provision frame is not received from the second server unit in the standby state, the system controls whether or not to send the service provision frame received from the first server unit to the client unit, according to the type of service. The service intermediary device according to claim 6.

9. The server unit, the client unit, and the service intermediary device are mounted in a vehicle. The service intermediary device further includes a vehicle state holding unit that holds state information indicating the state of the vehicle, The communication control unit, If the service provision frame is not received from the second server unit in the standby state, the vehicle state holding unit controls whether or not to transmit the service provision frame received from the first server unit to the client unit, according to the state information it holds. The service intermediary device according to claim 6.

10. The aforementioned server unit includes a first server unit and a second server unit. The communication control unit, When the service discovery frame is received from the client unit, the received service discovery frame is transmitted to both the first server unit and the second server unit. A service intermediary device according to any one of claims 1, 2, 6 to 9.

11. The server unit includes multiple server units, The aforementioned service management department, The plurality of server units maintain communication status information indicating whether or not they are in a state where communication is possible, The communication status information being held is transmitted to the client unit. A service intermediary device according to any one of claims 1, 2, 6 to 10.

12. When the service management unit detects that one of the multiple server units is in a communication-unavailable state, it refers to the communication status information and transmits the service provision frame received from a server unit that is in a communication-available state to the client unit. The service intermediary device according to claim 11.

13. The output of the result of the above determination is, Displaying information indicating the result of the aforementioned determination on the display screen, or This includes transmitting information indicating the result of the determination to an external device via a network. A service intermediary device according to any one of claims 1 to 12.

14. A service mediation method performed by a service mediation device, in a service provision system that provides services from a server unit to a client unit by service-oriented communication, wherein the service mediation device is connected to the server unit and the client unit respectively, and receives frames used for providing the service from the server unit or the client unit, Based on access control information that defines pre-stored communication combinations, the service intermediary device determines whether the combination of the service identifier included in the frame received by the service intermediary device, the identifier indicating the source or destination of the frame, and the type of the frame is appropriate, and outputs the result of the determination. The aforementioned service intermediary device further, Prior to providing the aforementioned service, the server unit receives a service provision frame containing first service information indicating the service to be provided. Prior to providing the aforementioned service, the client unit receives a service discovery frame, which includes a second service information indicating the target of the service discovery. The service provision frame, which includes the same first service information as the second service information included in the received service discovery frame, is transmitted to the client unit that was the source of the received service discovery frame. Service intermediation methods.

15. A program that causes a computer to execute the service mediation method described in claim 14.

Images