JP2020141352A - Control device and communication system - Google Patents

Abstract

To easily verify that a new service equivalent to updates or additions is working properly on a network.SOLUTION: A control device includes a plurality of controllers having services and a network, and each of the plurality of controllers includes a control unit that realizes a desired operation by combining services by performing communication control between the plurality of services. The control unit transitions the process state for starting the service from the normal mode to the diagnostic mode when performing the operation check of whether the new service normally operates, and performs the operation check by identifying a provider service that provides the service for the new service and the destination service that uses the new service, and performing communication control between the plurality of services consisting of the new service, the provider service, and the destination service in the diagnostic mode.SELECTED DRAWING: Figure 1

Description

The present invention relates to a control device and a communication system that execute an operation check of a new service corresponding to an update or a new addition.

In recent years, in a system in which a plurality of control devices are connected by a network to perform communication, each control device provides a service, and a desired operation is realized by a combination of the services. Such a system is applied to automobiles as an example. Conventionally, the service of the control device mounted on the automobile has not been changed after the automobile is manufactured. However, automobiles are now connected to external networks, and services can be changed and added even after the automobile is manufactured.

In such a situation, it is possible to test the service that was previously performed at the time of manufacturing the car for the service newly added after the car is manufactured to verify that the service operates normally. is necessary.

In order to perform such verification, there is a prior art technique of identifying a new service, performing a test on the new service, and transmitting the test result to an external device before providing a new service (for example, a patent). Reference 1). In Patent Document 1, the external device determines the permission to use the new service based on the received test result. Further, the external device enables the use of the new service when the permission is obtained, thereby ensuring the situation in which the newly added service operates normally.

Japanese Unexamined Patent Publication No. 2016-163244

However, the prior art has the following problems.
In Patent Document 1, each service is configured based on SOA (Service Oriented Architecture: Service Oriented Architecture). In addition, test messages used for testing are also provided with a test service, which is also based on SOA.

That is, in Patent Document 1, it is necessary to prepare a new service for testing and a new service interface in order to carry out a test for ensuring that the service to be added operates normally. Therefore, in Patent Document 1, in order to carry out the test of the new service, the complexity of the system increases, and it is difficult to easily confirm that the new service operates normally on the network.

The present invention has been made to solve the above-mentioned problems, and a control device and communication that can easily confirm that a new service corresponding to an update or a new addition operates normally on a network. The purpose is to get the system.

The control device according to the present invention includes a plurality of controllers having a service which is a software element for processing a desired function, and a network for connecting the plurality of controllers to each other, each of the plurality of controllers via a network. The control unit includes a control unit that realizes a desired operation by combining services by performing communication control between a plurality of services, and the control unit operates whether or not a new service corresponding to an update or a new addition operates normally. When executing the confirmation, the process state for starting the service is changed from the normal mode for executing the normal operation of the new service to the diagnostic mode for limiting the normal operation and executing the operation confirmation of the new service, and the new service is executed. The provider service that provides the service to the user and the user service that uses the new service are specified, and in the diagnostic mode, communication control is performed between the new service, the provider service, and multiple services composed of the user service. By performing the above, the operation check is executed in order to realize the desired operation by the combination of services.

Further, the communication system according to the present invention includes a control device according to the present invention and a server that provides a new service to the control device, and one of a plurality of controllers included in the control device is a controller. , It is a gateway ECU that is communicably connected to the server via a public communication line and controls the control device in an integrated manner. The gateway ECU executes the operation check regarding the new service acquired from the server by the control device and operates. When the test result indicating that the calculation result and the expected value match is obtained as the test result by executing the confirmation, the process state is changed from the diagnostic mode to the normal mode, and the new service is used. It starts normal operation.

According to the present invention, it is possible to obtain a control device and a communication system that can easily confirm that the service to be updated or the service to be newly added operates normally on the network.

It is a figure which shows the outline of the communication system which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the gateway ECU which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the domain controller ECU which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the local ECU which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the server which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the service package which concerns on Embodiment 1 of this invention. It is a figure which showed the structure of the sensing service package which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the actuator service package which concerns on Embodiment 1 of this invention. It is a sequence diagram which showed the series operation of the communication system which concerns on Embodiment 1 of this invention. It is a sequence diagram which showed the series operation of the communication system which concerns on Embodiment 1 of this invention. It is a sequence diagram which showed the series operation of the communication system which concerns on Embodiment 1 of this invention. It is a sequence diagram which showed the series operation of the communication system which concerns on Embodiment 1 of this invention. It is a figure which shows the specific example of the manifest in Embodiment 1 of this invention. It is a figure which shows the structure of the test data generation service which becomes the input when the new service is tested in Embodiment 1 of this invention. It is a figure which shows the structure of the test data generation service which becomes the input when the new service is tested in Embodiment 1 of this invention. It is a figure which shows the structure of the service which determines the test result from the output result at the time of testing the new service in Embodiment 1 of this invention. It is a figure which shows the structure of the service which determines the test result from the output result at the time of testing the new service in Embodiment 1 of this invention. It is a figure which shows the structure of the test management service package which manages the test data generation service and the test result determination service in Embodiment 1 of this invention. It is a figure which shows the structure when the function of each control device in Embodiment 1 of this invention is realized by hardware.

Hereinafter, preferred embodiments of the control device and communication system of the present invention will be described with reference to the drawings.
In the following, as an example of a communication system in which a plurality of control devices are connected by a network, a communication system in which a plurality of control devices mounted on a vehicle are connected by an in-vehicle network will be described.

Embodiment 1.
FIG. 1 is a diagram showing an outline of a communication system according to a first embodiment of the present invention. First, the overall structure of the communication system will be described with reference to FIG.

As shown in FIG. 1, the communication system is composed of an in-vehicle network 100 and an external network 200. The in-vehicle network 100 includes a gateway ECU 110, domain controllers ECUs 120 and 130, and local ECUs 140, 150, 160 and 170 as a plurality of control devices. Further, the external network 200 includes a server 210 and a public communication line 220.

Here, the ECU is an abbreviation for Electronic Control Unit (electronic control unit), and as will be described later, it corresponds to a controller provided with a control unit that controls communication between mutual ECUs.

The gateway ECU 110 is connected to the public communication line 220 by using wireless communication such as Wi-fi (registered trademark), and is connected to the server 210 via the public communication line 220.

In the in-vehicle network 100, the gateway ECU 110, the domain controller ECUs 120 and 130, and the devices of the local ECUs 140, 150, 160 and 170 are connected to each other by the communication bus 180. As the communication bus 180, a network such as Ethernet (registered trademark) or CAN (Control Area Network) can be used.

Therefore, the gateway ECU 110 is communicably connected to the server 210 via the public communication line 220, and controls the domain controllers ECUs 120 and 130 and the local ECUs 140, 150, 160 and 170 in an integrated manner.

FIG. 2 is a diagram showing a configuration of a gateway ECU 110 according to a first embodiment of the present invention. The gateway ECU 110 includes hardware of a processor 111, a timer 112, a communication interface 113, an external communication interface 114, an auxiliary storage device 115, and a memory 116. These hardware pieces in the gateway ECU 110 are connected to each other via a signal line.

The processor 111 is an IC (Integrated Circuit) that performs arithmetic processing, and controls other hardware. For example, the processor 111 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or a GPU (Graphics Processing Unit).

The timer 112 counts the clock signal from the oscillator circuit. The oscillator circuit is, for example, a crystal oscillator or a ceramic oscillator. The communication interface 113 is, for example, Ethernet or CAN. The external communication interface 114 is, for example, Wi-fi.

The auxiliary storage device 115 is a non-volatile storage device. For example, the auxiliary storage device 115 is a ROM (Read Only Memory), an HDD (Hard Disk Drive), or a flash memory. The data stored in the auxiliary storage device 115 is loaded into the memory 116 as needed.

The memory 116 is a volatile storage device. The memory 116 is also referred to as a main storage device or a main memory. For example, the memory 116 is a RAM (Random Access Memory). The data stored in the memory 116 is stored in the auxiliary storage device 115 as needed.

FIG. 3 is a diagram showing a configuration of domain controllers ECUs 120 and 130 according to the first embodiment of the present invention. The domain controller ECU 120 includes hardware of a processor 121, a timer 122, a communication interface 123, an auxiliary storage device 125, and a memory 126. These hardware pieces in the domain controller ECU 120 are connected to each other via a signal line.

Similarly, the domain controller ECU 130 is configured to include the hardware of the processor 131, the timer 132, the communication interface 133, the auxiliary storage device 135, and the memory 136. These hardware pieces in the domain controller ECU 130 are connected to each other via a signal line.

Processors 121, 131, timers 122, 132, communication interfaces 123, 133, auxiliary storage devices 125, 135, and memory 126, 136 are associated with processor 111, timer 112, communication interface 113, auxiliary storage device 115, and memory 116, respectively. It is similar.

FIG. 4 is a diagram showing a configuration of local ECUs 140, 150, 160, 170 according to the first embodiment of the present invention. The local ECU 140 is configured to include hardware of a processor 141, a timer 142, a communication interface 143, an auxiliary storage device 145, and a memory 146. These hardware pieces in the local ECU 140 are connected to each other via a signal line.

Similarly, the local ECU 150 is configured to include hardware for a processor 151, a timer 152, a communication interface 153, an auxiliary storage device 155, and a memory 156. These hardware pieces in the local ECU 150 are connected to each other via a signal line.

Similarly, the local ECU 160 is configured to include hardware for a processor 161, a timer 162, a communication interface 163, an auxiliary storage device 165, and a memory 166. These hardware pieces in the local ECU 160 are connected to each other via a signal line.

Similarly, the local ECU 170 is configured to include hardware of a processor 171, a timer 172, a communication interface 173, an auxiliary storage device 175, and a memory 176. These hardware pieces in the local ECU 170 are connected to each other via a signal line.

Processors 141, 151, 161 and 171, timers 142, 152, 162, 172, communication interfaces 143, 153, 163, 173, auxiliary storage devices 145, 155, 165, 175, and memories 146, 156, 166, 176 are It is the same as the processor 111, the timer 112, the communication interface 113, the auxiliary storage device 115, and the memory 116, respectively.

FIG. 5 is a diagram showing a configuration of a server 210 according to the first embodiment of the present invention. The server 210 includes hardware of a processor 211, a timer 212, an external communication interface 214, an auxiliary storage device 215, and a memory 216. These hardware pieces in the server 210 are connected to each other via a signal line.

The processor 211, timer 212, external communication interface 214, auxiliary storage 215, and memory 216 are similar to the processor 111, timer 112, external communication interface 114, auxiliary storage 115, and memory 116, respectively.

Next, the functions according to the respective configurations of FIGS. 2 to 5 will be described. In the gateway ECU 110 of FIG. 2, the processor 111 has a software element of the control unit 311. Here, the software element is an element realized by software.

The auxiliary storage device 115 stores a program that functions as the control unit 311. The program is loaded into memory 116 and executed by processor 111. Further, the auxiliary storage device 115 stores an OS (Operating System). At least part of the OS is loaded into memory 116 and executed by processor 111.

The data obtained by executing the program is stored in a storage device such as an auxiliary storage device 115, a memory 116, or a register or cache memory in the processor 111.

The timer 112 functions as a counter unit 312 that counts the clock signal and converts it into time. The memory 116 functions as a storage unit 316 for storing data. However, another storage device may function as the storage unit 316 instead of the memory 116 or together with the memory 116.

The communication interface 113 has a communication unit 313. The communication unit 313 has a function of receiving a message flowing on the communication bus, converting an analog signal into a digital signal, and acquiring data. Further, the communication unit 313 has a function of converting a digital signal into an analog signal and transmitting a message conforming to a specified protocol on the communication bus. The external communication interface 114 has an external communication unit 314 that functions as wireless communication.

The functions shown in the domain controllers ECUs 120 and 130 in FIG. 3, the functions shown in the local ECUs 140, 150, 160 and 170 in FIG. 4 and the functions shown in the server 210 in FIG. 5 are performed by the gateway ECU 110 in FIG. The functions are the same as those of 31 to 14 and 316.

Next, the service package will be described. FIG. 6 is a diagram showing the configuration of the service package 400 according to the first embodiment of the present invention. The service package 400 is composed of a service 401, a provide service interface 402, a request service interface 403, and a manifest 404.

The service 401 is a part that processes a desired function and is a software element. The program that provides the service 401 is configured based on the SOA (Service Oriented Architecture). Here, the SOA is based on a method in which a service is defined by two types, a service provider and a service user, and each service is searched for and used on a network.

Further, the service 401 is registered in the service registry. The service registry performs service provision registration from the service provider and service usage registration from the service user. Then, when the service to be provided and the service to be used exist in the service registry, the service registry establishes communication between the services.

One or more of these service registries exist in any ECU on the vehicle-mounted network 100. In the first embodiment, it is assumed that each ECU has a service registry. Further, in the first embodiment, the service registry of each ECU excluding the gateway ECU 110 is referred to as a local service registry, and the service registry of the gateway ECU 110 is referred to as a global service registry.

Further, the management of the service registry is performed by the control unit provided in each ECU. Further, for example, data handled by the service registry such as service registration information is stored in a memory or an auxiliary storage device on each ECU.

A plurality of services similar to the service 401 are arranged in each ECU on the vehicle-mounted network 100. By linking these services, the vehicle realizes the desired operation. However, in order to realize the desired operation, at least one service is required.

Returning to FIG. 6, the description will be continued. The provide service interface 402 is an interface implemented when the service 401 is a service provider. On the other hand, the request service interface 403 is an interface implemented when the service 401 is a service user.

However, when the service 401 is a service provider and a service user, each of the provide service interface 402 and the request service interface 403 is implemented. Further, the provide service interface 402 and the request service interface 403 need not be limited to one for each service 401, and a plurality of interfaces may be implemented.

By connecting the provide service interface 402 and the request service interface 403 to the above-mentioned communication interface, for example, Ethernet, the provider service interface 402 and the request service interface 403 are connected to the vehicle-mounted network 100, and messages can be exchanged between ECUs. The manifest 404 describes the conditions under which the service 401 is started.

When the service 401 is executed, the manifest 404 is read by the service execution management function provided in the control unit of the ECU in which the service 401 is arranged. The service execution management function determines the start of the service 401 based on the conditions described in the manifest 404.

For example, it is assumed that the manifest 404 describes the state of the ECU as "Running" and the service required for starting the service 401 as "service A". In this case, the service execution management function monitors the current state of the ECU and the execution state of the service A, and when all the conditions are met, the service 401 is started. Further, if any of the above-mentioned conditions does not match during the startup of the service 401, the service execution management function stops the service 401.

Here, the configuration of the newly added service is shown in FIG. 6 described above. That is, it is assumed that the newly added service is composed of the service package 400, the service 401, the provide service interface 402, the request service interface 403, and the manifest 404.

Hereinafter, the service corresponding to the update or new addition will be referred to as the new service 401. Further, in the first embodiment, the new service 401 is added to the domain controller ECU 120.

It is assumed that the service used by the new service 401 is located on the local ECU 140. Further, it is assumed that the service using the new service 401 is arranged on the local ECU 160.

The service used by the new service 401 is, for example, a sensing service package 410 that acquires sensor information. FIG. 7A is a diagram showing the configuration of the sensing service package 410 according to the first embodiment of the present invention. The sensing service package 410 is composed of a sensing service 411, a provide service interface 412, and a manifest 414.

The sensing service 411 provides a service to the new service 401 via its own provide service interface 412 and the request service interface 403 of the new service 401.

On the other hand, the service that uses the new service 401 is, for example, the actuator service package 420 that controls the actuator. FIG. 7B is a diagram showing the configuration of the actuator service package 420 according to the first embodiment of the present invention. The actuator service package 420 is composed of an actuator service 421, a request service interface 423, and a manifest 424.

The actuator service 421 receives the provision of the new service 401 via its own request service interface 423 and the provide service interface 402 of the new service 401.

Next, the operation of the communication system according to the first embodiment shown in FIG. 1 will be described in detail. 8A to 8D are sequence diagrams showing a series of operations of the communication system according to the first embodiment of the present invention. The process of FIG. 8A is connected by "C1" to the process of FIG. 8B, the process of FIG. 8B is connected by "C2" to the process of FIG. A series of operations is shown by the whole of FIGS. 8A to 8D.

First, when the car is started by the user 900, the services arranged in each EUC are started. Step S101 and step S102 shown in FIG. 8A are processes after the service is started.

When the service is activated, in step S101, the local ECU 140 in which the service used by the new service 401 is arranged performs service registration. Specifically, the sensing service 411 that provides the service to the new service 401 is registered as a service provider service in the global service registry and each local service registry.

On the other hand, in step S102, the local ECU 160 in which the service using the new service 401 is arranged makes a service request. Specifically, the actuator service 421 that uses the new service 401 is registered in the global service registry and each local service registry as a service use destination service.

Originally, the gateway ECU 110, the domain controller ECU 120, 130, the local ECU 150, 160, and other services other than the sensing service 411 and the actuator service 421 also start the service provision registration and usage registration. However, since it is unnecessary in the specific examples of FIGS. 8A to 8D, the description thereof will be omitted.

Further, when data is exchanged between the local ECUs 140 and 150 under the domain controller ECU 120 and the gateway ECU 110 or the domain controller ECU 130, the domain controller ECU 120 performs a routing process.

Similarly, when exchanging data between the local ECUs 160 and 170 under the domain controller ECU 130 and the gateway ECU 110 or the domain controller ECU 120, the domain controller ECU 130 performs a routing process. However, the description of this routing process will be omitted.

Next, in step S201, the user 900 selects a service to be added to the vehicle. In the first embodiment, the following description will be given assuming that the new service 401 is selected. However, the service shown here may be a service newly added to the automobile, or may be a service that updates a service already installed in the automobile.

As a method for the user 900 to select a service, for example, it is conceivable that the gateway ECU 110 is provided with an output device such as a display, the service that can be added is displayed on the display, and the user 900 selects the service.

Next, in step S202, the gateway ECU 110 transmits an acquisition request regarding the service package of the service selected by the user 900 to the server 210, and inquires about the additional service. When making an inquiry for an additional service, the gateway ECU 110 transmits, for example, a service ID that identifies the service to the server 210.

The service ID is associated with the service package. Therefore, the server 210 can manage, for example, the service ID and the service package in the database on the auxiliary storage device 215.

In the first embodiment, the new service 401 is selected. Therefore, in step S202, the gateway ECU 110 transmits the service ID of the new service 401 to the server 210.

Next, in step S203, the server 210 receives the service ID transmitted from the gateway ECU 110 in step S202. Then, the control unit 381 in the server 210 searches the database on the auxiliary storage device 215 based on the service ID.

The control unit 381 detects the corresponding service package 400 by searching, and transmits the detected service package 400 to the gateway ECU 110 via the external communication interface 214. As a result, the server 210 can provide the gateway 110 with the service package 400 corresponding to the new service 401.

Next, in step S204, when the acquisition of the service package 400 is completed, the gateway ECU 110 extracts the manifest 404 included in the service package 400 and stores it in the memory 116. After that, the gateway ECU 110 refers to the service placement destination described in the manifest 404, and transfers the service package 400 to the placement destination ECU.

FIG. 9 is a diagram showing a specific example of the manifest 404 according to the first embodiment of the present invention. Manifest 404 regarding the new service 401 shown in FIG. 9 describes the following contents.
Service placement: Location of new service Execution timing: Timing of executing new service Related service: Other services required to execute new service

Returning to the description of step S204, specifically, the control unit 311 of the gateway ECU 110 reads the service placement destination from the manifest 404. In the first embodiment, the control unit 311 reads from the manifest 404 of FIG. 9 described above that the service is arranged at the domain controller ECU 120. After that, the communication unit 313 of the gateway ECU 110 transfers the service package 400 to the domain controller ECU 120.

Next, in step S205, the control unit 321 in the domain controller ECU 120 receives the service package 400 via the communication unit 333, and stores the service package 400 in the auxiliary storage device 125. Further, the control unit 321 stores the service package 400 in the auxiliary storage device 125, and then notifies the gateway ECU 110 of the transfer source of the completion of the transfer via the communication unit 333.

Next, in step S206, the gateway ECU 110 searches for related services in order to confirm that the services related to the new service 401 are arranged on the same in-vehicle network 100. Specifically, the control unit 311 in the gateway ECU 110 reads out the manifest 404 stored in the memory 116, and compares the related service described in the manifest 404 with the service registered in the global service registry.

In the first embodiment, the sensing service 411 is registered as a service provision in the global service registry according to step S101. Further, in step S102, the actuator service 421 is registered for use in the global registry.

That is, in the global service registry, the sensing service 411 is registered as the provider service that provides the service to the new service 401, and the actuator service 421 is registered as the user service that uses the new service 401.

On the other hand, in the manifest 404, the sensing service 411 is described as the service used by the new service 401, and the actuator service 421 is described as the service provided by the new service 401. In other words, from the description of the manifest 404, the sensing service 411 is specified as the provider service, and the actuator service 421 is specified as the user service.

Therefore, since the service registered in the global service registry and the service described in the manifest 404 match, the control unit 311 is arranged on the in-vehicle network 100 to which the related service adds a new service. Judge that it has been done.

On the other hand, when there is no related service, the gateway ECU 110 makes a service addition request to the server 210 in the same procedure as in step S202, and in the same step as the operation check test of the new service 401 described later. Test the service you are adding.

The search for related services shown here is just an example. As another example, for example, the presence or absence of related services may be confirmed in advance from the configuration management information of the services installed in the automobile managed by the server 210.

Next, in step S207, the gateway ECU 110 transmits an instruction to transition the service related to the new service 401 to the diagnostic mode. Here, the diagnostic mode is a state in which normal operation is restricted, and refers to, for example, stopping the acquisition of sensor information or stopping the input to the actuator.

This diagnostic mode is used to confirm the operation of the service to be added while the automobile can ensure normal operation. However, if it is determined that the related service does not affect the normal operation of the automobile, it is not always necessary to shift to the diagnostic mode for the related service.

Next, in step S208, among the related services, the local ECU 140 in which the sensing service 411 is arranged shifts the sensing service 411 to the diagnostic mode.

The transition to the diagnostic mode is performed, for example, by the service execution management that manages the state of the process that activates the service provided in the control unit 341 of the local ECU 140. Process states include a diagnostic mode in addition to an initialization mode, a normal mode, and an termination mode. Upon receiving the diagnosis mode transition instruction from the gateway ECU 110, the local ECU 140 performs service execution management to shift the process from the normal mode or the like to the diagnosis mode.

Further, in the diagnostic mode, the provision of the service and the request for the use of the service are stopped. That is, the sensing service 411 registered in the global service registry or each local service registry is canceled.

Next, in step S209, the gateway ECU 110 confirms that the sensing service 411 has completed the transition to the diagnostic mode. The gateway ECU 110 determines, for example, whether or not the sensing service 411 has completed the transition to the diagnostic mode from the service registered in its own global service registry.

Further, the diagnosis mode transition in step S208 stops the provision of the sensing service 411 arranged in the local ECU. As a result, the service provision registration of the sensing service 411 registered in the global service registry is canceled. That is, the gateway ECU 110 determines that the sensing service 411 has transitioned to the diagnostic mode by utilizing the fact that the sensing service 411 has been canceled from the global service registry.

In steps S210 to S212, the same processing as in steps S207 to S209 is performed. Specifically, in step S211 the local ECU 160 in which the actuator service 421 is arranged among the related services shifts the actuator service 421 to the diagnostic mode.

The service execution management provided in the control unit 361 of the local ECU 160 that has received the diagnostic mode transition instruction from the gateway ECU 110 shifts the actuator service 421 to the diagnostic mode and withdraws the service use request to the global service registry.

Next, in step S212, the gateway ECU 110 determines that the actuator service 421 has transitioned to the diagnostic mode by utilizing the fact that the actuator service 421 has been canceled from the global service registry managed by its own control unit 311.

Next, in step S213, after the related service shifts to the diagnostic mode, the gateway ECU 110 requests the server 210 to acquire the diagnostic service as an inquiry for the diagnostic service. Here, the diagnostic service is a service that executes a test for confirming that the new service 401 operates correctly, and is, for example, a test case used in the process of developing the new service 401.

Specifically, the diagnostic service includes a service for generating test data, which is an alternative to the sensing service 411, a service for determining test results, and a service for managing tests, which is an alternative to the actuator service 421.

10A and 10B are diagrams showing a configuration of a test data generation service 431 that is an input when testing the new service 401 in the first embodiment of the present invention. FIG. 10A is a service configured with the above-mentioned sensing service 411 as the main and the test data generation service 431 as the sub. In the normal mode, the sensing service 411, which is the main service, is used, and the sensing service 411 provides the service by using the provide service interface 412.

On the other hand, in the diagnostic mode, the test data generation service 431, which is a sub, provides the service by using the provide service interface 412 used by the sensing service 411. The test data generation service 431 is a test management service described later. A request service interface 433 for using the service of 451 may be provided.

Here, the service package including the service configured with the sensing service 411 as the main and the test data generation service 431 as the sub is referred to as the sensing service package 415.

FIG. 10B is a diagram showing a test input service package 430 composed of only the test data generation service 431 described above. In the normal mode, the sensing service 411 shown in FIG. 7A provides the service. On the other hand, in the diagnostic mode, the test data generation service 431 shown in FIG. 10B provides the service.

As a result, the sensing service 411 and the test data generation service 431 can be handled independently. Further, in FIG. 10B, the test data generation service 431 does not need to be arranged in the same ECU as the sensing service 411, and can be arranged in any ECU.

However, the test data generation service 431 is an alternative service to the sensing service 411, which is the main service, that is, a dummy service. Therefore, the service identifier and the provide service interface related to the test data generation service 431 have the same configuration as the sensing service 411.

By making the test data generation service 431 and the sensing service 411 have the same configuration in this way, the sensing service 411 and the test data generation service 431 are hidden. As a result, the new service 401 does not need to be aware of the service to be used.

11A and 11B are diagrams showing a configuration of a service for determining a test result from an output result when testing the new service 401 in the first embodiment of the present invention. FIG. 11A is a service configured mainly with the actuator service 421 described above and with the test result determination service 441 as a sub. In the normal mode, the main actuator service 421 uses the new service 401 via the request service interface 423.

On the other hand, in the diagnostic mode, the test result judgment service 441, which is a sub, uses the new service 401 via the request service interface 423 used by the actuator service 421. The test result judgment service 441 uses the test management described later. A provider service interface 442 for providing services to service 451 may be provided.

Here, the service package including the service configured with the actuator service 421 as the main and the test result determination service 441 as the sub is referred to as the actuator service package 425.

FIG. 11B is a diagram showing a test output service package 440 composed of only the test result determination service 441 described above. In the normal mode, the actuator service 421 shown in FIG. 7B uses the service. On the other hand, in the diagnostic mode, the test result determination service 441 shown in FIG. 11B uses the service.

As a result, the actuator service 421 and the test result determination service 441 can be handled independently. Further, in FIG. 11B, the test result determination service 441 does not need to be arranged in the same ECU as the actuator service 421, and can be arranged in any ECU.

However, the test result determination service 441 is an alternative service to the actuator service 421, which is the main service, that is, a dummy service. Therefore, the identifier that identifies the service related to the test result determination service 441 and the request service interface have the same configuration as the actuator service 421.

By configuring the actuator service 421 and the test result determination service 441 in the same configuration in this way, the actuator service 421 and the test result determination service 441 are hidden. As a result, the new service 401 does not need to be aware of the service to be provided.

FIG. 12 is a diagram showing a configuration of a test management service package that manages the test data generation service 431 and the test result determination service 441 in the first embodiment of the present invention. The test management service package 450 is composed of a test management service 451, a request service interface 452, a provide service interface 453, and a manifest 454.

Here, the request service interface 452 is an interface for acquiring a test result from the test result determination service. Further, the provide service interface 453 is an interface for issuing an instruction to the test data generation service. Further, the manifest 454 executes and manages the test management service.

The test management service package 450 is arranged, for example, in the gateway ECU 110 that manages the services of the entire vehicle-mounted network 100.

Returning to FIG. 8B, the description of the communication system will be continued. In step S214, the server 210 searches for a service package required for testing the new service 401 described above based on the diagnostic service request from the gateway ECU 110. Then, the server 210 acquires, for example, the sensing service package 415, the actuator service package 425, and the test management service package 450 as diagnostic services as search results. Then, the server 210 transfers the acquired diagnostic service to the gateway ECU 110.

Next, in step S215, the gateway ECU 110 installs the diagnostic service. Specifically, the gateway ECU 110 stores the test management service package 450 in the auxiliary storage device 125 among the service packages acquired by the server 210.

Next, in step S216, the gateway ECU 110 activates the diagnostic service. Specifically, the gateway ECU 110 activates the test management service 451 of the test management service package 450 stored in the auxiliary storage device 125.

When the start of the test management service 451 is completed, the service provision registration and the service use registration are performed for the global service registry and each local service registry.

Next, in step S217, the gateway ECU 110 transfers the diagnostic service. Specifically, the gateway ECU 110 transfers the sensing service package 415 to the local ECU 140 among the service packages acquired from the server 210.

More specifically, similarly to step S204, the control unit 311 of the gateway ECU 110 reads the service placement destination from the manifest 414. In the first embodiment, the service is arranged at the local ECU 140. Therefore, the communication unit 313 of the gateway ECU 110 transfers the sensing service package 415 to the local ECU 140.

Next, in step S218, the local ECU 140 installs the diagnostic service. Specifically, the local ECU 140 stores the sensing service package 415 transferred from the gateway ECU 110 in the auxiliary storage device 145.

Next, in step S219, the local ECU 140 activates the diagnostic service. Specifically, the local ECU 140 activates the test data generation service 431 of the sensing service package 415 stored in the auxiliary storage device 145.

When the start of the test data generation service 431 is completed, the service provision registration and the service use registration are performed for the global service registry and each local service registry.

Next, in step S220, the local ECU 140 notifies the gateway ECU 110 that the test data generation service 431 has been started. As a method of notifying, for example, the control unit 311 of the gateway ECU 110 may search for a service registered in the global service registry and determine from the presence or absence of a service related to the test data generation service 431.

Next, in step S221, the gateway ECU 110 transfers the diagnostic service. Specifically, the gateway ECU 110 transfers the actuator service package 425 to the local ECU 160 among the service packages acquired from the server 210.

More specifically, similarly to step S204, the control unit 311 of the gateway ECU 110 reads the service placement destination from the manifest 424. In the first embodiment, the service is arranged at the local ECU 160. Therefore, the communication unit 313 of the gateway ECU 110 transfers the actuator service package 425 to the local ECU 160.

Next, in step S222, the local ECU 160 installs the diagnostic service. Specifically, the local ECU 160 stores the actuator service package 425 transferred from the gateway ECU 110 in the auxiliary storage device 165.

Next, in step S223, the local ECU 160 activates the diagnostic service. Specifically, the local ECU 160 activates the test result determination service 441 of the actuator service package 425 stored in the auxiliary storage device 165.

When the start of the test result determination service 441 is completed, the service provision registration and the service use registration are performed for the global service registry and each local service registry.

Next, in step S224, the local ECU 160 notifies the gateway ECU 110 that the test result determination service 441 has been started. As a method of notifying, for example, the control unit 311 of the gateway ECU 110 may search for a service registered in the global service registry and determine from the presence or absence of a service related to the test result determination service 441.

Next, in step S225, the gateway ECU 110 instructs the domain controller ECU 120 to start the new service 401, which is an additional service. Specifically, the control unit 311 of the gateway ECU 110 shifts the process state for activating the new service 401 from the initialization mode to the normal mode.

Next, in step S226, the domain controller ECU 120 starts starting the new service 401 based on the start instruction of the new service 401 from the gateway ECU 110. When the start of the new service 401 is completed, the service provision registration and the service use registration are performed for the global service registry and each local service registry.

Next, in step S227, the domain controller ECU 120 establishes service communication. Specifically, the domain controller ECU 120 establishes communication between the services by the test data generation service 431 registered in the local service registry and the usage request of the test data generation service 431 of the new service 401.

Similarly, the domain controller ECU 120 establishes communication between the services by the new service 401 registered in the service registry and the usage request of the test result determination service 441.

However, the test data generation service 431 is a dummy service of the sensing service 411, and the test result determination service 441 is a dummy service of the actuator service 421. Therefore, from the viewpoint of the new service 401, it is considered that the communication between the normal services is established by establishing the service communication in step S227.

Next, in step S228, the new service 401 requests a service from the sensing service 411. Specifically, the new service 401 requests test data necessary for testing the new service 401. As a matter of fact, the new service 401 requests the test data generation service 431.

Next, in step S229, when the test data generation service 431 receives a service use request from the new service 401, it generates test data necessary for testing the new service 401. The test data is, for example, data used for a unit test or a system test performed in the development process of the new service 401.

Next, in step S230, the test data generation service 431 responds to the request of the new service 401 and transmits the test data to the new service 401. That is, the local ECU 140 transmits test data to the domain controller ECU 120. Specifically, communication between services will be performed via the provide service interface 412 of the test data generation service and the request service interface 403 of the new service.

Next, in step S231, the new service 401 arranged on the domain controller ECU 120 executes the basic operation. Specifically, the new service 401 arranged on the domain controller ECU 120 performs the calculation of the new service 401 by inputting the test data transmitted from the test data generation service.

Next, in step S232, the domain controller ECU 120 transmits the calculation result to the actuator service 421 that requests the calculation result of the new service 401. That is, the domain controller ECU 120 transmits the calculation result to the local ECU 160. As a matter of fact, the domain controller ECU 120 transmits the calculation result to the test result determination service 441.

Specifically, communication between services is performed via the provide service interface 402 of the new service 401 and the request service interface 443 of the test result determination service 441.

Next, in step S233, the test result determination service 441 makes a test determination by determining whether or not the calculation result of the new service 401 matches the expected value. The expected value may be, for example, an expected value used for a unit test or a system test performed in the development process of the new service 401.

Next, in step S234, the test result determination service 441 transmits the test result to the test management service 451. That is, the local ECU 160 transmits the test result to the gateway ECU 110. Specifically, communication between services is performed via the provide service interface 442 of the test result determination service 441 and the request service interface 452 of the test management service 451.

Next, with respect to step S235 and step S236, the test result is False, that is, the new service 401 is executed when it operates abnormally.

In step S235, the gateway ECU 110 instructs the domain controller ECU 120 to delete the new service 401. Specifically, the control unit 321 of the domain controller ECU 120 stops the new service 401. After that, the control unit 321 deletes the service package 400 stored in the auxiliary storage device 125.

Next, in step S236, the domain controller EUC 120 notifies the gateway ECU 110 that the deletion of the new service 401 is completed. Specifically, the gateway ECU 110 determines that the new service 401 has been deleted because the registration information of the new service 401 has been deleted from the global service registry managed by its own control unit 311.

When the test result is True, that is, when the new service 401 operates normally, in step S237, the gateway ECU 110 transmits an instruction to transition from the diagnostic mode to the normal mode to the local ECU 140.

Next, in step S238, the local ECU 140 shifts the sensing service 411 from the diagnostic mode to the normal mode. As a method for transitioning to the normal mode, the same method as in step S208 described above can be adopted.

When the sensing service 411 shifts to the normal mode, the sensing service 411 registers the service provision of the sensing service 411 with the global service registry and each local service registry.

Next, in step S239, the local ECU 140 notifies the gateway ECU 110 that the sensing service 411 has completed the transition to the normal mode. As a method of notifying, for example, it is conceivable to use that the sensing service 411 is registered in the global service registry.

In steps S240 to S242, the actuator service 421 is transitioned from the diagnostic mode to the normal mode in the same procedure as in steps S237 to S239 described above.

Next, in step S243, the gateway ECU 110 transmits the test result of the new service 401 acquired in step S234 to the server 210.

Next, in step S244, the server 210 updates the vehicle information managed by the auxiliary storage device 215 on the server 210 based on the test result. The vehicle information is, for example, configuration management information of software installed in each automobile.

To update the vehicle information, specifically, when the test result is True, that is, when the new service 401 can be added normally, the new service 401 is added to the vehicle information. On the other hand, if the test result is False, that is, if the new service 401 does not operate properly, the vehicle information is not updated.

Next, in step S245, the server 210 notifies the gateway ECU 101 that the update of the vehicle information is completed.

Finally, in step S246, the gateway ECU 110 notifies the user 900 that all the procedures for adding the new service have been completed. As a method of notifying the user 900, for example, it is conceivable to provide the gateway ECU 110 with an output device such as a display and display on the display that the additional procedure has been completed.

As described above, the communication system according to the first embodiment has a configuration in which it can be confirmed that the communication system according to the first embodiment normally operates on the in-vehicle network with respect to the service newly added to the automobile or the existing service to be updated. It has. By providing such a configuration, it is possible to easily confirm and guarantee that the new service corresponding to the update or new addition operates normally.

In the first embodiment, the functions of each control device (110, 120, 130, 140, 150, 160, 170) may be realized by hardware. FIG. 13 is a diagram showing a configuration in which the function of each control device according to the first embodiment of the present invention is realized by hardware. Each control device includes a processing circuit 500. The processing circuit 500 is also referred to as a processing circuit. The processing circuit 500 is a dedicated electronic circuit that realizes a function executed by a control unit (311, 321, 331, 341, 351, 361, 371) provided in each control device.

For example, the processing circuit 500 is a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA, an ASIC, an FPGA, or a combination thereof. GA is an abbreviation for Gate Array, ASIC is an abbreviation for Application Special Integrated Circuit, and FPGA is an abbreviation for Field Programmable Gate Array. Each control device may include a plurality of processing circuits that replace the processing circuit 500. The plurality of processing circuits share the role of the processing circuit 500.

The above-described first embodiment is an example of a preferred embodiment and is not intended to limit the technical scope of the present invention. The first embodiment may be partially implemented or may be implemented in combination with other embodiments. Further, the procedure described with reference to the sequence diagram or the like may be appropriately changed.

100 In-vehicle network, 110 gateway, 111, 121, 131, 141, 151, 161, 171, 211 Processor, 112, 122, 132, 142, 152, 162, 172, 212 Timer, 113, 123, 133, 143, 153 , 163, 173 communication interface, 114, 214 external communication interface, 115, 125, 135, 145, 155, 165, 175, 215 auxiliary storage device, 116, 126, 136, 146, 156, 166, 176, 216 memory, 180 communication bus, 200 external network, 210 server, 220 public communication line, 311, 321, 331, 341, 351, 361, 371, 381 control unit, 312, 322, 332, 342, 352, 362, 372, 382 counter 313, 323, 333, 343, 353, 363, 373 Communication, 314, 384 External Communication, 316, 326, 336, 346, 356, 366, 376, 386 Storage, 400 Service Package, 401 Services ( New Service), 402 Provide Service Interface, 403 Request Service Interface, 404 Manifest, 410 Sensing Service Package, 411 Sensing Service, 412 Provide Service Interface, 414 Manifest, 415 Sensing Service Package, 420 Actuator Service Package, 421 Actuator Service, 423 Request Service interface, 424 manifest, 425 actuator service package, 430 test input service package, 431 test data generation service, 433 request service interface, 440 test output service package, 441 test result judgment service, 442 provide service interface, 443 request service interface, 450 Test Management Service Package, 451 Test Management Service, 452 Request Service Interface, 453 Provide Service Interface, 454 Manifest, 500 Processing Circuits, 900 Users.

The control device according to the present invention includes a plurality of controllers having a service which is a software element for processing a desired function, and a network for connecting the plurality of controllers to each other, each of the plurality of controllers via a network. The control unit includes a control unit that realizes a desired operation by combining services by performing communication control between a plurality of services, and the control unit operates whether or not a new service corresponding to an update or a new addition operates normally. When executing the confirmation, the process state for starting the service is changed from the normal mode for executing the normal operation of the new service to the diagnostic mode for restricting the normal operation and executing the operation confirmation of the new service, and the new service is executed. The provider service that provides the service to the user and the user service that uses the new service are specified, and in the diagnostic mode, communication control is performed between the new service, the provider service, and multiple services composed of the user service. It is a control device that executes operation check in order to realize the desired operation by combining services, and the new service is equipped with a provide service interface when the new service is a service provider. If the new service is a service user, the request service interface is implemented, and if the new service is a service provider and a service user, the provide service interface and the request service interface are implemented. , It is configured to have a manifest that describes the conditions for starting the new service .

Claims (5)

Multiple controllers with services that are software elements that process the desired function,
It is equipped with a network that connects the plurality of controllers to each other.
Each of the plurality of controllers includes a control unit that realizes a desired operation by combining services by performing communication control between a plurality of services via the network.
The control unit confirms whether or not the new service corresponding to the update or new addition operates normally.
The process state for starting the service is changed from the normal mode for executing the normal operation of the new service to the diagnostic mode for restricting the normal operation and executing the operation check of the new service.
Identify the provider service that provides the service for the new service and the destination service that uses the new service.
In the diagnostic mode, by performing communication control between the plurality of services configured by the new service, the provider service, and the destination service, the desired operation can be realized by combining the services. A control device that performs an operation check. The new service is composed of a main service used when performing the normal operation and a dummy service used in the diagnostic mode and limited to the normal operation.
The main service and the dummy service have the same identifier and the same interface.
The control device according to claim 1, wherein the control unit executes the operation check of the new service by activating the dummy service in the diagnostic mode. In one or more of the plurality of controllers, the service registry in which the provider service is registered as a service provision registration and the user service is registered as a service use registration for each service existing on the network. Have more
The control device according to claim 2, wherein each control unit in the plurality of controllers identifies the provider service and the user service by referring to the service registry. The provider service has test data in the dummy service corresponding to the data to be provided to the new service.
The controller having the provider service transmits the test data to the controller having the new service in the diagnostic mode.
The destination service has an expected value corresponding to the test data in the dummy service.
The control unit included in the controller having the destination service acquires the calculation result using the test data from the controller having the new service, and determines whether or not the calculation result and the expected value match. The control device according to claim 3, which outputs the test result shown. The control device according to claim 4 and
A server that provides the new service to the control device is provided.
One of the plurality of controllers included in the control device is a gateway ECU that is communicably connected to the server via a public communication line and controls the control device in an integrated manner.
The gateway ECU
The control device executes the operation check regarding the new service acquired from the server.
When a test result indicating that the calculation result and the expected value match is obtained as the test result obtained by executing the operation check, the process state is changed from the diagnostic mode to the normal mode. A communication system that transitions and starts the normal operation using the new service.

Images