Vehicle-mounted information processing device, information processing method, and server program

Abstract

Provided is an in-vehicle information processing device, an information processing method, and a server program that can expect to avoid a situation in which a client cannot accept a service due to inconsistency in versions as much as possible. In the in-vehicle information processing device of the present embodiment, a server processing section receives a search message that searches for a requested service from a client processing section that requests provision of the service, the search message including identification information of the requested service and version information, the server processing section determines whether the version information included in the received search message and version information of a service provided by itself are consistent, in the case where it is determined that the two version information are inconsistent, it is verified whether the service with different version information can be provided to the client processing section, and in the case where the service with different version information can be provided, the service is provided to the client processing section.

Description

Technical Field

[0001] This disclosure relates to an in-vehicle information processing device, information processing method, and server program for providing services to clients. Background Technology

[0002] In recent years, the development of autonomous driving functions in vehicles has continuously advanced, demanding more sophisticated control systems for in-vehicle systems. As a service-oriented middleware architecture designed to meet these requirements, SOME / IP (Scalable service-Oriented Middleware over IP) has attracted considerable attention.

[0003] Patent Document 1 proposes a scheme for an ECU (Electronic Control Unit) to initiate the provision of a new service by sending its identification information to an external device before the service begins, conducting tests on the new service according to test instructions from the external device and sending the test results back to the external device, and then initiating the provision of the new service upon receiving determination information from the external device indicating whether the provision of the new service is permitted. After receiving the identification information from the ECU, the external device uses the ECU to send test instructions and receives the results, determines whether to permit the provision of the new service based on the received results, and sends the determination information back to the ECU.

[0004] Prior art literature

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Application Publication No. 2016-163244 Summary of the Invention

[0007] Summary of the invention

[0008] The problem that the invention aims to solve

[0009] In SOME / IP, the server sets the service ID and version information for the services provided. Clients that want the service to be provided specify the service ID and version to retrieve whether the service is available. For example, if the server program providing the service is upgraded but the client program is not upgraded, the version of the service provided by the server will be inconsistent with the version of the service expected by the client, resulting in the client being unable to accept the expected service.

[0010] This disclosure is made in view of the following circumstances, and its purpose is to provide an in-vehicle information processing device, information processing method, and client program that can minimize the possibility of clients being unable to receive services due to version inconsistencies.

[0011] Solution for solving the problem

[0012] The in-vehicle information processing device of this type includes a server processing unit that processes services provided according to requests. The server processing unit receives a retrieval message from a client processing unit requesting the service. The retrieval message includes identification information and version information of the requested service. The server processing unit determines whether the version information in the received retrieval message matches the version information of the service it provides. If the server processing unit determines that the two sets of version information are inconsistent, it verifies whether the service with different version information can be provided to the client processing unit. If the server processing unit can provide the service with different version information, it provides the service to the client processing unit.

[0013] This application can be implemented not only as an apparatus having such a characteristic processing unit, but also as a method that sets the above-described characteristic processing as steps, or as a computer program for causing a computer to execute the above-described steps. It can be implemented as a semiconductor integrated circuit that is part or all of the above-described apparatus, or as other apparatus or systems that include the above-described apparatus.

[0014] Invention Effects

[0015] Based on the above, we can expect to minimize situations where clients are unable to accept the service due to version inconsistencies. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating the structure of the vehicle information processing system of this embodiment.

[0017] Figure 2 This is a schematic diagram illustrating the communication of the vehicle information processing system of this embodiment.

[0018] Figure 3 This is a schematic diagram illustrating the communication of the vehicle information processing system of this embodiment.

[0019] Figure 4 This is a block diagram showing the structure of the ECU on the client side in this embodiment.

[0020] Figure 5 This is a block diagram illustrating the structure of the server-side ECU in this embodiment.

[0021] Figure 6 This is a schematic diagram illustrating a structural example of the retrieval and provision messages sent and received by the vehicle information processing system according to this embodiment.

[0022] Figure 7 This is a schematic diagram illustrating an example of the configuration of request messages and response messages sent and received in the vehicle information processing system of this embodiment.

[0023] Figure 8 This is a schematic diagram illustrating an example of the processing performed by the vehicle information processing system of this embodiment.

[0024] Figure 9 This is a schematic diagram illustrating an example of the processing performed by the vehicle information processing system of this embodiment.

[0025] Figure 10 This is a flowchart illustrating the sequence of processes performed by the client's ECU in this embodiment.

[0026] Figure 11 This is a flowchart illustrating the sequence of processing performed by the ECU of the server in this embodiment.

[0027] Figure 12 This is a flowchart showing the sequence of verification processes performed by the ECU of the server in this embodiment.

[0028] Figure 13 This is a flowchart illustrating the sequence of other processes performed by the ECU of the server in this embodiment.

[0029] Figure 14 This is a schematic diagram illustrating an example of the processing performed by the vehicle information processing system of Modified Example 1.

[0030] Figure 15 This is a schematic diagram illustrating the structure of the vehicle information processing system in Modified Example 2. Detailed Implementation

[0031] [Description of embodiments of this disclosure]

[0032] First, embodiments of this disclosure will be listed for explanation. At least some of the embodiments described below may be combined arbitrarily.

[0033] (1) The vehicle information processing device of this form includes a server processing unit, which performs processing to provide services according to a request. The server processing unit receives a search message for a requested service from a client processing unit that requests the 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 is consistent with the version information of the service it provides. If the server processing unit determines that the two version information are inconsistent, it verifies whether the service with different version information can be provided to the client processing unit. If the server processing unit can provide the service with different version information, it provides the service to the client processing unit.

[0034] In this configuration, the server processing unit of the in-vehicle information processing device receives a service retrieval message from a client processing unit requesting the service. This retrieval message contains identification information and version information of the service required by the client processing unit. The server processing unit determines whether the version information in the received retrieval message matches the version information of the service it provides. If the two sets of version information match, the server processing unit provides the service to the client processing unit. If the two sets of version information do not match, the server processing unit verifies whether the client processing unit can accept the service with different version information. If the verification result indicates that the client processing unit can accept the service with different version information, the server processing unit processes the information to provide the service requested by the client processing unit. Therefore, the server processing unit of the in-vehicle information processing device can, as far as possible, avoid situations where the client processing unit cannot accept the service due to inconsistent service version information.

[0035] (2) Preferably, when the server processing unit is able to provide services with different version information, it changes the version information of the services subsequently provided to the client processing unit to the version information contained in the search message.

[0036] In this configuration, if the verification result shows that the client processing unit can accept services with different version information, the server processing unit will subsequently change the version information of the services it provides to the client processing unit to the version information contained in the retrieval messages received from the client processing unit. Therefore, version information inconsistencies will no longer occur, and smooth processing by the client processing unit can be expected.

[0037] (3) Preferably, the server processing unit temporarily changes the version information of the service it provides to the version information contained in the search message. Based on the temporarily changed version information, the server processing unit sends and receives messages with the client processing unit. Based on the result of the sending and receiving of the messages, the server processing unit verifies whether it can provide services with different version information.

[0038] In this configuration, when verifying whether the client processing unit can accept the provision of services with different version information, the server processing unit first temporarily changes the version information of the service it provides to the version information contained in the retrieval message received from the client processing unit. Then, based on the changed version information, the server processing unit sends and receives messages related to service provision with the client processing unit. Based on the result of this message exchange, the server processing unit verifies whether the client processing unit can accept the provision of services with different version information. Therefore, when the in-vehicle information processing device changes the version information of the service it provides to the version information of the service requested by the client processing unit, it can verify whether any malfunctions have occurred.

[0039] (4) Preferably, the server processing unit provides the client processing unit with a command to send a specified message, the server processing unit receives the message sent by the client processing unit according to the command, and the server processing unit performs verification based on the received message.

[0040] In this configuration, the server processing unit provides a command to the client processing unit to send a specified message, and performs verification based on the message sent by the client processing unit according to the command. Therefore, the server processing unit can verify with greater accuracy whether the client processing unit can accept services with different version information.

[0041] (5) Preferably, the server processing unit receives a search message sent by the client processing unit in order to retrieve whether the desired service is available, and the server processing unit sends a provision message containing identification information and version information of the service it provides as a response to the search message.

[0042] In this configuration, the server processing unit of the vehicle information processing device receives a search message from the client processing unit indicating the availability of a desired service, and sends a provision message containing identification information and version information of the service it provides as a response to the search message. Thus, when the client processing unit requires a provision message from the server processing unit, it can send a search message and receive a provision message in return.

[0043] (6) Preferably, the server processing unit repeatedly sends a provision message containing identification information and version information of the services it provides at a predetermined period.

[0044] In this configuration, the server processing unit of the in-vehicle information processing device repeatedly sends provision messages containing identification information and version information of the services it provides at predetermined intervals. Thus, the client processing unit, receiving these periodically sent provision messages, can determine whether the service it requires is being provided and which server processing unit is providing the service.

[0045] (7) Preferably, the server processing unit sends and receives messages with other devices that have the client processing unit.

[0046] In this configuration, the server processing unit of the in-vehicle information processing device sends and receives messages with other devices equipped with client processing units. Therefore, the in-vehicle information processing device is capable of processing to provide services required by other devices.

[0047] (8) Preferably, the client processing unit is included.

[0048] In this embodiment, the in-vehicle information processing device, which includes a server processing unit, also includes a client processing unit. Therefore, the in-vehicle information processing device can perform processing to provide services to the client processing unit within the device, using the same method as when providing services to external devices.

[0049] (9) The information processing method of this form is a method in which the server processing unit of the vehicle information processing device provides services according to the request from the client processing unit. The server processing unit receives a search message for the requested service from the client processing unit that requests the service. The search message contains the identification information and version information of the requested service. The server processing unit determines whether the version information contained in the received search message is consistent with the version information of the service it provides. If the server processing unit determines that the two version information are inconsistent, it verifies whether the service with different version information can be provided to the client processing unit. If the server processing unit can provide the service with different version information, it provides the service to the client processing unit.

[0050] In this form, similar to form (1), it is expected that situations where services cannot be accepted due to inconsistencies in service version information can be avoided as much as possible.

[0051] (10) The server program of this form causes the computer mounted in the vehicle to perform the following processing: receiving a retrieval message for a requested service from a client program that provides the requested service; the retrieval message contains identification information and version information of the requested service; determining whether the version information contained in the received retrieval message is consistent with the version information of the service it provides; if the two version information are inconsistent, verifying whether the service with different version information can be provided to the client program; if the service with different version information can be provided, providing the service to the client program.

[0052] In this form, similar to form (1), it is expected that situations where services cannot be accepted due to inconsistencies in service version information can be avoided as much as possible.

[0053] [Details of the embodiments of this disclosure]

[0054] Hereinafter, specific examples of vehicle information processing systems according to embodiments of the present disclosure will be described with reference to the accompanying drawings. This disclosure is not limited to these examples, but is disclosed by the claims and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0055] <System Structure>

[0056] Figure 1 This is a schematic diagram illustrating the structure of the vehicle information processing system of this embodiment. The vehicle information processing system of this embodiment comprises multiple ECUs 2 and 3 mounted on a vehicle 1 that communicate via a repeater 4, and performs various information processing related to the driving control of the vehicle 1 through the cooperation of these multiple ECUs 2 and 3. The illustrated vehicle information processing system is a star-shaped network structure in which one ECU 2 and three ECUs 3 are each connected to a repeater 4 via separate communication lines. However, the number of devices and network structure included in the vehicle information processing system are only examples and are not limited thereto. The total number of ECUs 2 and 3 included in the vehicle information processing system can be three or less, or five or more. Furthermore, the multiple ECUs 2 and 3 can also be connected via a bus-type or ring-type network structure.

[0057] ECU2 and ECU3 are information processing devices installed in vehicle 1. For example, ECU2 and ECU3 may include various ECUs such as ECUs that control the autonomous driving of vehicle 1, ECUs that control the operation of the engine, ECUs that control the locking / unlocking of doors, ECUs that control the turning on / off of lights, ECUs that control the operation of airbags, and ECUs that control the operation of ABS (Antilock Brake System). It should be noted that although the vehicle information processing device is set as ECU2 and ECU3 in this embodiment, it is not limited to this, and the vehicle information processing device can also be various devices other than ECU2 and ECU3.

[0058] Repeater 4 is a device with multiple ports for connecting communication lines and relaying the transmission and reception of messages between these communication lines. For example, repeater 4 may be a switching hub or gateway. Repeater 4 relays message transmission and reception by sending messages received from one communication line to another. It should be noted that in vehicle information processing systems employing, for example, a bus-type network structure with multiple ECUs 2 and 3 connected to a common communication line, repeater 4 may not be required.

[0059] In the vehicle information processing system of this embodiment, message sending and receiving between ECU2 and ECU3 are performed according to the SOME / IP communication standard. SOME / IP is a standard classified as Layer 5 or higher in the OSI reference model, enabling communication between applications in the form of service requests and responses. In this embodiment, ECU2 is a server-side device providing services, and ECU3 is a client-side device receiving services. However, this client-server relationship is just one example; each ECU2 and ECU3 can be either a client or a server. It should be noted that for communication below Layer 4 of the OSI reference model, any standard can be used, but standards such as Ethernet (registered trademark), TCP (Transmission Control Protocol), or UDP (User Datagram Protocol) can be used.

[0060] Figure 2 and Figure 3 This is a schematic diagram illustrating the communication of the vehicle information processing system according to this embodiment. In this diagram, the three ECUs 3 are distinguished by different designations: ECU3a, 3b, and 3c. For example... Figure 2 As shown, ECU3a sends a retrieval message (retrieval frame) for the services it needs after a predetermined time, such as after starting or restarting. In this embodiment, ECU3a sends the retrieval message using a method called multicast, which sends a message to multiple devices simultaneously. Therefore, the retrieval message sent by ECU3a is received by ECU2, 3b, and 3c (in... Figure 2 (The dashed arrows in the text indicate the sending and receiving of retrieval messages).

[0061] The retrieval message sent by ECU3a includes a service ID for identifying the service required by ECU3a and a service version for identifying the version of the software (server program) providing the service. ECUs 2, 3b, and 3c, upon receiving the retrieval message, determine whether they can provide a service consistent with the service ID and service version contained in the received retrieval message. In this example, ECU2 can provide the service, and ECU2 sends a provision message (provision frame) to ECU3a, which sent the retrieval message, notifying it of the content it can provide. At this time, ECU2 uses a unicast method, where the delivery destination of the provision message is set to ECU3a, to send the provision message (in...). Figure 2 In Chinese, arrows with single-dotted lines are used to indicate the sending and receiving of messages.

[0062] Upon receiving a provision message from ECU2, ECU3a can determine that a device capable of providing the service exists and that this device is ECU2. The provision message includes information such as the service ID and service version, the IP address and port number of the server (ECU2) providing the service. Subsequently, ECU3a sends a request for information related to the service to ECU2, and ECU2 sends a response containing service-related information back to ECU3a in response to this request. Thus, ECU2, acting as the server, provides services to ECU3a, which, acting as the client, allows ECU3a to perform various information processing using the services provided by ECU2.

[0063] Furthermore, in this embodiment, the transmission of the provision message is not only performed as a response to the retrieval message, but the ECU2 providing the service also spontaneously transmits the provision message at a predetermined period. The ECU2 capable of providing the service repeatedly transmits the provision message, containing information related to the service it provides, at a predetermined period of, for example, a few milliseconds to a few seconds. Figure 3 As shown, when ECU2 periodically sends a provision message, it uses a method called multicast, which sends a provision message to multiple devices simultaneously. Therefore, the provision message sent by ECU2 is received by ECUs 3a, 3b, and 3c (in... Figure 3 In Chinese, arrows with single-dotted lines are used to indicate the sending and receiving of messages.

[0064] The retrieval message and the periodically sent provision message can be the same message. ECU3a, upon receiving this message, will know that the services it requires are provided by ECU2, as described above, and can subsequently send service-related requests to ECU2. ECUs3b and 3c, which do not require services, can simply discard (ignore) the periodically sent provision message.

[0065] Thus, in the vehicle information processing system of this embodiment, the ECU3a on the client side requiring the service needs to know in advance about the ECU2 providing the service based on the provided message. After determining that ECU2 is providing the service, ECU3a sends and receives messages with ECU2, and can receive the service provided by ECU2 and process the information. ECU3a sends a request message for the service to ECU2, and in response to the request message, ECU2 sends a response message to ECU3a.

[0066] It should be noted that, in this embodiment, the service provided by the ECU2 acting as the server can be the provision of information possessed by the ECU2, such as sending messages containing various information including the vehicle speed of the vehicle 1 or the detection results of objects around the vehicle 1 to the requesting source ECU3a. Furthermore, for example, if the ECU2 is a device that controls vehicle-mounted equipment such as the lights or door locks of the vehicle 1, the ECU2 can provide a service of controlling the aforementioned vehicle-mounted equipment according to a request from the ECU3a. The service provided by the ECU2 acting as the server is not limited to the above-described services and can be various processes.

[0067] Here, in the ECUs 2 and 3a to 3c included in the vehicle information processing system, version upgrades are sometimes performed through software updates. Version upgrades can occur simultaneously across all devices in the vehicle information processing system, or they can occur individually in each device. Therefore, situations may arise where, for example, the software of ECU 3a, which receives the service, is upgraded, but the software of ECU 2, which provides the service, is not upgraded. In such cases, even if ECU 3a sends a retrieval message specifying the service with the new version, ECU 2, receiving the message, will not send a service request message to ECU 3a because the version of the service it provides is different, and ECU 3a cannot receive the service. Furthermore, although ECU 2 periodically sends service request messages specifying the service with the old version, ECU 3a, receiving the message, will not send a service request message to ECU 2 because the version of the service it desires is different. In other words, service provision from ECU 2 to ECU 3a is impossible.

[0068] Therefore, in the vehicle information processing system of this embodiment, when a client-side ECU3a exists that wants to provide a service with the same service ID but a different service version than the service it provides, the server-side ECU2 verifies whether the client-side ECU3a can accept the service. If the verification result determines that the client-side ECU3a can accept the service with a different service version, the server-side ECU2 can perform processing for providing the service to the client-side ECU3a.

[0069] <Device Structure>

[0070] Figure 4This is a block diagram illustrating the structure of the client-side ECU3 in this embodiment. The ECU3 in this embodiment is configured with a processing unit (processor) 31, a storage unit (memory) 32, and a communication unit (transceiver) 33. The processing unit 31 is configured using a computing processing device 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 retrieving the server providing the required services and processing information corresponding to the services provided by the server.

[0071] The storage unit 32 is constructed using non-volatile storage 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 required for processing by the processing unit 31. In this embodiment, the storage unit 32 stores the client program 32a executed by the processing unit 31.

[0072] The client program 32a can be written to the storage unit 32 during, for example, the manufacturing stage of the ECU 3. Furthermore, the client program 32a can be distributed via a remote server device, and the ECU 3 can also obtain the client program 32a and write it to the storage unit 32 by communicating with the server device. Alternatively, the ECU 3 can 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. Furthermore, a writing device can read the client program 32a recorded on the recording medium 99 and write it to the storage unit 32 of the ECU 3. The client program 32a can be provided in the form of distribution via a network or in the form of recording on the recording medium 99.

[0073] The communication unit 33 is connected to a communication line configured in vehicle 1, and transmits and receives messages with other ECUs 2 and 3 via this communication line. In this embodiment, the communication unit 33 transmits and receives messages according to a communication standard such as Ethernet. The communication unit 33 is constructed using an IC (Integrated Circuit) such as an Ethernet PHY (physical layer). However, the communication standard used by the communication unit 33 is not limited to Ethernet, and various communication standards such as CAN (Controller Area Network) or FlexRay can be used. The communication unit 33 transmits messages by outputting data provided from the processing unit 31 as an electrical signal to the communication line. Furthermore, the communication unit 33 samples 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.

[0074] In this embodiment, the ECU3 reads and executes the client program 32a stored in the storage unit 32 via the processing unit 31, thus implementing the client processing unit 310 as a software functional unit within the processing unit 31. The client processing unit 310 performs various processing steps as a client providing services, in accordance with the SOME / IP standard. In this embodiment, the client processing unit 310 includes a service retrieval unit 310a and an application processing unit 310b, among others.

[0075] The service retrieval unit 310a retrieves and processes the services required for its own processing from the server. The service retrieval unit 310a sends a retrieval message from the communication unit 33 using multicast, specifying the service ID and service version of the services required for its processing. For the sent retrieval message, the service retrieval unit 310a receives a provision message from the server, obtains information such as the IP address and port number contained in the received provision message, and thereby determines whether a server providing the service exists and obtains the information required for communication with the server. Furthermore, the service retrieval unit 310a receives provision messages periodically sent by the server, obtains information such as the IP address and port number contained in the received provision messages, and thereby determines whether a server providing the service exists and obtains the information required for communication with the server.

[0076] Application processing unit 310b utilizes the provided services to perform information processing related to applications specific to each ECU3. Application processing unit 310b sends a request message specifying the service ID and service version to the server retrieved by service retrieval unit 310a, and receives a response message sent accordingly. Application processing unit 310b obtains information contained in the received response message and performs various information processing based on the obtained information. For example, if application processing unit 310b sends a request message to the server requesting information about the vehicle speed of vehicle 1, and obtains the vehicle speed information contained in the response message received from the server accordingly, it can perform various information processing related to the vehicle speed. The information processing performed by application processing unit 310b using the services provided by the server can be arbitrary.

[0077] Figure 5 This is a block diagram illustrating the structure of the server-side ECU2 in this embodiment. The ECU2 in this embodiment is configured with a processing unit (processor) 21, a storage unit (memory) 22, and a communication unit (transceiver) 23. The processing unit 21 is configured using an arithmetic processing device such as a CPU or MPU. By reading and executing the server program 22a stored in the storage unit 22, the processing unit 21 can perform various processes, such as processing service retrieval notifications and providing services to clients.

[0078] The storage unit 22 is constructed using non-volatile storage elements such as flash memory or EEPROM. The storage unit 22 stores various programs executed by the processing unit 21 and various data required for processing by the processing unit 21. In this embodiment, the storage unit 22 stores the server program 22a executed by the processing unit 21.

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

[0080] The communication unit 23 is connected to a communication line configured in vehicle 1, and transmits and receives messages with other ECUs 3 via this communication line. In this embodiment, the communication unit 23 transmits and receives messages according to a communication standard such as Ethernet. The communication unit 23 can be configured, for example, using an IC with an Ethernet PHY. However, the communication standard used by the communication unit 23 is not limited to Ethernet, and various communication standards such as CAN or FlexRay can be used. The communication unit 23 transmits messages by outputting data provided from the processing unit 21 as an electrical signal to the communication line. Furthermore, the communication unit 23 samples 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.

[0081] In this embodiment, the ECU2 reads and executes the server program 22a stored in the storage unit 22, and implements the server processing unit 210 as a software functional unit in the processing unit 21. 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 providing unit 210a, a service verification unit 210b, and an application processing unit 210c, etc.

[0082] The service information providing unit 210a processes the sending of a provision message containing information related to the services it provides. Upon receiving a search message from a client, the service information providing unit 210a 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 providing unit 210a sends the provision message via unicast to the client that sent the search message. Furthermore, the service information providing unit 210a sends the provision message containing information related to the services it provides via multicast at predetermined intervals.

[0083] When a client ECU3 is requested to provide a service with the same service ID but a different service version than the service it provides, the service verification unit 210b verifies whether ECU3 can accept the service with the different service version. The service verification unit 210b obtains the service ID and service version contained in the search message received from the client ECU3. If the service ID in the search message matches the service ID of its own service but the service version in the search message does not match the service version of its own service, the verification process begins. The service verification unit 210b temporarily changes the service version of the service it provides to the client ECU3 to be verified to the service version in the search message. The service verification unit 210b then sends a message with the modified service version to the client ECU3.

[0084] Upon receiving the service request message, ECU3 determines that ECU2 is providing the service it desires and sends a request message to ECU2 to utilize that service. The request message includes the service ID and service version information of the requested service. ECU2's service verification unit 210b receives the request message from ECU3 and determines its correctness. The service verification unit 210b receives a predetermined number (e.g., 10) of request messages from ECU3. If the number of correctly identified request messages exceeds a threshold (e.g., 5), ECU3 is deemed capable of accepting services with different service versions. If the number of correctly identified request messages does not exceed the threshold, the service verification unit 210b determines that ECU3 cannot accept services with different service versions.

[0085] In addition, the service verification unit 210b can determine the correctness of each request message received from the ECU3 by using, for example, the following method.

[0086] • Whether the various ID information contained in the request message are valid values.

[0087] • Regarding the value of the session ID, which changes incrementally or decrementally with each request message, is the change in its value justified?

[0088] • Whether the parameters or return values ​​related to the service request are within the appropriate range.

[0089] However, the method for determining the correctness of a request message is not limited to the method described above. For example, if the message sending and receiving of ECU2 and 3 conforms to the SOME / IP standard, the service verification unit 210b can use whether the message is judged as an error under the SOME / IP standard as the above-mentioned correctness determination.

[0090] If the service verification unit 210b determines that ECU3 cannot accept the provision of a service with a different service version, it reverts the service version of the temporarily changed service to its original state and subsequently ceases to respond to retrieval and request messages received from ECU3 (however, this is limited to messages containing the same service ID as the verified service ID). Therefore, the client ECU3 cannot receive services from ECU2.

[0091] If the service verification unit 210b determines that the ECU3 can accept the provision of a service with a different service version, it maintains the service version of the temporarily changed service without reverting to the original state; that is, it permanently changes the service version. The service verification unit 210b then responds to subsequent retrieval and request messages received from the ECU3 using the changed service version. In other words, the ECU2 uses the service version contained in the provision and response messages sent to the ECU3 as the changed service version.

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

[0093] <Client and server processing>

[0094] Figure 6 This is a schematic diagram illustrating a structural example of the retrieval and provision messages sent and received using the vehicle information processing system of this embodiment. The retrieval message sent by the client ECU3 and the provision message sent by the server ECU2 in this embodiment consist of information including title information, message type, service ID, service version, and option information.

[0095] The message header information, such as Ethernet header, IP header, TCP / UDP header, and SOME / IP header, is used to store information defined by communication standards. The header information can store information such as MAC address, Ethernet type, IP address, or port number. The header information can be in any format, and the information stored in the header information can be arbitrary.

[0096] The message type stores information indicating whether the message is a retrieval message or a provision message. For example, the message is a retrieval message when the message type is set to "0", and a provision message when it is set to "1".

[0097] A service ID is a unique identifier provided by the server for a specific service. A service version is information that identifies the version of the service being provided; it is the version of the software that enables the server to function, for example, to provide the service identified by the service ID. In this embodiment, a larger service version value indicates a newer version. The service ID and service version contained in the retrieval message represent the service ID and service version of the service the client requests from the server. The service ID and service version contained in the provision message represent the service ID and service version of the services the server is capable of providing.

[0098] The option information provided to the message in this embodiment includes information such as the IP address and port number of the server providing the service. However, for the retrieval message, the client's IP address and port number are also provided as option information.

[0099] Figure 7 This is a schematic diagram illustrating one configuration example of request and response messages sent and received in the vehicle information processing system of this embodiment. A request message is a message from a client requesting service from a server. 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 in this embodiment include: header information containing standard header information for SOME / IP and other standard header information; 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 parameters related to the service request or return values ​​related to the service request.

[0100] The service ID and service version included in the SOME / IP header information are as described above. The method ID is the ID that specifies which method to use among the multiple methods provided by the service specified by the service ID. For example, when setting a value as the service ID for providing vehicle information, the method ID can be set as the value specified for methods such as providing vehicle speed, providing acceleration, or providing rudder angle.

[0101] A session ID is a numerical value that is incremented (by 1) each time a service is requested and provided. 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.

[0102] The message category setting is a numerical value that indicates whether the message is a request message from the client to the server or a response message from the server to the client.

[0103] The service request parameters included in the SOME / IP payload are information contained in the request message from the client to the server. These parameters are numerical values ​​and other information used in the processing related to the service implemented by the client, and are used by the client to set conditions for service processing. For services that do not require parameters, the request message may not include parameter information.

[0104] The return value of a service request is 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. Furthermore, if the request message requests a service such as control of in-vehicle equipment instead of information transmission, the value in the response message indicating whether the requested control is functioning correctly will be set as the return value.

[0105] Figure 8 and Figure 9 This is a schematic diagram illustrating an example of the processing performed by the vehicle information processing system according to this embodiment. In this diagram, it shows an example where the service version provided by the server ECU2 is "1.1", and the client ECU3 requests a service version upgrade from "1.1" to "1.2". Before the version upgrade, the client ECU3 sends a request message to the server ECU2 to set the service version to "1.1". Upon receiving this request message, the server ECU2 performs information processing to provide the service version "1.1", and sends a response message containing the result of the information processing to the requesting ECU3. At this time, the service version of the response message sent by ECU2 is "1.1".

[0106] Then, the software (client program 32a) used for information processing via the service in the client ECU3 is upgraded, updating the service version from "1.1" to "1.2". In contrast, the software (server program 22a) of the server ECU2 providing the service is not upgraded, and ECU2 provides the service with version "1.1". In this situation, even if ECU3 sends a retrieval message and a request message to ECU2 setting the service version to "1.2", ECU2 may be unable to send the provision message and response message back to ECU3 due to the different service versions.

[0107] After the version upgrade is completed, the client's ECU3 sends a retrieval message setting the service version to "1.2". In this embodiment, the server's ECU2, upon receiving this retrieval message, can identify that ECU3 has requested a service with the same service ID as the service it provides, but a different service version.

[0108] Therefore, ECU2 will temporarily change the version of the service provided to ECU3 from "1.1" to "1.2". ECU2 sends a provision message to ECU3, which sent the retrieval message, setting the service version to "1.2". Then, ECU2 begins a verification process to confirm whether it can utilize its own service version "1.1" for the information processing of ECU3 requesting the service version "1.2".

[0109] ECU2 then receives a request message with service version "1.2" from ECU3, determines the correctness of the received request message, and sends a response message to the requesting source ECU3. At this time, the service version of the response message sent by ECU2 is set to "1.2". ECU2 determines the correctness of the request message received from ECU3 based on factors such as whether the various ID information contained 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.

[0110] ECU2 continues verification processing until it receives a predetermined number of request messages from ECU3. Upon receiving the predetermined number of request messages, ECU2 makes a final determination based on the correctness of each request message to determine whether ECU3 can accept the provision of services with different service versions. If, for example, the number of valid request messages received exceeds a threshold, ECU2 determines that ECU3 can accept the provision of services with different service versions. If the number of valid request messages does not exceed the threshold, ECU2 determines that ECU3 cannot accept the provision of services with different service versions.

[0111] During the verification process, if it is determined that ECU3 can utilize the service version "1.1" (refer to...), Figure 8 ECU2 permanently changes the version of the service provided to ECU3 to "1.2". Then, ECU2 receives a request message from ECU3 to set the service version to "1.2", performs information processing to provide the service with version "1.1", and sends a response message containing the processing result with the service version set to "1.2" to ECU3.

[0112] During the verification process, if it is determined that ECU3 cannot utilize the service version "1.1" (refer to...), Figure 9 ECU2 reverts the service version, temporarily changed for verification processing, from "1.2" back to "1.1". Then, upon receiving a request message and a retrieval message from ECU3 setting the service version to "1.2", ECU2 does not send a response message or a provision message. That is, ECU2 does not respond to subsequent request messages and retrieval messages with different service versions received from ECU3, which it determined during verification processing could not provide service, and does not repeat the verification process.

[0113] Figure 10 This is a flowchart illustrating the processing sequence performed by the client ECU3 in this embodiment. In this embodiment, the ECU3 starts up, for example, when the ignition switch of vehicle 1 switches from an off state to an on state (step S1). After starting up, the service retrieval unit 310a of the processing unit 31 of the ECU3 sends a retrieval message via multicast to retrieve a server that provides the services it needs (step S2). Then, the service retrieval unit 310a determines whether it has received a provision message from the server or a provision message periodically sent by the server as a response to the retrieval message (step S3). If no provision message is received (S3: No), the service retrieval unit 310a waits until a provision message is received.

[0114] Upon receiving a provision message (S3: Yes), the application processing unit 310b begins information processing using the service provided by the ECU2, the source of the provision message, and sends a request message to the ECU2 on the server (step S4). The application processing unit 310b determines whether a response message from the ECU2 on the server has been received in response to the request message sent in step S4 (step S5). If no response message is 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 corresponding to the information contained in the received response message (step S6), and returns the processing to step S4.

[0115] Figure 11This is a flowchart illustrating the processing sequence performed by the server's ECU2 in this embodiment. The service information providing unit 210a of the server's ECU2 processing unit 21 in this embodiment determines whether a search message sent by the client's ECU3 has been received (step S11). If a search message has been received (S11: Yes), the service information providing unit 210a determines whether the service ID contained 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 providing unit 210a does not send a provision message and ends the processing.

[0116] If the service ID matches (S12: Yes), the service information providing unit 210a determines whether the service version contained in the received search message matches the service version of the service it provides (step S13). If the service version matches (S13: Yes), the service information providing unit 210a sends a provision message to the ECU3, the source of the search message (step S14), and ends the process.

[0117] If the service version is inconsistent (S13: No), the service information providing unit 210a temporarily changes the service version of the service it provides to the service version contained in the received search message (step S15). Then, the service information providing unit 210a sends a service version provision message with the temporarily changed service version set to the ECU3, the source of the search message (step S16).

[0118] Then, the service verification unit 210b of the processing unit 21 performs verification processing based on the request and response messages exchanged with ECU3 (step S17). Based on the result of the verification processing in step S17, the service verification unit 210b determines whether a service version different from the service version contained in the search message, i.e., a service version that ECU2 can provide, can be provided to ECU3 (step S18). If it is determined that the service can be provided (S8: Yes), the service verification unit 210b permanently changes the service version provided to the client ECU3 (step S19) and ends the processing.

[0119] If the service is determined to be unavailable (S18: No), the service verification unit 210b reverts the service version temporarily changed in step S15 back to the original service version (step S20). Regarding retrieval messages and request messages with different service versions received from ECU3, the client being verified, the service verification unit 210b prohibits the acceptance of such messages (step S21) and terminates the process.

[0120] It should be noted that ECU2 stores in storage unit 22 the identification information of the client ECU3 that has undergone verification processing, the service ID and service version of the service requested by ECU3, and a corresponding table showing the verification results. When the same retrieval message or request message is received from the verified ECU3, it can determine whether to respond to the received message according to this table. In the above flowchart, the permanent change of service version in step S19 and the blocking of subsequent message acceptance in step S21 can be performed by setting appropriate information in this table by ECU2.

[0121] Figure 12 This is a flowchart illustrating the sequence of verification processes performed by the server's ECU2 in this embodiment. Figure 11 The flowchart shown details the processing performed in step S17. In this embodiment, the service verification unit 210b of the processing unit 21 of the ECU2 determines whether a request message has been received from the ECU3 being verified (step S31). If no request message is received (S31: No), the service verification unit 210b waits until a request message is received.

[0122] Upon receiving a request message (S31: Yes), the service verification unit 210b determines whether the received request message is correct (step S32). At this time, the service verification unit 210b determines the correctness of the received request message based on factors such as whether the various ID information contained 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. The service verification unit 210b sends a response message to the ECU3, the source of the request message, to the received request message (step S33). At this time, the response message sent by ECU2 can be a response message containing correct information or a response message containing a specified value for verification purposes. The service verification unit 210b determines whether the ECU3, the object of verification, has finished receiving the required number of request messages (step S34). If the required number of request messages has not been received (S34: No), the service verification unit 210b returns the process to step S31.

[0123] If the predetermined number of request messages has been received (S34: Yes), the service verification unit 210b determines whether the number of valid request messages among the predetermined number of received request messages exceeds a threshold (step S35). If the number of valid request messages exceeds the threshold (S35: Yes), the service verification unit 210b determines that the service can be provided to the verification target ECU3 (step S36), ends the verification process, and returns to normal. Figure 11The flowchart is as follows. If the number of legitimate request messages does not exceed the threshold (S35: No), the service verification unit 210b determines that the service cannot be provided to the verification target ECU3 (step S37), ends the verification process, and returns the process. Figure 11 The flowchart.

[0124] Figure 13 This is a flowchart illustrating the sequence of other processes performed by the server's ECU2 in this embodiment. The application processing unit 210c of the server's ECU2 processing unit 21 in this embodiment determines whether a request message sent by the client's ECU3 has been received (step S51). If a request message has been received (S51: Yes), the application processing unit 210c determines whether the service ID and service version contained in the received request message are consistent with the service ID and service version of the service it provides (step S52). If the service ID and service version are inconsistent (S52: No), the application processing unit 210c returns the processing to step S51.

[0125] If the service ID and service version are consistent (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 information obtained as a result of the information processing to the ECU3, the source of the request message (step S54), and returns the processing to step S51.

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

[0127] Summary

[0128] In this embodiment of the structure described above, the server processing unit 210 of the server ECU2 receives a service retrieval message from the client processing unit 310 of the client ECU3 requesting the service. This retrieval message contains the service ID and service version of the service required by the client processing unit 310. The server processing unit 210 determines whether the service version contained in the received retrieval message matches the service version of the service it provides. If the two service versions match, the server processing unit 210 performs information processing to provide the service to the client processing unit 310. If the two service versions do not match, the server processing unit 210 performs verification processing to determine whether the client processing unit 310 can accept the provision of a service with a different service version. If the verification result indicates that the client processing unit 310 can accept the provision of 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. Therefore, the server processing unit 210 of the server ECU2 can minimize the possibility that the client processing unit 310 cannot accept the service due to inconsistencies in the service version.

[0129] Furthermore, in this embodiment, if the verification process results in the client processing unit 310 being able to accept the provision of services with different service versions, the server processing unit 210 first changes the service version of the service it provides to the service version contained in the search message received from the client processing unit 310. Therefore, service version inconsistencies will no longer occur, and the processing by the client processing unit 310 can proceed smoothly.

[0130] Furthermore, in this embodiment, when verifying whether the client processing unit 310 can accept the provision of services with different service versions, the server processing unit 210 first temporarily changes the service version of its own service to the service version contained in the search message received from the client processing unit 310. Then, based on the changed service version, the server processing unit 210 sends and receives messages related to service provision with the client processing unit 310. Based on the result of this message exchange, the server processing unit 210 verifies whether the client processing unit 310 can accept the provision of services with different service versions. Thus, when the ECU2 changes the service version of its own service to the service version requested by the client processing unit 310 of the ECU3, it can verify whether any adverse conditions have occurred.

[0131] Furthermore, in this embodiment, the server processing unit 210 of ECU2 receives a search message from the client processing unit 310 of ECU3 to check the availability of a desired service. In response to the search message, it sends a provision message containing information such as the service ID and service version of the service it provides. Therefore, when the client processing unit 310 requires a provision message from the server processing unit 210, it can send a search message and receive a provision message.

[0132] Furthermore, in this embodiment, the server processing unit 210 of ECU2 repeatedly sends provision messages containing information such as the service ID and service version of the service it provides at a predetermined period. Therefore, the client processing unit 310, upon receiving the periodically sent provision messages, can determine whether the service it requires has been provided and which server processing unit 210 is providing the service.

[0133] Furthermore, in the vehicle information processing system of this embodiment, the server processing unit 210 is provided in ECU2, and the client processing unit 310 is provided in ECU3. Messages are sent and received between the server processing unit 210 of ECU2 and the ECU3, which has the client processing unit 310. Thus, ECU2 is capable of performing information processing to provide services required by other devices.

[0134] It should be noted that in this embodiment, the ECUs 2 and 3 of the vehicle information processing system are configured to send and receive service-related messages in accordance with the SOME / IP standard. However, this is not a limitation; the system can also be configured to send and receive messages in accordance with standards other than SOME / IP. The technology described in this embodiment is applicable to any system as long as the server and client are systems that send and receive messages.

[0135] (Variation Example 1)

[0136] Figure 14 This is a schematic diagram illustrating an example of the processing performed by the vehicle information processing system of Modification 1. In the vehicle information processing system of Modification 1, when the server ECU2 verifies whether a service version different from the service provided to ECU3 is available, it first sends a verification command message to the ECU3 to be verified. The verification command message is a request message sent by ECU2 to cause ECU3 to perform verification processing, temporarily halting normal information processing. The verification command message may contain information such as the type of message that ECU3 should send and the order in which they should be sent.

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

[0138] ECU3 sends a predetermined number of request messages in accordance with the verification command message. After sending the predetermined number of request messages, ECU3 can resume its temporarily suspended information processing. ECU2 continues verification processing until it receives the predetermined number of request messages from ECU3. Upon receiving the predetermined number of request messages, based on the correctness of each request message, it makes a final determination as to whether ECU3 can accept the provision of services with different service versions. During the verification process, if it is determined that ECU3 can utilize the service version "1.1", ECU2 permanently changes the version of the service provided to ECU3 to "1.2". Then, ECU2 receives the request message from ECU3 with the service version set to "1.2", performs information processing to provide the service version "1.1", and sends a response message containing the processing result with the service version set to "1.2" to ECU3.

[0139] In the vehicle information processing system of the above-described modified example 1, the server processing unit 210 of the server ECU2 sends a verification command message to the client processing unit 310 of the client ECU3, instructing it to send a specified request message. The client processing unit 310 sends a request message based on the verification command message. The server processing unit 210 performs verification based on the request message sent by the client processing unit 310, according to the verification command message. Therefore, the server processing unit 210 can verify with higher accuracy whether the client processing unit 310 can accept the provision of services with different service versions.

[0140] (Variation Example 2)

[0141] Figure 15This is a schematic diagram illustrating the structure of the vehicle information processing system of Modified Example 2. In the vehicle information processing system of Modified Example 2, an ECU 5 includes a client processing unit 310 and a server processing unit 210. The ECU 5 of Modified Example 2 is configured with a processing unit 51, a storage unit 52, and a communication unit 53, etc. The storage unit 52 stores the client program 32a and the server program 22a. In the ECU 5, the processing unit 51 reads and executes the client program 32a stored in the storage unit 52, thus implementing the client processing unit 310 as a software functional unit in the processing unit 51. Similarly, in the ECU 5, the processing unit 51 reads and executes the server program 22a, thus implementing the server processing unit 210 as a software functional unit in the processing unit 51. The processing unit 51 can enable multiple programs to operate in parallel, for example, through time-sharing, allowing the client processing unit 310 and the server processing unit 210 to operate in parallel.

[0142] In ECU5 of Modification 2, the client processing unit 310 and the server processing unit 210 can exchange request and response messages, and exchange retrieval and provision messages without communicating with external devices via 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 retrieve the services required for its own processing from the server processing unit 210, verify whether it can accept services with different versions, and process service requests from the server processing unit 210.

[0143] In the vehicle information processing system of the above-described modified example 2, the ECU5, which includes a server processing unit 210, also has a client processing unit 310. Therefore, the server processing unit 210 of the ECU5 can provide services to the client processing unit 310 inside the device using the same method as when providing services to external devices.

[0144] The various devices in the vehicle-mounted system are equipped with a computer consisting of a microprocessor, ROM, and RAM. The microprocessor and other processing units can handle the... Figures 10-13 The computer program, including some or all of the steps in the sequence diagram or flowchart shown, is read from and executed separately from storage units such as ROM and RAM. These multiple computer programs can be installed from external server devices or the like. Furthermore, these multiple computer programs are distributed in a state where they are stored on recording media such as CD-ROM, DVD-ROM, or semiconductor memory.

[0145] It should be considered that the embodiments disclosed herein are illustrative in all respects and not restrictive. The scope of this disclosure is defined not by the foregoing but by the claims and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0146] Label Explanation

[0147] 1 vehicle

[0148] 2 ECU (Electronic Control Unit)

[0149] 3. 3a~3c ECU

[0150] 4 Repeaters

[0151] 5 ECU

[0152] 21 Processing Department

[0153] 22 Storage Department

[0154] 22a Server Program

[0155] 23 Ministry of Communications

[0156] 31 Processing Department

[0157] 32 Storage Unit

[0158] 32a Client Program

[0159] 33 Ministry of Communications

[0160] 51 Processing Department

[0161] 52 Storage Department

[0162] 53 Ministry of Communications

[0163] Recording media 98, 99

[0164] 210 Server Processing Department

[0165] 210a Service Information Provision Department

[0166] 210b Service Verification Department

[0167] 210c Application Processing Unit

[0168] 310 Client Processing Department

[0169] 310a Service Retrieval Department

[0170] 310b Application Processing Unit.

Claims

1. An in-vehicle information processing apparatus that has a server processing section that performs processing of providing a service in accordance with a request, wherein the server processing section receives a search message that searches for a requested service from a client processing section that requests provision of the service, the search message includes identification information and version information of the requested service, the server processing section determines whether the version information included in the received search message is identical to version information of a service that the server processing section itself provides, the server processing section verifies whether the service with different version information can be provided to the client processing section in a case where it is determined that the two version information are not identical, the server processing section provides the service with different version information to the client processing section in a case where the service with different version information can be provided, the server processing section changes the version information of the service that is to be provided to the client processing section to the version information included in the search message in a case where the service with different version information can be provided, the server processing section temporarily changes the version information of the service that the server processing section itself provides to the version information included in the search message, the server processing section performs transmission and reception of messages with the client processing section based on the temporarily changed version information, and the server processing section verifies whether the service with different version information can be provided based on a result of the transmission and reception of the messages.

2. The in-vehicle information processing apparatus according to claim 1, wherein the server processing section provides a command that causes the client processing section to transmit a prescribed message to the client processing section, the server processing section receives a message that the client processing section transmits in accordance with the command, and the server processing section performs verification based on the received message.

3. The in-vehicle information processing apparatus according to claim 1 or 2, wherein the server processing section receives a search message that the client processing section transmits in order to search for the presence or absence of a service that is desired to be provided, and the server processing section transmits a provision message that includes identification information and version information of a service that the server processing section itself provides as a response to the search message.

4. The in-vehicle information processing apparatus according to claim 1 or 2, wherein the server processing section repeatedly transmits a provision message that includes identification information and version information of a service that the server processing section itself provides at a prescribed period.

5. The in-vehicle information processing apparatus according to claim 1 or 2, wherein the server processing section performs transmission and reception of messages with another apparatus that has the client processing section.

6. The in-vehicle information processing apparatus according to claim 1 or 2, wherein the in-vehicle information processing apparatus has the client processing section.

7. An information processing method that is a method in which a server processing section of an in-vehicle information processing apparatus performs processing of providing a service in accordance with a request from a client processing section, wherein the server processing section receives a search message that searches for a requested service from a client processing section that requests provision of the service, the search message includes identification information and version information of the requested service, and the server processing section determines whether the version information included in the received search message is identical to version information of a service that the server processing section itself provides. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ the server processing section determines whether the version information included in the search message received and the version information of the service provided by itself are consistent, the server processing section verifies whether the service with different version information can be provided to the client processing section when it is determined that the two version information are not consistent, the server processing section provides the service with different version information to the client processing section when it can provide the service with different version information, the server processing section changes the version information of the service to be provided to the client processing section later to the version information included in the search message when it can provide the service with different version information, the server processing section temporarily changes the version information of the service provided by itself to the version information included in the search message, the server processing section performs transmission and reception of messages between the client processing section based on the version information temporarily changed, the server processing section verifies whether the service with different version information can be provided based on the result of the transmission and reception of the messages.

8. A server program product that causes a computer mounted on a vehicle to perform the following processing: receiving a search message that searches for a requested service from a client program that requests provision of the service; the search message includes identification information of the requested service and version information; determining whether the version information included in the search message received and the version information of the service provided by itself are consistent; verifying whether the service with different version information can be provided to the client program when it is determined that the two version information are not consistent; providing the service with different version information to the client program when it can provide the service with different version information, the server processing section changes the version information of the service to be provided to the client processing section later to the version information included in the search message when it can provide the service with different version information, the server processing section temporarily changes the version information of the service provided by itself to the version information included in the search message, the server processing section performs transmission and reception of messages between the client processing section based on the version information temporarily changed, the server processing section verifies whether the service with different version information can be provided based on the result of the transmission and reception of the messages.

Images