In-vehicle information processing device, information processing method, and server program

Abstract

To provide an on-vehicle information processing device capable of expecting that a client can avoid not receiving a service due to a mismatch between versions as much as possible, and provide an information processing method and a server program.SOLUTION: In an on-vehicle information processing device according to this embodiment, a server processing part receives a retrieval message for retrieving a service to be requested from a client processing part for requesting service provision, the retrieval message includes the identification information and version information of the service to be requested, the server processing part determines whether the version information included in the received retrieval message coincides with version information of a service provided by the server processing part itself, verifies whether to provide a client processing part with a service having different version information if it is determined that both pieces of version information are not coincident, and provides the client processing part with the service if the service having different version information can be provided.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle information processing device, an information processing method, and a server program that perform a process of providing services to a client.

Background Art

[0002] In recent years, the development of the automatic driving function of vehicles has been advanced, and the control of a more highly functional in-vehicle system has been demanded. As an architecture of service-oriented middleware for realizing this, SOME / IP (Scalable service-Oriented MiddlewarE over IP) has attracted attention.

[0003] In Patent Document 1, before starting the provision of a new service, its identification information is transmitted to an external device, a test of the new service is performed in response to a test instruction from the external device, and the test result is transmitted to the external device. When determination information indicating permission to provide the new service is received from the external device, an ECU (Electronic Control Unit) that starts providing the new service has been proposed. After receiving the identification information from the ECU, the external device transmits a test instruction to the ECU and receives the result, determines whether to permit the provision of the new service based on the received result, and transmits the determination information to the ECU.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In SOME / IP, the services provided by the server are configured with information such as a service ID and version. Clients wishing to receive a service search for whether the service is available by specifying the service ID and version. For example, if the server program providing the service is updated, but the client program has not been updated, the version of the service provided by the server and the version of the service desired by the client may not match, potentially preventing the client from receiving the desired service.

[0006] This disclosure is made in view of the circumstances described herein, and its purpose is to provide an in-vehicle information processing device, an information processing method, and a server program that are expected to minimize the risk of clients being unable to receive services due to version mismatches. [Means for solving the problem]

[0007] The in-vehicle information processing device according to this embodiment is an in-vehicle information processing device comprising a server processing unit that performs processing to provide services in response to requests, wherein the server processing unit receives a search message from a client processing unit that requests the provision of a service to search for the requested service, the search message includes identification information and version information of the requested service, the server processing unit determines whether the version information included in the received search message matches the version information of the service it provides, and if it determines that the two versions do not match, it temporarily changes the version information of the service it provides to the version information included in the search message, sends and receives messages with the client processing unit based on the temporarily changed version information, verifies whether it is possible to provide the client processing unit with a service with a different version information based on the result of the message sending and receiving, and provides the service to the client processing unit if it is possible to provide the service with a different version information.

[0008] The present invention can be realized not only as a device equipped with such characteristic processing, but also as a method in which such characteristic processing is performed in steps, or as a computer program for causing a computer to execute such steps. It can also be realized as a semiconductor integrated circuit that realizes some or all of these devices, or as other devices or systems that include these devices. [Effects of the Invention]

[0009] Based on the above, it is expected that the situation in which clients are unable to receive services due to version mismatches can be avoided as much as possible. [Brief explanation of the drawing]

[0010] [Figure 1] This is a schematic diagram illustrating the configuration of the in-vehicle information processing system according to this embodiment. [Figure 2] This is a schematic diagram illustrating the communication of the in-vehicle information processing system according to this embodiment. [Figure 3] This is a schematic diagram illustrating the communication of the in-vehicle information processing system according to this embodiment. [Figure 4] This is a block diagram showing the configuration of the client-side ECU according to this embodiment. [Figure 5] This is a block diagram showing the configuration of the server-side ECU according to this embodiment. [Figure 6] This is a schematic diagram showing one example of the configuration of search messages and provision messages transmitted and received by the in-vehicle information processing system according to this embodiment. [Figure 7] This is a schematic diagram showing one example of the configuration of request messages and response messages transmitted and received by the in-vehicle information processing system according to this embodiment. [Figure 8] This is a schematic diagram illustrating an example of processing performed by the in-vehicle information processing system according to this embodiment. [Figure 9]This is a schematic diagram illustrating an example of processing performed by the in-vehicle information processing system according to this embodiment. [Figure 10] This flowchart shows the procedure for processing performed by the client's ECU according to this embodiment. [Figure 11] This flowchart shows the procedure for processing performed by the ECU of the server according to this embodiment. [Figure 12] This flowchart shows the procedure for the verification process performed by the server's ECU according to this embodiment. [Figure 13] This flowchart shows the steps for other processing performed by the ECU of the server according to this embodiment. [Figure 14] This is a schematic diagram illustrating an example of processing performed in the in-vehicle information processing system according to Modification Example 1. [Figure 15] This is a schematic diagram illustrating the configuration of the in-vehicle information processing system according to Modification Example 2. [Modes for carrying out the invention]

[0011] [Description of Embodiments in this Disclosure] The embodiments of this disclosure will be listed and described first. At least some of the embodiments described below may be combined in any way.

[0012] (1) The in-vehicle information processing device according to this embodiment is an in-vehicle information processing device comprising a server processing unit that performs processing to provide a service in response to a request, wherein the server processing unit receives a search message from a client processing unit that requests the provision of a service to search for the requested service, the search message includes identification information and version information of the requested service, the server processing unit determines whether the version information included in the received search message matches the version information of the service it provides, and if it determines that the two versions do not match, it verifies whether it is possible to provide a service with a different version to the client processing unit, and if it is possible to provide a service with a different version, it provides the service to the client processing unit.

[0013] In this aspect, the server processing unit of the in-vehicle information processing device receives a search message for searching for a service from a client processing unit that requests the provision of a service. This search message includes the identification information and version information of the service required by the client processing unit, and the server processing unit determines whether the version information included in the received search message matches the version information of the service provided by itself. When both version information matches, the server processing unit performs a process of providing this service to the client processing unit. When both version information does not match, the server processing unit verifies whether the client processing unit can receive the provision of a service with different version information. As a result of the verification, if the client processing unit can receive the provision of a service with different version information, the server processing unit performs information processing for providing the service requested by the client processing unit. Thereby, it can be expected that the server processing unit of the in-vehicle information processing device can avoid as much as possible the situation where the client processing unit cannot receive the service due to the mismatch of the version information of the service.

[0014] (2) When the server processing unit can provide services with different version information, it is preferable to change the version information of the services to be provided to the client processing unit later to the version information included in the search message.

[0015] In this aspect, as a result of the verification, if the client processing unit can receive the provision of a service with different version information, the server processing unit changes the version information of the service that it will provide to this client processing unit later to the version information included in the search message received from the client processing unit. Thereby, in the future, the mismatch of the version information will not occur, and it can be expected that the processing of the client processing unit will be performed smoothly.

[0016] (3) The server processing unit preferably temporarily changes the version information of the service it provides to the version information included in the search message, sends and receives messages with the client processing unit based on the temporarily changed version information, and verifies whether or not it is possible to provide a service with different version information based on the results of the message sending and receiving.

[0017] In this embodiment, when verifying whether the client processing unit can receive services with different version information, the server processing unit first temporarily changes the version information of the service it provides to the version information included in the search message received from the client processing unit. Then, the server processing unit sends and receives messages regarding the provision of services with the client processing unit based on the changed version information. Based on the results of this message exchange, the server processing unit verifies whether the client processing unit can receive services with different version information. This allows the in-vehicle information processing device to verify whether any problems occur when it changes the version information of the service it provides to the version information of the service requested by the client processing unit.

[0018] (4) Preferably, the server processing unit gives a command to the client processing unit to send a predetermined message, receives the message sent by the client processing unit in response to the command, and performs verification based on the received message.

[0019] In this embodiment, the server processing unit issues a command to the client processing unit to send a predetermined message, and performs verification based on the message sent by the client processing unit in response to this command. This allows the server processing unit to verify with greater accuracy whether the client processing unit can receive a service with different version information.

[0020] (5) The server processing unit preferably receives a search message sent by the client processing unit to search for the availability of the service it wishes to provide, and sends a provision message in response to the search message, which includes identification information and version information of the service it provides.

[0021] In this embodiment, the server processing unit of the in-vehicle information processing device receives a search message from the client processing unit to search for the availability of a desired service, and in response to this search message, sends a provision message containing identification information and version information of the service it provides. This allows the client processing unit to send a search message and receive a provision message from the server processing unit when it needs the provision message.

[0022] (6) The server processing unit preferably repeatedly sends a service message containing identification information and version information of the service it provides at predetermined intervals.

[0023] In this embodiment, the server processing unit of the in-vehicle information processing device repeatedly transmits a provision message containing identification information and version information of the services it provides at predetermined intervals. As a result, the client processing unit can receive the periodically transmitted provision messages and determine whether the services it needs are being provided, and can also determine which server processing unit is providing the service.

[0024] (7) The server processing unit preferably sends and receives messages with other devices equipped with the client processing unit.

[0025] In this embodiment, the server processing unit of the in-vehicle information processing device sends and receives messages with other devices equipped with client processing units. This enables the in-vehicle information processing device to perform processing to provide services required by the other devices.

[0026] (8) It is preferable to have the client processing unit described above.

[0027] In this embodiment, the in-vehicle information processing device, which includes a server processing unit, also includes a client processing unit. This allows the in-vehicle information processing device to perform processing to provide services to the client processing unit inside the device in the same manner as when providing services to an external device.

[0028] (9) The information processing method according to this embodiment is an information processing method in which a server processing unit of an in-vehicle information processing device performs processing to provide a service in response to a request from a client processing unit, wherein the server processing unit receives a search message from a client processing unit that requests the provision of a service to search for the requested service, the search message includes identification information and version information of the requested service, the server processing unit determines whether the version information included in the received search message matches the version information of the service it provides, the server processing unit determines that the two versions of the information do not match, and verifies whether it is possible to provide a service with a different version to the client processing unit, and the server processing unit provides the service to the client processing unit if it is possible to provide a service with a different version.

[0029] In this embodiment, as in embodiment (1), it is expected that the inability to receive services due to mismatches in service version information can be avoided as much as possible.

[0030] (10) The server program according to this embodiment receives a search message from a client program that requests the provision of a service to a computer installed in the vehicle, and the search message includes identification information and version information of the requested service, and the server program determines whether the version information included in the received search message matches the version information of the service it provides, and if it determines that the two versions do not match, it verifies whether it is possible to provide the client program with a service with a different version, and if it is possible to provide the service with a different version, it executes a process to provide the service to the client program.

[0031] In this embodiment, as in embodiment (1), it is expected that the inability to receive services due to mismatches in service version information can be avoided as much as possible.

[0032] [Details of the embodiments of this disclosure] Specific examples of an in-vehicle information processing system according to the embodiments of this disclosure will be described below with reference to the drawings. This disclosure is not limited to these examples, and is intended to include all modifications within the meaning and scope of the claims as indicated by the claims.

[0033] <System Configuration> Figure 1 is a schematic diagram illustrating the configuration of the in-vehicle information processing system according to this embodiment. The in-vehicle information processing system according to this embodiment is a system in which a plurality of ECUs 2 and 3 mounted on a vehicle 1 communicate via a relay 4, and these plurality of ECUs 2 and 3 cooperate to perform various information processing related to the driving control of the vehicle 1. The illustrated in-vehicle information processing system has a star-type network configuration in which one ECU 2 and three ECUs 3 are each connected to one relay 4 via individual communication lines. However, the number of devices and network configuration included in the in-vehicle information processing system are examples only and are not limited to this. The total number of ECUs 2 and 3 included in the in-vehicle information processing system may be three or less, or it may be five or more. Furthermore, the plurality of ECUs 2 and 3 may be connected in a bus-type or ring-type network configuration.

[0034] ECU2 and 3 are information processing devices mounted on vehicle 1. For example, ECU2 and 3 may include various ECUs such as an ECU that controls the automatic driving of vehicle 1, an ECU that controls the operation of the engine, an ECU that controls the locking / unlocking of the doors, an ECU that controls the turning on / off of the lights, an ECU that controls the operation of the airbags, and an ECU that controls the operation of the ABS (Antilock Brake System). In this embodiment, the in-vehicle information processing devices are ECU2 and 3, but the in-vehicle information processing devices are not limited to these, and the in-vehicle information processing devices may be various devices other than ECU2 and 3.

[0035] Repeater 4 is a device that has multiple ports for connecting communication lines and relays the transmission and reception of messages between communication lines connected to these ports. For example, repeater 4 is a device such as a switching hub or gateway. Repeater 4 relays the transmission and reception of messages by receiving a message on one communication line and transmitting it from another communication line. Note that if the in-vehicle information processing system employs a bus-type network configuration in which, for example, multiple ECUs 2 and 3 are connected on a common communication line, then repeater 4 may not be required.

[0036] In the in-vehicle information processing system according to this embodiment, message transmission and reception between ECU2 and ECU3 are performed according to the SOME / IP communication standard. SOME / IP is a standard classified as Layer 5 or higher of the OSI reference model, and communication takes place between application programs in the form of service requests and responses. In this embodiment, ECU2 is the server-side device that provides the service, and ECU3 is the client-side device that receives the service. However, this client-server relationship is just an example, and each ECU2 and ECU3 can be either a client or a server. Any standard may be adopted for communication at Layer 4 or lower of the OSI reference model, but for example, standards such as Ethernet®, TCP (Transmission Control Protocol), or UDP (User Datagram Protocol) may be adopted.

[0037] Figures 2 and 3 are schematic diagrams illustrating the communication of the in-vehicle information processing system according to this embodiment. In these figures, the three ECUs 3 are distinguished by different codes, ECU3a, 3b, and 3c. For example, as shown in Figure 2, ECU3a sends a search message (search frame) to search for the services it needs at a predetermined timing, such as after startup or restart. In this embodiment, ECU3a sends the search message using a transmission method that simultaneously sends one message to multiple devices, so-called multicast. As a result, the search message sent by ECU3a is received by ECU2, 3b, and 3c (in Figure 2, the sending and receiving of the search message is indicated by dashed arrows).

[0038] The search message sent by ECU3a includes a service ID to identify the service required by ECU3a and a service version to identify the version of the software (server program) that provides this service. Upon receiving the search message, ECU2, 3b, and 3c determine whether they can provide the service that matches the service ID and service version included in the received search message. In this example, ECU2 can provide the service, and ECU2 sends a provision message (provision frame) to ECU3a, which sent the search message, notifying it that the service can be provided. At this time, ECU2 sends the provision message using a transmission method that designates ECU3a as one of its destinations, so-called unicast (in Figure 2, the sending and receiving of the provision message is indicated by a dashed-dotted arrow).

[0039] Upon receiving a service provision message from ECU2, ECU3a can determine, based on the message, that a device capable of providing the service exists and that this device is ECU2. The service provision message includes information such as the service ID and service version, as well as the IP address and port number of the server (ECU2) providing the service. Subsequently, ECU3a sends a request for information regarding this service to ECU2, and in response to this request, ECU2 sends a response to ECU3a containing information about the service. As a result, the service is provided from the server ECU2 to the client ECU3a, and ECU3a can perform various information processing using the service provided by ECU2.

[0040] Furthermore, in this embodiment, the transmission of provision messages is not limited to responses to search messages; the ECU2 providing the service also spontaneously transmits provision messages at predetermined intervals. The ECU2 capable of providing a service repeatedly transmits a provision message containing information about the service it provides, for example, at predetermined intervals of a few milliseconds to a few seconds. As shown in Figure 3, when the ECU2 transmits periodic provision messages, it transmits one provision message simultaneously to multiple devices using a transmission method known as multicast. As a result, the provision messages transmitted by the ECU2 are received by ECUs 3a, 3b, and 3c (in Figure 3, the transmission and reception of provision messages are indicated by dashed-dotted arrows).

[0041] The offer message sent in response to a search message and the periodically sent offer message may be the same. Upon receiving this, ECU3a can know that ECU2 is providing the service it needs, as described above, and can subsequently send service requests to ECU2. ECU3b and 3c, which do not require the service, can simply discard (ignore) the periodically sent offer message upon receiving it.

[0042] In the in-vehicle information processing system according to this embodiment, the client-side ECU 3a, which requires a service, needs to know in advance which ECU 2 is providing the service based on the provided message. After it is determined that ECU 2 is providing the service, ECU 3a can send and receive messages with ECU 2 and receive the service from ECU 2 to perform information processing. ECU 3a sends a request message to ECU 2 requesting the provision of the service, and ECU 2 sends a response message to ECU 3a in response to this request message.

[0043] In this embodiment, the service provided by the server ECU2 can be the process of sending a message containing various information, such as the vehicle speed of vehicle 1 or the results of object detection around vehicle 1, to the requesting ECU3a. Furthermore, for example, if ECU2 is a device that controls in-vehicle equipment such as the lights or door locks of vehicle 1, ECU2 can provide a service that controls these in-vehicle equipment in response to a request from ECU3a. The service provided by the server ECU2 is not limited to those described above and may be various other processes.

[0044] Here, ECU2,3a~3c, which are included in the in-vehicle information processing system, may undergo version upgrades through software updates. Version upgrades may be performed simultaneously on all devices in the in-vehicle information processing system, or they may be performed individually on each device. For example, a situation may occur where the software of ECU3a, which receives this service, is upgraded, but the software of ECU2, which provides the service, is not upgraded. In such a situation, even if ECU3a sends a search message specifying the service with the new version, ECU2, which receives this message, will not send a service request message to ECU3a because the version of the service it provides is different, and ECU3a will not be able to receive the service. Also, ECU2 periodically sends service request messages specifying the service with the old version, but ECU3a, which receives this message, will not send a service request message to ECU2 because the version of the service it desires is different. In other words, ECU2 will not be able to provide the service to ECU3a.

[0045] Therefore, in the in-vehicle information processing system according to this embodiment, if there is a client-side ECU3a that desires to receive a service with the same service ID as the service it provides but a different service version, the server-side ECU2 verifies whether the client-side ECU3a can receive this service. If the verification determines that the client-side ECU3a can receive a service with a different service version, the server-side ECU2 can perform processing to provide the service to this client ECU3a.

[0046] <Device configuration> Figure 4 is a block diagram showing the configuration of the client-side ECU3 according to this embodiment. The ECU3 according to this embodiment is configured to include a processing unit (processor) 31, a storage unit (storage) 32, and a communication unit (transceiver) 33, etc. The processing unit 31 is configured using a processing unit such as a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit). By reading and executing the client program 32a stored in the storage unit 32, the processing unit 31 can perform various processes such as searching for a server that provides the necessary service and processing information according to the service provided by the server.

[0047] The storage unit 32 is configured using non-volatile memory elements such as flash memory or EEPROM (Electrically Erasable Programmable Read Only Memory). The storage unit 32 stores various programs executed by the processing unit 31, and various data necessary for the processing of the processing unit 31. In this embodiment, the storage unit 32 stores the client program 32a executed by the processing unit 31.

[0048] The client program 32a may be written to the storage unit 32, for example, during the manufacturing stage of the ECU3. Alternatively, the client program 32a may be distributed by a remote server device, and the ECU3 may acquire the client program 32a through communication with the server device and write it to the storage unit 32. Alternatively, the ECU3 may read the client program 32a recorded on a recording medium 99, such as a memory card or optical disc, and store it in the storage unit 32. Alternatively, a writing device may read the client program 32a recorded on the recording medium 99 and write it to the storage unit 32 of the ECU3. The client program 32a may be provided by distribution via a network, or by being recorded on the recording medium 99.

[0049] The communication unit 33 is connected to a communication line installed in the vehicle 1, and sends and receives messages with other ECUs 2 and 3 via this communication line. In this embodiment, the communication unit 33 sends and receives messages according to the Ethernet communication standard, for example. The communication unit 33 may be configured using, for example, an Ethernet PHY (physical layer) IC (Integrated Circuit). However, the communication standard used by the communication unit 33 is not limited to Ethernet; various communication standards such as CAN (Controller Area Network) or FlexRay may be adopted. The communication unit 33 transmits messages by outputting data provided by the processing unit 31 as an electrical signal to the communication line. The communication unit 33 also samples and acquires the potential of the communication line, converts the electrical signal on the communication line into digital data, and provides the converted data to the processing unit 31 as a received message.

[0050] In this embodiment, the ECU3 is implemented as a software-based functional unit in the processing unit 31 by the processing unit 31 reading and executing the client program 32a stored in the memory unit 32. The client processing unit 310 performs various processes as a client receiving services in accordance with the SOME / IP standard. In this embodiment, the client processing unit 310 includes a service search unit 310a and an application processing unit 310b, etc.

[0051] The service search unit 310a performs a process to search for servers that provide the services necessary for its own processing. The service search unit 310a sends a search message via multicast from the communication unit 33, specifying the service ID and service version of the services necessary for its own processing. The service search unit 310a receives a provision message sent from a server in response to the search message it sent, and by obtaining information such as the IP address and port number contained in the received provision message, it determines whether there is a server that provides the service and obtains information necessary for communication with the server. The service search unit 310a also receives provision messages that are periodically sent by the server, and by obtaining information such as the IP address and port number contained in the received provision message, it determines whether there is a server that provides the service and obtains information necessary for communication with the server.

[0052] The application processing unit 310b performs information processing related to applications specific to each ECU 3 using the provided services. The application processing unit 310b sends a request message specifying the service ID and service version to the server found by the service search unit 310a, and receives a response message sent in response. The application processing unit 310b acquires the information contained in the received response message and performs various information processing based on the acquired information. For example, the application processing unit 310b can send a request message to the server requesting the transmission of vehicle speed information for vehicle 1, acquire the vehicle speed information contained in the response message received from the server in response, and perform various information processing using the vehicle speed. The information processing performed by the application processing unit 310b using the services provided by the server can be any type of processing.

[0053] Figure 5 is a block diagram showing the configuration of the server-side ECU2 according to this embodiment. The ECU2 according to this embodiment is configured to include a processing unit (processor) 21, a storage unit (storage) 22, and a communication unit (transceiver) 23, etc. The processing unit 21 is configured to use a processing unit such as a CPU or MPU. The processing unit 21 can perform various processes such as notifying the service to be provided in response to a service search and providing a service to the client by reading and executing the server program 22a stored in the storage unit 22.

[0054] The storage unit 22 is configured using, for example, a non-volatile memory element such as flash memory or EEPROM. The storage unit 22 stores various programs executed by the processing unit 21, and various data necessary for the processing of the processing unit 21. In this embodiment, the storage unit 22 stores the server program 22a executed by the processing unit 21.

[0055] The server program 22a may be written to the storage unit 22, for example, during the manufacturing stage of the ECU2. Alternatively, the server program 22a may be distributed by a remote server device, and the ECU2 may obtain the server program 22a through communication with the server device and write it to the storage unit 22. Alternatively, the ECU2 may read the server program 22a recorded on a recording medium 98, such as a memory card or optical disc, and store it in the storage unit 22. Alternatively, a writing device may read the server program 22a recorded on the recording medium 98 and write it to the storage unit 22 of the ECU2. The server program 22a may be provided by distribution via a network, or it may be provided in the form of being recorded on the recording medium 98.

[0056] The communication unit 23 is connected to a communication line installed in the vehicle 1, and sends and receives messages with other ECUs 3 via this communication line. In this embodiment, the communication unit 23 sends and receives messages according to the Ethernet communication standard, for example. The communication unit 23 may be configured using, for example, an Ethernet PHY IC. However, the communication standard used by the communication unit 23 is not limited to Ethernet; various communication standards such as CAN or FlexRay may be adopted. The communication unit 23 transmits messages by outputting data provided by the processing unit 21 as an electrical signal to the communication line. The communication unit 23 also samples and acquires the potential of the communication line, converts the electrical signal on the communication line into digital data, and provides the converted data to the processing unit 21 as a received message.

[0057] In this embodiment, the ECU2 is implemented as a software-based functional unit in the processing unit 21 by the processing unit 21 reading and executing the server program 22a stored in the memory unit 22. The server processing unit 210 performs various processes as a server providing services in accordance with the SOME / IP standard. In this embodiment, the server processing unit 210 includes a service information provision unit 210a, a service verification unit 210b, and an application processing unit 210c, etc.

[0058] The service information provision unit 210a performs the process of sending a provision message containing information about the services it provides. When the service information provision unit 210a receives a search message from a client, it determines whether the service ID and service version contained in the search message match the service ID and service version of the services it provides. If the service ID and service version match, the service information provision unit 210a sends a provision message via unicast to the client that sent the search message. The service information provision unit 210a also sends provision messages containing information about the services it provides via multicast at predetermined intervals.

[0059] The service verification unit 210b performs a process to verify whether the ECU3 can receive a service with a different service version if the ECU3 requests a service whose service ID matches the service it provides but whose service version is different. The service verification unit 210b obtains the service ID and service version contained in the search message received from the client's ECU3, and starts the verification process if the service ID in the search message matches the service ID of the service it provides, and the service version in the search message does not match the service version of the service it provides. The service verification unit 210b temporarily changes the service version of the service it provides to the ECU3 of the client being verified to the service version in the search message. The service verification unit 210b sends a provision message with the changed service version set to the ECU3 being verified.

[0060] Upon receiving this service provision message, ECU3 determines that ECU2 is providing the service it desires and sends a request message to ECU2 to use this service. The request message includes information about the service ID and service version of the service being requested. The service verification unit 210b of ECU2 receives the request message from ECU3 and determines whether the received request message is correct or incorrect. The service verification unit 210b receives a predetermined number (e.g., 10) of request messages from ECU3, and if the number of request messages determined to be correct exceeds a threshold (e.g., 5), it determines that ECU3 can receive a service with a different service version. If the number of request messages determined to be correct does not exceed the threshold, the service verification unit 210b determines that ECU3 cannot receive a service with a different service version.

[0061] Furthermore, the service verification unit 210b can determine the validity of each request message received from the ECU 3, for example, by the following method. • Whether the various ID information and other data included in the request message are valid values. Regarding values ​​such as session IDs, which change (e.g., by incrementing or decrementing) with each request message sent, is the change in those values ​​legitimate? • Whether the values ​​of arguments or return values ​​related to the service request are within a valid range.

[0062] However, the method for determining the validity of a request message is not limited to the above. For example, if the message transmission and reception of ECU2 and ECU3 conforms to the SOME / IP standard, the service verification unit 210b may use the above-mentioned validity determination as a check of whether or not it is judged as an error in the SOME / IP standard.

[0063] If the service verification unit 210b determines that ECU3 cannot receive a service with a different service version, it temporarily reverts the service version of the service to its original state and does not respond to any subsequent search messages and request messages received from ECU3 (limited to messages containing the same service ID as the verified service ID). As a result, client ECU3 will no longer be able to receive services from ECU2.

[0064] If the service verification unit 210b determines that ECU3 can receive a service with a different service version, it maintains the temporarily changed service version without reverting it, i.e., permanently changes the service version. The service verification unit 210b then responds to search messages and request messages received from ECU3 with the changed service version. In other words, ECU2 includes the changed service version in the service versions of the service provision messages and response messages it sends to ECU3.

[0065] The application processing unit 210c performs information processing to provide services specific to ECU2. The application processing unit 210c receives a request message from the client's ECU3 and obtains the service ID and service version contained in the received request message. The application processing unit 210c performs information processing to provide the service corresponding to the obtained service ID and service version. The application processing unit 210c generates a response message containing the information obtained as a result of the information processing and sends the response message to the client that sent the request message.

[0066] <Client and Server Processing> Figure 6 is a schematic diagram showing an example of the configuration of search messages and provision messages transmitted and received by the in-vehicle information processing system according to this embodiment. The search message transmitted by the client's ECU3 and the provision message transmitted by the server's ECU2 according to this embodiment are composed of information such as header information, message type, service ID, service version, and option information.

[0067] Message header information includes, for example, Ethernet headers, IP headers, TCP / UDP headers, and SOME / IP headers, and is used to store information defined by communication standards. Header information may store information such as MAC address, Ethernet type, IP address, or port number. The format of the header information is not limited to any particular type, and the information stored within the header information is also limited to any type.

[0068] The message type stores information indicating whether the message is a search message or a provided message. For example, this message is a search message if the message type is set to "0", and a provided message if it is set to "1".

[0069] The service ID is unique identification information assigned to a service provided by the server. The service version is information that identifies the version of the service provided, for example, the version of the software that the server runs to provide the service identified by the service ID. In this embodiment, a higher service version number indicates a newer version. The service ID and service version included in the search message are the service ID and service version of the service that the client wishes to receive from the server. The service ID and service version included in the offer message are the service ID and service version of the service that the server can provide.

[0070] In this embodiment, optional information is information attached to the service message and includes information such as the IP address and port number of the server providing the service. However, similarly, information such as the client's IP address and port number may also be attached to the search message as optional information.

[0071] Figure 7 is a schematic diagram showing an example of the configuration of request messages and response messages transmitted and received in the in-vehicle information processing system according to this embodiment. A request message is a message sent by a client to request the server to provide a service. A response message is a message sent by the server in response to a request message from a client. The request message sent by the client's ECU3 and the response message sent by the server's ECU2 according to this embodiment include header information, which includes header information for the SOME / IP standard and header information for other standards, and a SOME / IP payload. The SOME / IP header information may include information such as service ID, method ID, service version, session ID, and message type. The SOME / IP payload may include information such as arguments related to the service request or return values ​​related to the service request.

[0072] The service ID and service version included in the SOME / IP header information are as described above. The method ID specifies which of the multiple methods provided for the service specified by the service ID will be used. For example, if a numerical value is set as the service ID to specify the vehicle information provision service, the method ID may be set as a numerical value specifying the method that provides vehicle speed, the method that provides acceleration, or the method that provides steering angle, etc.

[0073] The session ID is a numerical value that is incremented (its value increases by 1) with each service request and provision. For example, if a client sends a service request with session ID=1 and receives a service response with session ID=1, the client will then send the next service request with session ID=2. If the client does not receive the desired service response, it can resend the service request with the same session ID.

[0074] The message type is set to a numerical value that indicates, for example, whether the message is a request message from the client to the server or a response message from the server to the client.

[0075] The arguments of a service request included in the SOME / IP payload are information contained in the request message from the client to the server. These service request arguments are numerical or other information used in processing the service performed by the client, and are used by the client to set conditions for the service processing. For services that do not require arguments, the request message does not need to include argument information.

[0076] The return value of a service request is the information contained in the response message from the server to the client. For example, if the request message requests the transmission of vehicle speed information, the vehicle speed information will be set as the return value in the response message. Alternatively, if the request message requests a service such as the control of in-vehicle equipment rather than the transmission of information, the response message will contain a value indicating whether the requested control or service was performed successfully.

[0077] Figures 8 and 9 are schematic diagrams illustrating an example of processing performed in the in-vehicle information processing system according to this embodiment. These figures show an example where the service version of the service provided by the server's ECU2 is "1.1", and the service version of the service requested by the client's ECU3 is upgraded from "1.1" to "1.2". Before the upgrade, the client's ECU3 sends a request message to the server's ECU2 with the service version set to "1.1". Upon receiving this request message, the server's ECU2 performs information processing to provide the service with service version "1.1", and sends a response message containing the results of the information processing to the requesting ECU3. The service version of the response message sent by ECU2 at this time is "1.1".

[0078] Subsequently, the client ECU3's software (client program 32a) for processing information using the service is updated, changing the service version from "1.1" to "1.2". However, the server ECU2's software (server program 22a) has not been updated, and ECU2 provides the service with version "1.1". In this situation, even if ECU3 sends search messages and request messages set to service version "1.2" to ECU2, ECU2 may not be able to send the provision messages and response messages to ECU3 because the service versions are different.

[0079] After the version upgrade is complete, the client's ECU3 sends a search message with the service version set to "1.2". The server's ECU2 in this embodiment receives this search message and recognizes that the service ID of the service it provides matches, but that a different service version is being requested by ECU3.

[0080] Therefore, ECU2 temporarily changes the version of the service it provides to ECU3 from "1.1" to "1.2". ECU2 sends a service message with the service version set to "1.2" to ECU3, which sent the search message. Subsequently, ECU2 starts a verification process to check whether it is possible to use the service it provides with service version "1.1" for the information processing of ECU3, which is requesting the service with service version "1.2".

[0081] ECU2 receives a request message with service version "1.2" sent from ECU3, determines whether the received request message is valid, and sends a response message to the requesting ECU3. The service version of the response message sent by ECU2 at this time is set to "1.2". ECU2 determines whether the request message received from ECU3 is valid based on, for example, whether the various ID information included in the request message is of valid value, whether the change in the session ID of the request message is valid, and whether the value of the payload of the request message is within a valid range.

[0082] ECU2 continues the verification process until it receives a predetermined number of request messages from ECU3. Once it has received the predetermined number of request messages, ECU2 makes a final decision on whether ECU3 can receive a service with a different service version, based on the pass / fail judgment result of each request message. For example, if the number of messages judged to be valid out of the predetermined number of received request messages exceeds a threshold, ECU2 determines that ECU3 can receive a service with a different service version. If the number of messages judged to be valid does not exceed the threshold, ECU2 determines that ECU3 cannot receive a service with a different service version.

[0083] During the verification process, if ECU3 determines that a service with service version "1.1" is available (see Figure 8), ECU2 permanently changes the service version it provides to ECU3 to "1.2". Subsequently, ECU2 receives a request message from ECU3 with service version "1.2" set, performs information processing to provide the service with service version "1.1", and sends a response message containing the processing result with service version "1.2" set to "1.2" to ECU3.

[0084] During the verification process, if ECU3 determines that a service with service version "1.1" is unavailable (see Figure 9), ECU2 reverts the service version, which was temporarily changed for the verification process, from "1.2" back to "1.1". Subsequently, if ECU2 receives a request message or search message from ECU3 with service version "1.2", it will not send a response message or a provision message in response. In other words, ECU2 will not respond to any subsequent request messages or search messages with different service versions received from ECU3, which ECU3 determined to be unable to provide the service during the verification process, and will not repeat the verification process.

[0085] Figure 10 is a flowchart showing the processing procedure performed by the client ECU3 according to this embodiment. The ECU3 according to this embodiment is started, for example, when the ignition switch of the vehicle 1 is switched from the off state to the on state (step S1). After startup, the service search unit 310a of the processing unit 31 of the ECU3 sends a search message by multicast to search for a server that provides the service it needs (step S2). Subsequently, the service search unit 310a determines whether it has received a provision message sent by the server as a response to the search message it sent, or a provision message that the server periodically sends (step S3). If it has not received a provision message (S3: NO), the service search unit 310a waits until it receives a provision message.

[0086] If a provision message is received (S3:YES), the application processing unit 310b starts information processing using the service provided by the ECU2 that sent the provision message and sends a request message to the server's ECU2 (step S4). The application processing unit 310b determines whether or not it has received a response message from the server's ECU2 for the request message sent in step S4 (step S5). If a response message has not been received (S5:NO), the application processing unit 310b waits until a response message is received. If a response message is received (S5:YES), the application processing unit 310b performs information processing according to the information contained in the received response message (step S6) and returns processing to step S4.

[0087] Figure 11 is a flowchart showing the processing procedure performed by the server's ECU2 according to this embodiment. The service information provision unit 210a of the processing unit 21 of the server's ECU2 according to this embodiment determines whether or not it has received a search message sent by the client's ECU3 (step S11). If a search message is received (S11: YES), the service information provision unit 210a determines whether or not the service ID included in the search message matches the service ID of the service it provides (step S12). If the service IDs do not match (S12: NO), the service information provision unit 210a terminates processing without sending a provision message.

[0088] If the service ID matches (S12: YES), the service information provision unit 210a determines whether the service version included in the received search message matches the service version of the service it provides (step S13). If the service versions match (S13: YES), the service information provision unit 210a sends a provision message to the ECU3 that sent the search message (step S14) and terminates the process.

[0089] If the service versions do not match (S13: NO), the service information provision unit 210a temporarily changes the service version of the service it provides to the service version included in the received search message (step S15). Then, the service information provision unit 210a sends the provision message with the temporarily changed service version set to the ECU3 that sent the search message (step S16).

[0090] Subsequently, the service verification unit 210b of the processing unit 21 performs verification processing based on the request message and response message sent and received with the ECU3 (step S17). Based on the results of the verification processing in step S17, the service verification unit 210b determines whether it is possible to provide the ECU3 with a service version different from the service version included in the search message, i.e., a service version of the service that the ECU2 can provide (step S18). If it is determined that the service can be provided (S8: YES), the service verification unit 210b permanently changes the service version of the service provided to the client's ECU3 (step S19) and terminates the process.

[0091] If it is determined that the service cannot be provided (S18: NO), the service verification unit 210b reverts the service version that was temporarily changed in step S15 back to the original service version (step S20). The service verification unit 210b then prohibits the acceptance of search messages and request messages with different service versions that are subsequently received from the client's ECU3 as targets for verification processing (step S21), and terminates the process.

[0092] Furthermore, ECU2 stores in storage unit 22 a table that associates the identification information of the client ECU3 that performed the verification process, the service ID and service version of the service requested by ECU3, and the results of the verification process. When ECU2 receives a similar search message or request message from a verified ECU3, it may refer to this table to determine whether or not to respond to the received message. In the flowchart above, the process of permanently changing the service version in step S19, and the process of prohibiting the acceptance of subsequent messages in step S21, can be performed by ECU2 setting appropriate information in this table.

[0093] Figure 12 is a flowchart showing the procedure of the verification process performed by the server's ECU2 according to this embodiment, and details the process performed in step S17 of the flowchart shown in Figure 11. The service verification unit 210b of the processing unit 21 of the ECU2 according to this embodiment determines whether or not it has received a request message from the ECU3 to be verified (step S31). If it has not received a request message (S31: NO), the service verification unit 210b waits until it receives a request message.

[0094] If a request message is received (S31:YES), the service verification unit 210b determines whether the received request message is valid or not (step S32). At this time, the service verification unit 210b can determine whether the received request message is valid or not based on, for example, whether the various ID information contained in the request message is a valid value, whether the change in the session ID of the request message is valid, and whether the value of the payload of the request message is within a valid range. The service verification unit 210b sends a response message to the received request message to the ECU3 that sent the request message (step S33). The response message sent by the ECU2 at this time may be a response message containing valid information, or it may be a response message containing predetermined values ​​for verification. The service verification unit 210b determines whether it has finished receiving a predetermined number of request messages from the ECU3 to be verified (step S34). If it has not finished receiving a predetermined number of request messages (S34:NO), the service verification unit 210b returns to step S31.

[0095] If the service verification unit 210b has finished receiving a predetermined number of request messages (S34:YES), it determines whether the number of request messages deemed legitimate out of the predetermined number of received request messages exceeds a threshold (step S35). If the number of legitimate request messages exceeds the threshold (S35:YES), the service verification unit 210b determines that it is possible to provide this service to the ECU3 under verification (step S36), terminates the verification process, and returns to the flowchart in Figure 11. If the number of legitimate request messages does not exceed the threshold (S35:NO), the service verification unit 210b determines that it is impossible to provide this service to the ECU3 under verification (step S37), terminates the verification process, and returns to the flowchart in Figure 11.

[0096] Figure 13 is a flowchart showing the steps of other processing performed by the server's ECU2 according to this embodiment. The application processing unit 210c of the processing unit 21 of the server's ECU2 according to this embodiment determines whether or not it has received a request message sent by the client's ECU3 (step S51). If a request message is received (S51: YES), the application processing unit 210c determines whether or not the service ID and service version included in the received request message match the service ID and service version of the service it provides (step S52). If the service ID and service version do not match (S52: NO), the application processing unit 210c returns to step S51.

[0097] If the service ID and service version match (S52: YES), the application processing unit 210c performs information processing to provide the requested service based on the information contained in the received request message (step S53). The application processing unit 210c sends a response message containing the information obtained as a result of the information processing to the ECU3 that sent the request message (step S54), and returns to step S51.

[0098] If no request message has been received (S51: NO), the service information provision unit 210a of the processing unit 21 determines whether a predetermined period has elapsed since the last transmission of a periodic provision message (step S55). If the predetermined period has elapsed (S55: YES), the service information provision unit 210a transmits a periodic provision message (step S56) and returns to step S51. If the predetermined period has not elapsed (S55: NO), the service information provision unit 210a returns to step S51.

[0099] <Summary> In this embodiment of the server configuration described above, the server processing unit 210 of the ECU2 receives a search message from the client processing unit 310 of the ECU3 of the client requesting the service, which searches for the service. This search message includes the service ID and service version of the service required by the client processing unit 310, and the server processing unit 210 determines whether the service version included in the received search message matches the service version of the service it provides. If both service versions match, the server processing unit 210 performs information processing to provide this service to the client processing unit 310. If both service versions do not match, the server processing unit 210 performs verification processing to determine whether the client processing unit 310 can receive a service with a different service version. If the verification process shows that the client processing unit 310 can receive a service with a different service version, the server processing unit 210 performs information processing to provide the service requested by the client processing unit 310. In this way, the server processing unit 210 of the ECU2 of the server can avoid as much as possible the client processing unit 310 being unable to receive a service due to a mismatch in service versions.

[0100] In this embodiment, if the verification process determines that the client processing unit 310 can receive services with different service versions, the server processing unit 210 first changes the service version of the service it provides to the service version included in the search message received from the client processing unit 310. This prevents service version mismatches from occurring thereafter, allowing the client processing unit 310 to operate smoothly.

[0101] In this embodiment, when verifying whether the client processing unit 310 can receive services with different service versions, the server processing unit 210 first temporarily changes the service version of the service it provides to the service version included in the search message received from the client processing unit 310. Then, the server processing unit 210 sends and receives messages regarding the provision of services with the client processing unit 310 based on the changed service version. Based on the results of this message exchange, the server processing unit 210 verifies whether the client processing unit 310 can receive services with different service versions. This allows the ECU 2 to verify whether any problems occur when it changes the service version of the service it provides to the service version of the service requested by the client processing unit 310 of the ECU 3.

[0102] In this embodiment, the server processing unit 210 of ECU2 receives a search message from the client processing unit 310 of ECU3 to search for the availability of a desired service, and in response to this search message, sends a provision message containing information such as the service ID and service version of the service it provides. This allows the client processing unit 310 to send a search message and receive a provision message from the server processing unit 210 when it needs the provision message.

[0103] In this embodiment, the server processing unit 210 of the ECU2 repeatedly sends a provision message containing information such as the service ID and service version of the service it provides at predetermined intervals. As a result, the client processing unit 310 can receive the periodically sent provision messages and determine whether the service it needs is being provided, and can also determine which server processing unit 210 is providing the service.

[0104] In the in-vehicle information processing system according to this embodiment, a server processing unit 210 is provided in ECU2, and a client processing unit 310 is provided in ECU3. The server processing unit 210 of ECU2 sends and receives messages with ECU3, which is equipped with the client processing unit 310. This allows ECU2 to perform information processing to provide services required by other devices.

[0105] In this embodiment, the ECUs 2 and 3 of the in-vehicle information processing system are configured to send and receive service-related messages in accordance with the SOME / IP standard. However, the system is not limited to this configuration, and may be configured to send and receive messages in accordance with standards other than SOME / IP. The technology described in this embodiment can be used in any system in which a server and client send and receive messages.

[0106] (Variation 1) Figure 14 is a schematic diagram illustrating an example of processing performed in an in-vehicle information processing system according to Modification 1. In the in-vehicle information processing system according to Modification 1, when the server's ECU2 verifies whether it can provide a service with a different service version to ECU3, it first sends a verification command message to the ECU3 to be verified. The verification command message is a message that causes ECU3 to temporarily suspend normal information processing and to have ECU2 send the request messages necessary for the verification process. The verification command message may include information such as the type of message that ECU3 should send and the order in which they should be sent.

[0107] Upon receiving a verification command message, the client's ECU3 temporarily suspends its own information processing and repeatedly sends request messages and receives response messages based on the information contained in the verification command message. The server's ECU2 receives the request message sent by ECU3, determines whether it is correct or incorrect, and sends a response message to ECU3 in response to the request message. At this time, the service version of the request and response messages sent and received is set to "1.2".

[0108] ECU3 sends a predetermined number of request messages in accordance with the verification command message. After sending the predetermined number of request messages, ECU3 may resume its temporarily suspended information processing. ECU2 continues the verification process until it receives a predetermined number of request messages from ECU3. Once it receives the predetermined number of request messages, it makes a final decision on whether ECU3 can receive services with different service versions based on the pass / fail judgment result of each request message. If, during the verification process, it determines that ECU3 can use a service with service version "1.1", ECU2 permanently changes the version of the service provided to ECU3 to "1.2". Subsequently, ECU2 receives a request message from ECU3 with service version "1.2" set, performs information processing to provide the service with service version "1.1", sets the service version of the response message containing the processing result to "1.2", and sends it to ECU3.

[0109] In the in-vehicle information processing system according to Modification 1 of the above configuration, the server processing unit 210 of the server's ECU2 sends a verification command message to the client processing unit 310 of the client's ECU3, instructing it to send a predetermined request message. The client processing unit 310 sends a request message in response to this verification command message. The server processing unit 210 performs verification based on the request message sent by the client processing unit 310 in response to the verification command message. This allows the server processing unit 210 to verify with greater accuracy whether the client processing unit 310 can receive services with different service versions.

[0110] (Modification 2) Figure 15 is a schematic diagram illustrating the configuration of an in-vehicle information processing system according to Modification 2. In the in-vehicle information processing system according to Modification 2, one ECU 5 is equipped with both a client processing unit 310 and a server processing unit 210. The ECU 5 according to Modification 2 is configured to include a processing unit 51, a storage unit 52, a communication unit 53, etc. The storage unit 52 stores a client program 32a and a server program 22a. In the ECU 5, the processing unit 51 reads and executes the client program 32a stored in the storage unit 52, thereby realizing the client processing unit 310 as a software function unit in the processing unit 51. Similarly, in the ECU 5, the processing unit 51 reads and executes the server program 22a, thereby realizing the server processing unit 210 as a software function unit in the processing unit 51. The processing unit 51 can operate multiple programs in parallel, for example, by time sharing, and the client processing unit 310 and the server processing unit 210 operate in parallel.

[0111] In the ECU 5 according to Modification 2, the client processing unit 310 and the server processing unit 210 can exchange request messages and response messages, and exchange search messages and provision messages without communication with an external device by the communication unit 53. Regardless of whether the server processing unit 210 is located inside or outside the device, the client processing unit 310 can perform processes such as searching for a server processing unit 210 that provides the services necessary for its own processing, verifying whether it can receive services with different service versions, and requesting the server processing unit 210 to provide services.

[0112] In the in-vehicle information processing system according to the modified configuration 2 described above, the ECU 5, which is equipped with a server processing unit 210, is equipped with a client processing unit 310. As a result, the server processing unit 210 of the ECU 5 can provide services to the client processing unit 310 inside the device in the same manner as when providing services to an external device.

[0113] Each device in the in-vehicle system is equipped with a computer comprising a microprocessor, ROM, RAM, etc. The arithmetic processing unit, such as the microprocessor, may read and execute a computer program, which includes some or all of the steps in a sequence diagram or flowchart as shown in Figures 10 to 13, from a storage unit such as ROM or RAM. The computer programs of these multiple devices can each be installed from an external server device or the like. Furthermore, the computer programs of these multiple devices are distributed in a state where they are stored on a recording medium such as a CD-ROM, DVD-ROM, or semiconductor memory.

[0114] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is indicated by the claims, not in the sense described above, and all modifications in the sense and scope equivalent to the claims are intended. [Explanation of symbols]

[0115] 1 vehicle 2. ECU (In-vehicle Information Processing Unit) 3,3a~3c ECU 4 Repeater 5 ECU 21 Processing Unit 22 Memory section 22a Server Program 23 Communications Department 31 Processing Unit 32 Storage section 32a Client Program 33 Communications Department 51 Processing Unit 52 Storage section 53 Communications Department 98,99 recording media 210 Server Processing Unit 210a Service Information Department 210b Service Verification Department 210c Application Processing Unit 310 Client Processing Unit 310a Service Search Section 310b Application Processing Unit

Claims

1. An in-vehicle information processing device comprising a server processing unit that performs processing to provide services in response to requests, The server processing unit receives a search message from the client processing unit requesting the service, and searches for the requested service. The search message includes identification information and version information of the requested service, The server processing unit, Determine whether the version information contained in the received search message matches the version information of the service provided by the system. If it is determined that the two version information entries do not match, the version information of the service provided by the service provider will be temporarily changed to the version information included in the search message. Based on the temporarily changed version information, messages are sent and received between the client processing unit and the client processing unit. Based on the results of sending and receiving the aforementioned messages, it is verified whether or not to provide a service with different version information to the client processing unit. When it is possible to provide a service with different version information, the service is provided to the client processing unit. In-vehicle information processing system.

2. The server processing unit, A command is given to the client processing unit to send a predetermined message, The client processing unit receives a message sent in response to the aforementioned command. Perform verification based on the received message. The in-vehicle information processing device according to claim 1.

3. The server processing unit, The client processing unit receives a search message sent to search for the availability of the desired service, In response to the aforementioned search message, the system sends a service message containing the identification and version information of the service it provides. The in-vehicle information processing device according to claim 1 or claim 2.

4. The server processing unit repeatedly sends a service message containing identification information and version information of the service it provides at predetermined intervals. An in-vehicle information processing device according to any one of claims 1 to 3.

5. The server processing unit sends and receives messages with other devices equipped with the client processing unit. An in-vehicle information processing device according to any one of claims 1 to 4.

6. The client processing unit is provided, An in-vehicle information processing device according to any one of claims 1 to 4.

7. An information processing method in which the server processing unit of an in-vehicle information processing device performs processing to provide services in response to a request from the client processing unit, The server processing unit receives a search message from the client processing unit requesting the service, which searches for the requested service. The search message includes identification information and version information of the requested service, The server processing unit determines whether the version information contained in the received search message matches the version information of the service it provides. If the server processing unit determines that the two version information items do not match, it temporarily changes the version information of the service it provides to the version information included in the search message. The server processing unit sends and receives messages with the client processing unit based on the temporarily changed version information. Based on the results of sending and receiving the message, the server processing unit verifies whether it is possible to provide the client processing unit with a service that has different version information. When the server processing unit is capable of providing a service with different version information, it provides that service to the client processing unit. Information processing methods.

8. The computer installed in the vehicle, A client program requests the provision of a service and receives a search message to find the requested service. The search message includes identification information and version information of the requested service, Determine whether the version information contained in the received search message matches the version information of the service provided by the system. If it is determined that the two version information entries do not match, the version information of the service provided by the service provider will be temporarily changed to the version information included in the search message. Based on the temporarily changed version information, messages are sent and received between the client program and the system. Based on the results of sending and receiving the aforementioned messages, it is verified whether or not to provide the client program with a service that has different version information. When it is possible to provide a service with different version information, provide that service to the client program. A server program that executes a process.

Images