Patent Description:
<CIT> discloses a conversion device that converts data of a signal communication ECU (Electronic Control Unit) into data of a service communication ECU based on a conversion map, and conversely converts data of the service communication ECU into data of the signal communication ECU.

Here, when the conversion device detects that at least one of the signal communication ECU and the service communication ECU has been updated, the conversion device automatically updates the conversion map to change the manner of data conversion. Document <NPL> discloses an example of automotive network mapping.

According to the conversion device disclosed in <CIT>, the conversion map is automatically updated based on the similarity of data. When a new service is to be supported, there is a possibility that the conversion map cannot be updated because there is no similar data. Furthermore, there is a problem that the conversion device cannot support a service that issues an operation instruction to the signal communication ECU.

The disclosure has been made in view of such problems of the conventional art. An object of the disclosure is to provide a service proxy device, a service providing system, and a service proxy method that can update a conversion map even when a new service is provided and can handle a service that issues an operation instruction to a signal communication ECU.

A service proxy device according to an aspect of the disclosure is recited in claim <NUM>.

A service providing system according to an aspect of the disclosure includes the client, the server, and the above-mentioned service proxy device.

A service proxy method according to an aspect of the disclosure is recited in claim <NUM>.

According to the disclosure, it is possible to provide a service proxy device, a service providing system, and a service proxy method that can update a conversion map even when a new service is provided and can handle a service that issues an operation instruction to a signal communication ECU.

Hereinafter, a service proxy device, a service providing system, and a service proxy method according to embodiments will be described in detail with reference to the drawings. Note that the dimensional ratio of the drawings is exaggerated for the sake of explanation and may differ from the actual ratio. Further, the same functions and elements are denoted by the same or similar reference numerals, and a description thereof will be omitted as appropriate.

<FIG> is a block diagram showing a configuration of a service providing system according to an embodiment. The service providing system <NUM> includes a client <NUM>, a server <NUM> (ECU: Electronic Control Unit), and a service proxy device <NUM>, which will be described later. In addition, the service providing system <NUM> may include a transfer target ECU <NUM>. For example, the service providing system <NUM> is mounted on a vehicle.

The client <NUM> and the service proxy device <NUM> are connected to each other so that data can be transmitted and received via a first communication. For example, the first communication is a service communication. The service communication is a communication method for transmitting and receiving data between a client and a server. An example of a network that realizes the service communication is the Ethernet.

The server <NUM> and the service proxy device <NUM> are connected to each other so that data can be transmitted and received by a second communication. The transfer target ECU <NUM> and the service proxy device <NUM> are connected to each other so that data can be transmitted and received by the second communication. For example, the second communication is a signal communication. The signal communication is a communication method for broadcasting data to ECUs (including the server <NUM> and the transfer target ECU <NUM>) on a network. A CAN (Controller Area Network) bus is an example of a network that realizes the signal communication. <FIG> shows a state in which a CAN bus A is provided between the server <NUM> and the service proxy device <NUM>, and a CAN bus B is provided between the transfer target ECU <NUM> and the service proxy device <NUM>.

<FIG> is a block diagram showing a configuration of a service proxy device according to the embodiment. The service proxy device <NUM> includes a first communicator <NUM>, a second communicator <NUM>, a database <NUM>, and a controller <NUM>. The first communicator <NUM> is connected to the client <NUM> via the first communication. The second communicator <NUM> is connected to the server <NUM> and the transfer target ECU <NUM> via the second communication.

The database <NUM> stores a map table that associates functions with services and identifies the server <NUM> that has the functions and the client <NUM> that requests the service. <FIG> is a diagram showing an example of a map table. As shown in <FIG>, the map table associates a function ID that identifies the function with a service ID that identifies the service. Furthermore, the map table may associate information that identifies the type of service with each service ID.

The map table may also associate, for each function ID, an ECU ID that identifies the server <NUM> having the function identified by the function ID. Furthermore, the map table may associate, for each service ID, a client ID that identifies the client <NUM> that requests the service ID.

The database <NUM> may also store a server management table that associates the function with the server <NUM> and identifies whether the function in the server <NUM> is available. <FIG> illustrates an example of a server management table. The server management table associates information that identifies whether the function in the server <NUM> is available with an ECU ID that identifies the server <NUM>. The server management table may also associate a message ID that identifies a message transmitted or received in the function with the function ID that identifies the function. The server management table may also associate, for each message ID, a signal ID that indicates a transfer destination of the message identified by the message ID, and a signal value. Here, the signal value corresponds to the execution result of the function in the server <NUM>.

The database <NUM> may also store a client management table that identifies the service requested by the client <NUM> by associating the client <NUM> with the service. <FIG> illustrates an example of a client management table. The client management table associates the service ID that identifies the service requested by the client <NUM> with the client ID that identifies the client <NUM>. Additionally, the client management table may associate connection destination information required for service communication with the client <NUM> with the client ID. For example, the client management table may associate a MAC address, an IP address, a port number, etc. as the connection destination information.

The controller <NUM> is a general-purpose computer equipped with a CPU (Central Processing Unit), a memory, a storage device, an input/output unit, etc. A computer program for functioning as a part of the service proxy device <NUM> is installed in the controller <NUM>. The computer program may be stored in a recording medium that can be read and written by a computer. The computer program may be capable of being distributed through a network.

The controller <NUM> receives a service execution instruction requesting execution of the service from the client <NUM> via the first communicator <NUM>. The controller <NUM> receives the execution result of the function associated with the service from the server <NUM> via the second communicator <NUM>. Then, the controller <NUM> transmits the execution result of the function associated with the service to the client <NUM> via the first communicator <NUM> based on the service execution instruction and the map table.

Furthermore, the controller <NUM> may transmit a function check instruction for checking whether or not the function is available to the server <NUM> via the second communicator <NUM> and may receive answer data transmitted from the server <NUM> based on the function check instruction. The controller <NUM> may then update the server management table based on the received answer data. More specifically, the controller <NUM> updates information identifying whether or not a function is available to the server <NUM>, which is stored in the server management table, based on the answer data.

The controller <NUM> may determine whether or not the function associated with the service related to the service execution instruction is available based on the server management table, and may transmit the execution result to the client <NUM> when it is determined that the function is available. The controller <NUM> may also receive the execution result from the server <NUM> via the first communicator <NUM> and may update the server management table by associating the function with the execution result.

The controller <NUM> may send a function execution instruction to the server <NUM> having the function, requesting the execution of the function associated with the service related to the service execution instruction, and may receive the execution result based on the function execution instruction from the server <NUM>.

Furthermore, the controller <NUM> may receive a service check instruction for checking the presence or absence of the service from the client <NUM> via the first communicator <NUM>. The controller <NUM> may then determine whether or not the function corresponding to the service exists based on the service check instruction and the map table. If the function corresponding to the service exists, the controller <NUM> may update the client management table and the map table based on the service check instruction.

In addition, the controller <NUM> may transfer a message received from the server <NUM> via the second communicator <NUM> to the transfer target ECU <NUM> identified by the signal ID indicating the transfer destination of the message. The controller <NUM> may update the server management table based on the message received from the server <NUM>.

<FIG> is a sequence chart illustrating a process at the time of startup. As shown in <FIG>, the service proxy device <NUM> starts the process included in the range RG1 based on a start-up instruction from the user.

More specifically, the service proxy device <NUM> transmits the function check instruction to server <NUM> to check the functions possessed by the server <NUM> ("Check possessed functions"). When the server <NUM> receives the function check instruction, the server <NUM> transmits the answer data identifying the functions possessed by the server <NUM> itself to the service proxy device <NUM> ("Answer possessed functions"). The service proxy device <NUM> updates the server management table based on the answer data ("Update server management table").

The processes included in the above-mentioned range RG1 are executed for each server <NUM> connected to the service proxy device <NUM>.

<FIG> is a flowchart illustrating a process at the time of startup. In step S101, the controller <NUM> clears the information on "availability of function" contained in the server management table.

In step S103, the controller <NUM> selects one server <NUM> from among the unselected servers <NUM>.

In step S105, the controller <NUM> checks the possessed functions of the selected server <NUM>. Specifically, the controller <NUM> transmits the function check instruction to the selected server <NUM> via the second communicator <NUM>. Thereafter, the controller <NUM> receives the answer data from the selected server <NUM>.

In step S107, the controller <NUM> sets the information on "availability of function" that identifies whether or not the function held by the selected server <NUM> can be used, based on the answer data.

In step S109, the controller <NUM> determines whether or not there is an unselected server <NUM>. If there is an unselected server <NUM> (YES in step S109), the process returns to step S103.

If there is no unselected server <NUM> (NO in step S109), service proxy device <NUM> ends the process at the time of startup.

<FIG> is a sequence chart illustrating a process for responding to a service inquiry. As shown in <FIG>, the service proxy device <NUM> receives the service check instruction for checking the presence or absence of the service from the client ("Check availability of service"). The service proxy device <NUM> determines whether or not the function corresponding to the service exists based on the service check instruction and the map table ("Check possessed service using map table"). The service proxy device <NUM> then transmits the determination result of whether or not the function corresponding to the service exists to the client <NUM> ("Answer possessed service").

<FIG> is a flowchart illustrating a process for responding to a service inquiry. In step S201, the controller <NUM> determines whether or not the function corresponding to the service exists based on the service check instruction and the map table.

If there is no function corresponding to the service (NO in step S201), the service proxy device <NUM> ends the process for responding to the service inquiry.

If the function corresponding to the service exists (YES in step S201), in step S203, the controller <NUM> transmits a response to the client <NUM> via the first communicator <NUM> indicating that the function corresponding to the service exists.

In step S205, the controller <NUM> updates the client management table based on the service check instruction. Specifically, the controller <NUM> associates the service ID that identifies the service requested by the client <NUM> with the client ID that identifies the client <NUM>.

In step S207, the controller <NUM> updates the map table based on the service check instruction. Specifically, the controller <NUM> associates the client ID that identifies the client <NUM> that requests the service ID for each service ID. Thereafter, the service proxy device <NUM> ends the process for responding to the service inquiry.

The process for responding to the service inquiry shown in <FIG> may be repeatedly executed after the process at the time of startup shown in <FIG>.

<FIG> is a sequence chart illustrating a normal process. As shown in <FIG>, the service proxy device <NUM> receives a message transmitted from the server <NUM> ("Transfer message periodically"), and then transfers the received message to the transfer target ECU <NUM> ("Forward message"). Then, the service proxy device <NUM> updates the server management table based on the received message ("Update server management table").

<FIG> is a flowchart illustrating a normal process. In step S301, the controller <NUM> determines whether or not the message has been received from the server <NUM>.

If no message has been received (NO in step S301), the process returns to step S301.

When a message has been received (YES in step S301), in step S303, the controller <NUM> forwards the received message to the transfer target ECU <NUM> via the second communicator <NUM>.

In step S305, the controller <NUM> updates the server management table based on the received message. Specifically, the controller <NUM> associates the function ID that identifies the function with the message ID that identifies the message sent or received in the function. Additionally, the controller <NUM> may associate the signal ID and the signal value with each message ID, wherein the signal ID indicates the transfer destination of the message identified by the message ID. Thereafter, the service proxy device <NUM> ends the normal process.

The normal process shown in <FIG> may be repeatedly executed after the process at the time of startup shown in <FIG>.

<FIG> is a sequence chart illustrating a process during service proxy. As shown in <FIG>, the service proxy device <NUM> receives the service execution instruction sent from the client <NUM> ("Request service"). Based on the service execution instruction, the service proxy device <NUM> identifies the function associated with the service identified by the service execution instruction and the server <NUM> having the function ("Identify function and server").

If the execution result is registered in the map data, service proxy device <NUM> performs process in the range RG2. Specifically, the service proxy device <NUM> transmits the execution result to client <NUM> ("Reply execution result").

If the execution result is not registered in the map data and it is necessary to obtain the execution result, the service proxy device <NUM> performs process in the range RG3.

Specifically, the service proxy device <NUM> transmits the function execution instruction to the server <NUM> ("Instruct function execution"). The server <NUM>, which has received the function execution instruction, executes the function identified by the function execution instruction and transmits the execution result to the service proxy device <NUM> ("execution result"). Then, the service proxy device <NUM> transmits the execution result to the client <NUM> ("Reply execution result").

<FIG> is a flowchart illustrating a process during service proxy. <FIG> is a flowchart illustrating an acquisition process. <FIG> is a flowchart illustrating an execution process.

In step S401, the controller <NUM> determines whether or not the service request has been made by the client <NUM>. Specifically, the controller <NUM> determines whether or not the service execution instruction has been received from the client <NUM>.

If there is no service request (NO in step S401), the process returns to step S401.

If the service request has been received (YES in step S401), the controller <NUM> executes an acquisition process in step S403. The details of the acquisition process will be described with reference to <FIG>.

In step S405, the controller <NUM> executes an execution process. The details of the execution process will be described with reference to <FIG>.

Thereafter, the service proxy device <NUM> ends the process during service proxy.

<FIG> is a flowchart illustrating an acquisition process. In step S501, the controller <NUM> determines whether or not the service identified by the service execution instruction is registered. Specifically, the controller <NUM> determines whether or not the service is registered in the map table.

If the service is not registered (NO in step S501), the acquisition process is terminated. On the other hand, if the service is registered (YES in step S501), in step S503, the controller <NUM> determines whether or not the client is registered in association with the service. Specifically, the controller <NUM> refers to the map table and determines whether or not the client that transmitted the service execution instruction is associated with the service identified by the service execution instruction.

If the client is not registered (NO in step S503), the acquisition process ends. On the other hand, if the client is registered (YES in step S503), in step S505, the controller <NUM> refers to the map table to identify the function and server corresponding to the service. Then, the acquisition process ends.

<FIG> is a flowchart illustrating an execution process. In step S601, the controller <NUM> selects one server <NUM> from among the servers <NUM> that have not been selected.

In step S603, the controller <NUM> determines whether the selected server is the server <NUM> identified in the acquisition process.

If the selected server is not the identified server <NUM> (NO in step S603), the process proceeds to step S621.

On the other hand, if the selected server is the identified server <NUM> (YES in step S603), in step S605, the controller <NUM> selects one function from among the unselected functions.

In step S607, the controller <NUM> determines whether the selected function is the function identified in the acquisition process.

If the selected function is not the identified function (NO in step S607), the process proceeds to step S619.

On the other hand, if the selected function is the identified function (YES in step S607), in step S609, the controller <NUM> determines whether or not the identified function is available in the identified server <NUM>. Specifically, the controller <NUM> refers to the server management table to determine whether or not the function is available.

If the function is not available (NO in step S609), the process proceeds to step S619.

On the other hand, if the function is available (YES in step S609), in step S611, the controller <NUM> determines whether or not there is the execution result that takes into consideration the identified function in the identified server <NUM>. Specifically, the controller <NUM> refers to the server management table and determines whether or not the execution result is registered.

If there is the execution result (YES in step S611), the process proceeds to step S617. On the other hand, if there is no execution result (NO in step S611), the controller <NUM> transmits the function execution instruction to the identified server <NUM> in step S613.

Thereafter, in step S615, the controller <NUM> receives the execution result from the server <NUM>.

In step S617, the controller <NUM> transmits the execution result to the client <NUM>.

In step S619, the controller <NUM> determines whether or not there is the unselected function. If there is the unselected function (YES in step S619), the process returns to step S605.

If there is no unselected function (NO in step S619), in step S621, the controller <NUM> determines whether or not there is the unselected server <NUM>. If there is the unselected server <NUM> (YES in step S621), the process returns to step S601.

If there is no unselected server <NUM> (NO in step S621), the service proxy device <NUM> ends the execution process.

The process during service proxy shown in <FIG> may be repeatedly executed after the process at the time of startup shown in <FIG>.

As explained in detail above, a service proxy device according to the present embodiment includes a first communicator connected to a client via a first communication, a second communicator connected to a server via a second communication, a database, and a controller. The database is configured to store a map table that associates functions with services and identifies a server having the function and a client requesting the service. The controller is configured to receive a service execution instruction from the client via the first communicator, which requests the execution of the service. The controller is configured to receive an execution result of the function associated with the service from the server via the second communicator. The controller is configured to transmit the execution result of the function associated with the service to the client via the first communicator based on the service execution instruction and the map table.

This allows a conversion map to be updated when supporting new services, and it possible to support services that provide operational instructions in signal communication. Also, communication is possible across different communication methods between clients and servers, making it possible to provide a variety of services without changing the communication method of existing servers. As a result, it is possible to reduce the cost and workload during design and manufacturing of a system in which communication occurs between clients and servers. Furthermore, user convenience is improved.

Further, in the service proxy device according to the present embodiment, the database may store a server management table that identifies whether the function is available or not in association with the server. Via the second communicator, the controller may transmit a function check instruction to the server to check whether the function is available, and may receive an answer data transmitted from the server based on the function check instruction. The controller may update the server management table based on the answer data. This allows the service proxy device to centrally manage functions available on the server, and makes it easy to determine whether the service can be provided.

Furthermore, in the service proxy device according to the present embodiment, the controller may determine whether the function associated with the service related to the service execution instruction is available based on the server management table. The controller may transmit the execution result to the client in a case of determining that the function is available. This allows the client to be notified of whether or not the requested service can be provided using the server connected to the service proxy device. As a result, user convenience is improved.

Further, in the service proxy device according to the present embodiment, the controller may receive the execution result from the server via the first communicator, and may update the server management table by associating the function with the execution result. This allows the service proxy device to centrally manage the execution results of the function on the server. For example, for a function that is periodically executed on the server, the execution results periodically transmitted can be centrally managed by the service proxy device.

Furthermore, in the service proxy device according to the present embodiment, the controller may transmit a function execution instruction to the server that has the function, the function execution instruction requesting execution of the function associated with the service related to the service execution instruction. The controller may receive, from the server, the execution result based on the function execution instruction. This allows the function related to the requested service to be executed in the server, and the requested service to be provided. As a result, user convenience is improved.

Further, in the service proxy device according to the present embodiment, the database may store a client management table that identifies the service requested by the client in association with the client. The controller may receive a service check instruction for checking presence or absence of the service from the client via the first communicator. The controller may determine whether the function corresponding to the service exists based on the service check instruction and the map table. The controller may update the client management table and the map table based on the service check instruction if the function corresponding to the service exists. This allows the service requested by the client to be linked with the function provided by the server and managed in a centralized manner. As a result, it becomes possible to easily determine whether or not a service can be provided.

A service providing system according to the present embodiment includes the client, the server, and the above-mentioned service proxy device. This allows a conversion map to be updated when supporting new services, and it possible to support services that provide operational instructions in signal communication.

A service proxy method according to the present embodiment, relates to a service proxy device including a first communicator connected to a client via a first communication, a second communicator connected to a server via a second communication, a database, and a controller. The database is configured to store a map table that associates functions with services and identifies a server having the function and a client requesting the service. The controller is configured to receive a service execution instruction from the client via the first communicator, which requests the execution of the service. The controller is configured to receive an execution result of the function associated with the service from the server via the second communicator. The controller is configured to transmit the execution result of the function associated with the service to the client via the first communicator based on the service execution instruction and the map table.

This allows a conversion map to be updated when supporting new services, and it possible to support services that provide operational instructions in signal communication.

Respective functions described in the above embodiment may be implemented by one or plural processing circuits. The processing circuits include programmed processors, electrical circuits, etc., as well as devices such as application specific integrated circuits (ASIC) and circuit components arranged to perform the described functions, etc..

Claim 1:
A service proxy device (<NUM>) comprising
a first communicator (<NUM>) connected to a client (<NUM>) via a first communication,
a second communicator (<NUM>) connected to a server (<NUM>) via a second communication,
a database (<NUM>), and
a controller (<NUM>), wherein
the database (<NUM>) is configured to
store a map table that associates functions with services and identifies the server (<NUM>) having the function and the client (<NUM>) requesting the service,
the controller (<NUM>) is configured to
receive, via the first communicator (<NUM>), a service execution instruction requesting execution of the service from the client (<NUM>),
transmit a function execution instruction to the server (<NUM>) that has the function, the function execution instruction requesting execution of the function associated with the service related to the service execution instruction, and
receive, from the server (<NUM>), via the second communicator (<NUM>), the execution result of the function, based on the function execution instruction, and
transmit, via the first communicator (<NUM>), the execution result of the function associated with the service based on the service execution instruction and the map table, to the client (<NUM>), wherein
the database (<NUM>) is configured to
store a server management table that identifies whether the function is available or not in association with the server (<NUM>), and
store a client management table that identifies the service requested by the client (<NUM>) in association with the client (<NUM>),
the controller (<NUM>) is configured to, via the second communicator (<NUM>),
transmit a function check instruction to the server (<NUM>) to check whether the function is available,
receive an answer data transmitted from the server (<NUM>) based on the function check instruction, and
update the server management table based on the answer data,
the controller (<NUM>) is further configured to
receive a service check instruction for checking presence or absence of the service from the client (<NUM>) via the first communicator (<NUM>),
determine whether the function corresponding to the service exists based on the service check instruction and the map table, and
update the client management table and the map table based on the service check instruction if the function corresponding to the service exists.