Vehicle communication system and vehicle-mounted system

Abstract

An OTA center 1A manages data to be written to a plurality of ECUs mounted on a car 31, and performs, by means of an application program, a plurality of functions for transmitting update data to the car 31 by wireless communication. The application program, which implements at least some of the functions, adopts a server-less architecture. When an onboard-side system 51 transmits an information request 1 including vehicle configuration information collected in a car 31A to an OTA center 1F, an API gateway unit 11F transmits an interim response reply including a job ID corresponding to the request to the onboard-side system 51. The onboard-side system 51, upon receiving the response reply, transmits a response request for a final response reply corresponding to the information request 1, to the OTA center 1F as an information request 2 to which the job ID is attached.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2021-210817 filed on December 24, 2021, the contents of which are incorporated herein by reference. [Technical field]

[0002] The present disclosure relates to a vehicle communication system and an in-vehicle system. [Background technology]

[0003] In recent years, with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of application programs such as vehicle control and diagnosis mounted on the vehicle's electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) is increasing. In addition, with version upgrades for function improvements and the like, there are also increasing opportunities to rewrite ECU application programs, that is, to perform so-called reprogramming. Meanwhile, with the development of communication networks, connected car technology is also becoming widespread. In light of these circumstances, for example, Patent Document 1 discloses a technology in which an ECU update program is delivered from a server to an in-vehicle device by OTA (Over The Air) and the update program is rewritten on the vehicle side. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-27624 A Summary of the Invention

[0005] When the center device disclosed in Patent Document 1 is actually configured, it will have a configuration as shown in Fig. 53, for example, and each management block constituting the center device is assumed to be realized by an architecture that generally assumes the use of a server. In this application, the environment or configuration for executing an application program on the assumption that a server is used is referred to as a "server architecture." In other words, in a server architecture, resources are always assigned to an application program, and the program is executed as a resident process.

[0006] However, as shown in Fig. 54, it is expected that the number of accesses from vehicles to the server in the center device will be high during the day and low at night. Therefore, if the server is operated at night, the cost will be very wasteful.

[0007] In addition, due to regulations, a center device compatible with connected cars must be installed in each country. Therefore, if the same scale system is built for each country, there will be a lot of waste in the cost of operating servers in areas with few vehicles (see Figure 55).

[0008] Therefore, it is assumed that the environment or configuration for executing application programs on the center device side is realized by a serverless architecture that does not rely on the above-mentioned server architecture. The serverless architecture, which will be described in detail in the "Description of Embodiments," refers to a system that uses computing services without using a server to execute program code on demand.

[0009] Basically, communication between a vehicle and a center device follows a flow in which the center device performs processing in response to a request from the vehicle, and then returns a response to the vehicle. When a serverless architecture is adopted, a charge for computing services is incurred each time processing is executed. Therefore, the issue is how to suppress the occurrence of charges. In addition, it is necessary to efficiently perform communication between the vehicle and the center device and to effectively use computing resources.

[0010] The present disclosure has been made in consideration of the above-mentioned circumstances, and its purpose is to provide a vehicle communication system and an in-vehicle system that can minimize the consumption of computing resources that occurs when adopting a serverless architecture when multiple vehicles communicate wirelessly with a center device.

[0011] According to the vehicle communication system of claim 1 or 2, the center device manages data to be written to an electronic control device mounted in the vehicle, and executes a plurality of functions for transmitting update data to the vehicle by wireless communication using an application program. At that time, the application program that realizes at least some of the functions is started when an event occurs, and a serverless architecture is adopted in which resources are dynamically allocated to the execution of the code of the application program in an on-demand manner, and the resources allocated to the application program are released when the execution of the code is completed.

[0012] As described above, the number of accesses from vehicles to the center device varies depending on the time of day, and the number of vehicles itself also differs depending on the region. If a serverless architecture is adopted for an application program that realizes at least some of the functions, resources are dynamically allocated and the program is started each time an access occurs from a vehicle, and the resources are released when the execution of the code is completed. Therefore, compared to the case of adopting a server architecture that is executed as a resident process, it is possible to reduce the consumption of computing resources, and as a result, the running costs of the infrastructure can be reduced.

[0013] Furthermore, the campaign determination unit receives vehicle configuration information from the vehicle and determines whether or not there is campaign information for the vehicle. If there is campaign information, the campaign generation unit generates campaign notification information for the vehicle. The status management unit manages the generation status of the campaign information, and the campaign transmission unit distributes the campaign notification information to the vehicle in accordance with the generation status. An application program that realizes the functions of the campaign determination unit, status management unit, and campaign generation unit employs a serverless architecture.

[0014] For example, even in communications that require connection management, the status management unit manages the generation status of campaign information, so the campaign generation unit and campaign transmission unit do not need to continue operating until the campaign notification information is delivered to the vehicle. Therefore, the benefits of realizing these functions using a serverless architecture can be enjoyed to the fullest.

[0015] When the in-vehicle system transmits a first request including vehicle configuration information collected in the vehicle to the center device, the campaign transmission unit transmits an intermediate response including a job ID corresponding to the request to the in-vehicle system. When the in-vehicle system receives the intermediate response, it transmits a response request for a final response corresponding to the first request to the center device as a second request with the job ID attached.

[0016] That is, the in-vehicle system only needs to send two requests to communicate with the center device. Then, the center device can launch an application program corresponding to the requested processing between the two requests and execute the processing. This allows the use of an external computing service that employs a serverless architecture only for the period during which the required processing is to be executed. Therefore, a system in which charges are based on the duration of service usage can reduce the operating costs of the center device. [Brief description of the drawings]

[0017] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: [Figure 1] FIG. 1 is a functional block diagram showing a configuration of an OTA center in the first embodiment; [Diagram 2] Figure 2 shows an example of how the functions of an OTA center are realized by applying AWS. [Diagram 3] FIG. 3 is a flow diagram illustrating a process performed between a vehicle-side system and an OTA center. [Figure 4A] FIG. 4A is a flowchart (part 1) showing a process from receiving vehicle configuration information to transmitting campaign information; [Figure 4B] FIG. 4B is a flowchart (part 2) showing a process from receiving vehicle configuration information to transmitting campaign information; [Figure 5A]FIG. 5A is a flowchart (part 1) showing the process from registering campaign information to registering a distribution package in a CDN distribution unit. [Figure 5B] FIG. 5B is a flowchart (part 2) showing the process from registering campaign information to registering a distribution package in the CDN distribution unit. [Figure 6] FIG. 6 is a flowchart showing the process from data access by a vehicle to package delivery by the CDN delivery unit. [Figure 7] FIG. 7 is a flowchart showing a registration process of software update data. [Figure 8A] FIG. 8A is a flowchart (part 1) showing the process from registering case information to generating a package. [Figure 8B] FIG. 8B is a flowchart (part 2) showing the process from registering case information to generating a package. [Figure 9] FIG. 9 is a flowchart (part 3) showing the process from registering case information to generating a package. [Figure 10] FIG. 10 is a diagram for explaining the effect of accumulating data in a queuing buffer unit for a certain period of time before transferring the data to a compute service function unit at the next stage. [Figure 11] FIG. 11 is a diagram for explaining the processing modes of the server model and the serverless model. [Figure 12] FIG. 12 is a diagram showing the running costs of the server model and the serverless model. [Figure 13] FIG. 13 is a functional block diagram showing a configuration of an OTA center in the second embodiment; [Figure 14] FIG. 14 shows an example of how the functions of an OTA center are realized by applying AWS. [Figure 15A] FIG. 15A is a flowchart (part 1) showing a process from receiving vehicle configuration information to transmitting a job ID and generating campaign information; [Figure 15B]FIG. 15B is a flowchart (part 2) showing the process from receiving vehicle configuration information to transmitting a job ID and generating campaign information. [Figure 16] FIG. 16 is a flowchart showing the process from receiving a campaign information request to checking the generation status and sending the request. [Figure 17A] FIG. 17A is a flowchart (part 1) showing the process from registering campaign information to registering a distribution package in a CDN distribution unit. [Figure 17B] FIG. 17B is a flowchart (part 2) showing the process from registering campaign information to registering a distribution package in the CDN distribution unit. [Figure 18] FIG. 18 is a flowchart (part 3) showing the process from registering campaign information to registering a distribution package in the CDN distribution unit. [Figure 19A] FIG. 19A is a flowchart (part 1) showing the process from registration of case information to generation of a package. [Figure 19B] FIG. 19B is a flowchart (part 2) showing the process from registration of case information to generation of a package. [Figure 20] FIG. 20 is a flowchart (part 3) showing the process from registering case information to generating a package. [Figure 21] FIG. 21 is a functional block diagram showing a configuration of an OTA center in the third embodiment; [Figure 22] FIG. 22 shows an example of how the functions of an OTA center are realized by applying AWS. [Diagram 23] FIG. 23 is a flowchart showing the process from receiving vehicle configuration information to transmitting a job ID and generating campaign information. [Figure 24A] FIG. 24A is a flowchart (part 1) showing the process from receiving a campaign information request to checking the generation status of campaign information and transmitting the campaign information. [Figure 24B]FIG. 24B is a flowchart (part 2) showing the process from receiving a campaign information request to checking the generation status of campaign information and transmitting the campaign information. [Figure 25A] FIG. 25A is a flowchart (part 1) showing the process from registering campaign information to registering a distribution package in a CDN distribution unit. [Figure 25B] FIG. 25B is a flowchart (part 2) showing the process from registering campaign information to registering a distribution package in the CDN distribution unit. [Figure 26A] FIG. 26A is a flowchart (part 1) showing the process from receiving a request to register case information to checking and transmitting the registration information. [Figure 26B] FIG. 26B is a flowchart (part 2) showing the process from receiving a request to register case information to checking and transmitting the registration information. [Figure 27] FIG. 27 is a diagram for explaining a problem that may occur in the third embodiment in the fourth embodiment. [Figure 28] FIG. 28 is a functional block diagram showing the configuration of an OTA center. [Figure 29] FIG. 29 shows an example of how the functions of an OTA center are realized by applying AWS. [Diagram 30] FIG. 30 is a flowchart showing the process from receiving vehicle configuration information to transmitting a job ID and generating campaign information. [Diagram 31] FIG. 31 is a functional block diagram showing a configuration of an OTA center in the fifth embodiment; [Diagram 32] FIG. 32 shows an example of how the functions of an OTA center are realized by applying AWS. [Diagram 33] FIG. 33 is a flowchart showing the process from receiving vehicle configuration information to transmitting a job ID and generating campaign information. [Diagram 34] FIG. 34 is a flowchart showing the process from registering campaign information to registering a distribution package in the CDN distribution unit. [Diagram 35]FIG. 35 is a flowchart showing the process from registration of case information to generation of a package. [Diagram 36] FIG. 36 is a functional block diagram showing a configuration of an OTA center in the sixth embodiment; [Figure 37] FIG. 37 shows an example of how the functions of an OTA center are realized by applying AWS. [Figure 38A] FIG. 38A is a flowchart (part 1) showing the process from receiving a campaign information request to checking the generation status of campaign information and transmitting the campaign information. [Figure 38B] FIG. 38B is a flowchart (part 2) showing the process from receiving a campaign information request to checking the generation status of campaign information and transmitting the campaign information. [Figure 39] FIG. 39 is a flowchart showing the process from data access by a vehicle to package delivery by the CDN delivery unit. [Diagram 40] FIG. 40 is a functional block diagram showing a configuration of a vehicle communication system in the seventh embodiment. [Diagram 41] FIG. 41 shows an example of how the functions of an OTA center are realized by applying AWS. [Diagram 42] FIG. 42 is a diagram for explaining each functional unit of the downloader of the OTA master. [Diagram 43] FIG. 43 is a flowchart showing the process on the OTA master side from the transmission of vehicle configuration information to the reception of campaign information. [Diagram 44] FIG. 44 is a flowchart showing a process for transmitting all data of vehicle configuration information; [Figure 45A] FIG. 45A is a flowchart (part 1) showing the processing on the OTA center side from the transmission of vehicle configuration information (request 1) to the transmission of campaign information. [Figure 45B] FIG. 45B is a flowchart (part 2) showing the processing on the OTA center side from the transmission of vehicle configuration information (request 1) to the transmission of campaign information. [Figure 45C]FIG. 45C is a flowchart (part 3) showing the processing on the OTA center side from the transmission of vehicle configuration information (request 1) to the transmission of campaign information. [Figure 46A] FIG. 46A is a flowchart (part 4) showing the processing on the OTA center side from the transmission of vehicle configuration information (request 1) to the transmission of campaign information. [Figure 46B] FIG. 46B is a flowchart (part 5) showing the processing on the OTA center side from the transmission of vehicle configuration information (request 1) to the transmission of campaign information. [Figure 47] FIG. 47 is a flowchart showing the processing on the OTA center side from the transmission of vehicle configuration information (request 2) to the transmission of campaign information. [Figure 48A] FIG. 48A is a flowchart (part 1) showing a process performed between the OTA center and the OTA master when approval is given sequentially for program updates by a campaign in the eighth embodiment; [Figure 48B] FIG. 48B is a flowchart (part 2) showing the processing performed between the OTA center and the OTA master when approval is given sequentially for program updates due to a campaign. [Figure 49A] FIG. 49A is a flowchart (part 1) showing a process performed between the OTA center and the OTA master when approval is given sequentially for program updates by a campaign in the ninth embodiment; [Figure 49B] FIG. 49B is a flowchart (part 2) showing the processing performed between the OTA center and the OTA master when approval is given sequentially for program updates due to a campaign. [Figure 50] FIG. 50 is a flowchart showing a VIN list registration process for a premium member in the tenth embodiment. [Figure 51] FIG. 51 is a flowchart (part 1) showing the process on the OTA center side from the transmission of vehicle configuration information to the transmission of campaign information. [Figure 52]FIG. 52 is a flowchart (part 2) showing the process on the OTA center side from the transmission of the vehicle configuration information to the transmission of the campaign information. [Figure 53] FIG. 53 is a functional block diagram assuming that the functions of the OTA center are configured mainly by applying a server architecture. [Figure 54] FIG. 54 is a diagram showing server access trends by time period in a connected car service. [Figure 55] Figure 55 shows the difference in the number of cars sold in each region. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] (First embodiment)

[0019] Hereinafter, a first embodiment will be described. As shown in Fig. 1, an OTA center 1, which is a center device of this embodiment, includes a distribution system 2 and a common system 3. In the common system 3, a distribution package including an ECU update program and data to be distributed to a car 31, which is a vehicle, is generated and managed, and the generated distribution package is distributed to the car 31 via the distribution system 2 by wireless communication, i.e., by OTA.

[0020] When the common system 3 generates a package, necessary data is transmitted and received between the OEM (Original Equipment Manufacturer) back office 4, which is an external server system, and the key management center 5. The OEM back office 4 includes a first server 6 to a fourth server 9. These servers 6 to 9 are similar to those shown in FIG. 53, and are systems for manufacturing information management, customer management, telematics contracts, and SMS (Short Message Service) distribution, respectively. The key management center 5 includes a fifth server 10, which is a system for issuing and managing keys used for OTA.

[0021] The first server 6 to the fifth server 10 employ the above-mentioned server architecture, and resources are always allocated to application programs, and the programs are executed as resident processes.

[0022] An API (Application Programming Interface) gateway unit (1) 11 of the distribution system 2 performs wireless communication with the car 31 and the OTA operator 34. Data received by the API gateway unit 11 is transferred in sequence to the compute service function unit (1) 12, the queuing buffer unit 13, the compute service function unit (2) 14, and the compute service processing unit (1) 15. The compute service function unit 12 accesses the database unit (1) 16. The compute service processing unit 15 accesses the file storage unit 18 and the database unit (2) 19. The database unit 19 stores campaign information, which is software update information corresponding to the car 31 that requires program update. The API gateway unit 11 inputs and outputs data and exchanges instructions and responses between the car 31, the OTA operator 34, the smartphone 32, the PC 33, and the like. The API gateway unit 11 may perform wired communication between the OTA operator 34 or the PC 33.

[0023] The data output by the compute service processing unit 15 is output to the API gateway unit 11 via the compute service function unit (3) 20. A CDN (Contents Delivery Network) distribution unit 21 accesses the file storage unit 18 and distributes the data stored in the file storage unit 18 to the car 31 by OTA. The CDN distribution unit 21 is an example of a network distribution unit.

[0024] The API gateway unit (2) 22 of the common system 3 inputs and outputs data with the compute service processing unit 15 of the distribution system 2, and the compute service processing unit (2) 23 and the compute service function unit (4) 24 provided in the common system 3. The compute service processing unit 23 accesses the database unit (3) 25 and the file storage unit (3) 26. The compute service function unit 24 accesses the file storage unit 26 and the database unit (4) 27. The API gateway unit 22 also accesses each of the servers 6 to 10 provided in the OEM back office 4 and the key management center 5. The API gateway unit 22 inputs and outputs data and exchanges instructions and responses with each of the servers 6 to 10 provided in the OEM back office 4 and the key management center 5.

[0025] In the above configuration, the compute service function units 12, 14, 20, and 24, and the compute service processing units 15 and 23 employ a serverless architecture. The "serverless architecture" is started when an event occurs, and resources are automatically allocated to the execution of the code of the application program in an on-demand manner. Once the execution of the code is completed, the allocated resources are automatically released, and is based on a design concept opposed to the above-mentioned "server architecture."

[0026] Furthermore, the "serverless architecture" is started in response to the occurrence of an event, and resources are dynamically allocated for the execution of the code of an application program, and the allocated resources are released when the execution of the code is completed. The resources may be released immediately after the execution of the code is completed, or may be released after waiting for a predetermined time, for example, 10 seconds, after the execution is completed.

[0027] Here are four principles for building a serverless architecture: Use computing services to execute program code on demand, without using servers. - Make it a straight forward function with only one purpose. · Configure a push-based event-driven pipeline. -Makes the front end thicker and stronger. It would be something like this.

[0028] FIG. 2 shows an example of the center device 1 shown in FIG. 1 configured using the AWS (Amazon Web Service) cloud. · Amazon API Gateway: Corresponds to API gateway parts 11 and 22. · AWS Lambda: Corresponds to compute service function units 12, 20, and 24. · Amazon Kinesis: Equivalent to queuing buffer unit 13. Elastic Load Balancing: corresponds to the compute service function unit 14. · AWS Fargate: Equivalent to the compute service processing unit 15. · Amazon S3: corresponds to the file storage units 18 and 26. ·Amazon Aurora: corresponds to database parts 19, 25 and 27.

[0029] Incidentally, CDN77 corresponds to the CDN distribution unit 21, and is a service provided by CDN77 Co., Ltd. This may be replaced with the Amazon CloudFront service provided by AWS. CDN77 is a cache server distributed around the world. In addition, both AWS Lambda and AWS Fargate are serverless computing services and can realize equivalent functions. Therefore, the compute service function unit 14 and the compute service processing unit 15 may be integrated into either one of them in the block diagram.

[0030] Next, the operation of this embodiment will be described. As shown in Fig. 3, in the "vehicle configuration information synchronization" phase, vehicle configuration information is transmitted to the OTA center 1 at the timing when the ignition switch is turned on in the car 31, for example, every two weeks. The vehicle configuration information is information about the hardware and software of the ECU mounted on the vehicle. The OTA center 1 checks whether there is campaign information applicable to software update based on the transmitted vehicle configuration information. If there is corresponding campaign information, the OTA center 1 transmits the campaign information to the car 31. When the vehicle configuration information is transmitted by the car 31, the information is compared with the vehicle configuration information of the car 31 held on the OTA center 1 side, and the process of updating the information to the newer information is called a synchronization process of the vehicle configuration information. The vehicle configuration information is an example of vehicle information.

[0031] In the "campaign acceptance + DL acceptance" phase, when the driver of the car 31 who has received the campaign information presses a button for accepting the download displayed on the screen of the in-vehicle device, a data package for program update is downloaded from the CDN distribution unit 21. During the download, the car 31 notifies the OTA center 1 of the progress rate of the download process.

[0032] When the download is complete, the status changes to "installation accepted" and the installation is performed, and the progress rate of the installation process is notified from the car 31 to the OTA center 1. When the installation process is complete, the status changes to "activation performed" in the car 31, and when activation is completed, the completion of activation is notified to the OTA center 1. Incidentally, with regard to "campaign consent + DL consent" and "installation consent", consent including "installation consent" may be obtained from the driver at the time of "campaign consent + DL consent".

[0033] Each of the above processes will now be described in detail. <Receive vehicle configuration information → Send campaign information>

[0034] 4, the API gateway unit 11 receives a Hypertext Transfer Protocol Secure (HTTPS) request for vehicle configuration information from the car 31 (S1). The request contents include, for example, a vehicle identification number (VIN), a hardware ID of each ECU, and a software ID of each ECU. Next, the API gateway unit 11 starts the compute service function unit 12 and passes the received vehicle configuration information to the function unit 12 (S2).

[0035] The compute service function unit 12 passes the vehicle configuration information to the queuing buffer unit 13 (S3). The queuing buffer unit 13 accumulates and buffers the passed vehicle configuration information for a certain period of time, for example, one second or several seconds (S4). At this point, the compute service function unit 12 ends the processing, and releases resources such as the CPU and memory that were occupied for performing the processing (S5). Note that the compute service function unit 12 may receive a TCP port number from the API gateway unit 11 and store it in a shared memory, as necessary.

[0036] When the above-mentioned certain period has elapsed (S5A), the queuing buffer unit 13 starts the compute service function unit 14 and passes the vehicle configuration information accumulated within the certain period to the compute service function unit 14 (S6). The queuing buffer unit 13 is an example of an access buffer control unit. The compute service function unit 14 interprets part of the contents of the passed vehicle configuration information, and passes the vehicle configuration information to the compute service processing unit 15 when it starts a container application of the compute service processing unit 15 that can execute appropriate processing (S7).

[0037] Here, a container is a logical partition created on the host OS, and libraries and programs required to run an application are bundled together. OS resources are logically separated and shared among multiple containers. An application executed in a container is called a container app.

[0038] The compute service processing unit 15 accesses the database unit 19 and determines whether or not campaign information, which is software update information, corresponding to the passed vehicle configuration information is present (S8). If campaign information is present, the compute service processing unit 15 generates campaign information to be distributed to the car 31 by referring to the database unit 19 (S9). Here, the compute service processing unit 15 is an example of a campaign determination unit and a campaign generation unit. Furthermore, the compute service function unit 14 corresponds to a first compute service unit, and the compute service processing unit 15 corresponds to a second compute service unit.

[0039] The compute service processing unit 15 starts the compute service function unit 20 and passes the generated campaign information (S10). At this point, the compute service processing unit 15 ends the processing, and releases resources such as the CPU and memory that were occupied to perform that processing (S11). If there is no campaign in step S8, campaign information is generated to be delivered to the car 31 to notify "no campaign" (S12), and then the process proceeds to step S10.

[0040] The compute service function unit 20 passes the passed campaign information to the API gateway unit 11 for distribution to the corresponding car 31. At this point, the compute service function unit 20 ends the processing, and releases resources such as the CPU and memory that were occupied for performing that processing (S14). The API gateway unit 11 transmits an HTTPS response including the campaign information to the car 31 (S15). The API gateway unit 11 is an example of a campaign transmission unit.

[0041] Furthermore, in the above processing, if necessary, the compute service function unit 20 may obtain the TCP port number stored by the compute service function unit 12 from the shared memory and request the API gateway unit 11 to deliver an HTTPS response to that TCP port number.

[0042] <Register campaign information → Register distribution package to CDN distribution unit 21>

[0043] 5, the OTA operator 34 transmits an HTTPS request for campaign information registration (S21). When the API gateway unit 11 starts the compute service function unit 12, it passes the received campaign information (S22).

[0044] The compute service function unit 12 passes the campaign information to the queuing buffer unit 13 (S23). The queuing buffer unit 13 accumulates and buffers the passed campaign information for a certain period of time (S24). At this point, the compute service function unit 12 ends the processing, and releases resources such as the CPU and memory that were occupied to perform the processing (S25). The compute service function unit 12 is an example of a campaign registration unit, and corresponds to a fifth compute service unit.

[0045] When the certain period of time has elapsed (S25A), the queuing buffer unit 13 starts the compute service function unit 14 and passes the campaign information accumulated within the certain period of time to the compute service function unit 14 (S26). The compute service function unit 14 interprets part of the content of the passed campaign information, starts a container application of the compute service processing unit 15 that can execute appropriate processing, and passes the campaign information to the compute service processing unit 15 (S27).

[0046] The compute service processing unit 15 registers the campaign information in the database unit 19 in order to link the target vehicle included in the received campaign information with the software package to be updated (S28). The compute service processing unit 15 also starts the compute service function unit 20, and passes a notification that the registration of the campaign information has been completed to the API gateway unit 11 (S30). The compute service processing unit 15 is an example of a campaign registration unit, and corresponds to a fourth compute service unit.

[0047] Next, the compute service processing unit 15 stores the software package to be updated and URL information for downloading in the file storage unit 18 (S31). At this point, the compute service processing unit 15 ends the processing, and releases resources such as the CPU and memory that were occupied for performing that processing (S32). Then, the file storage unit 18 operates as an origin server for the CDN distribution unit 21 (S33). The compute service processing unit 15 is an example of a package distribution unit, and corresponds to a third compute service unit.

[0048] <Data access from the car → Delivery package sent from CDN to the car>

[0049] 6, an OTA master consisting of a DCM (Data Communication Module) and a central ECU actually mounted on the car 31 accesses the CDN distribution unit 21 based on download URL information included in the campaign information (S41). The CDN distribution unit 21 determines whether the software package requested by the car 31 is stored in its own cache memory (S42). If the software package is stored in the cache memory, the CDN distribution unit 21 transmits the software package to the car 31 (S43).

[0050] On the other hand, if the requested software package is not stored in the cache memory, the CDN distribution unit 21 requests the software package from the file storage unit 18, which is the origin server (S44). The file storage unit 18 then transmits the requested software package to the CDN distribution unit 21 (S45). The CDN distribution unit 21 stores the software package received from the file storage unit 18 in its own cache memory and transmits it to the car 31 (S46).

[0051] <Registering software update data> 7, the API gateway unit 22 receives a registration request for software update data and related information from the first server 6 of the OEM back office 4 as an HTTPS request (S51). The API gateway unit 22 starts the compute service function unit 24 and passes the software update data and related information (S52). The compute service function unit 24 stores the software update data and related information in the file storage unit 26 (S53).

[0052] The compute service function unit 24 updates the search table stored in the database unit 27 so that it is possible to refer to where the software update data and related information are stored (S54). At this point, the compute service function unit 24 ends the processing, and releases resources such as the CPU and memory that were occupied in order to perform that processing (S55).

[0053] <Register project information -> Generate package> 8, the OTA operator 34 transmits an HTTPS request for project information to the API gateway unit 11 in order to register the project information (S61). The project information is a collection of hardware information and software information of an ECU to which a certain distribution package can be applied. When the API gateway unit 11 starts the compute service function unit 12, it passes the received project information to the function unit 12 (S62).

[0054] The compute service function unit 12 passes the case information to the queuing buffer unit 13 (S63). The queuing buffer unit 13 accumulates and buffers the passed case information for a certain period of time (S64). The compute service function unit 12 ends the processing, and releases resources such as the CPU and memory that were occupied for performing the processing (S65). Note that the compute service function unit 12 may receive a TCP port number from the API gateway unit 11 and store it in the shared memory as necessary.

[0055] When the above-mentioned certain period has elapsed, the queuing buffer unit 13 starts the compute service function unit 14 and passes the case information accumulated within the certain period to the compute service function unit 14 (S66). The compute service function unit 14 interprets part of the contents of the passed case information, starts a container application of the compute service processing unit 15 that can execute appropriate processing, and passes the case information to the compute service processing unit 15 (S67).

[0056] The compute service processing unit 15 accesses the database unit 19, and in order to generate a software package based on the software update target information included in the passed case information, starts the container application of the compute service processing unit 23 and passes the software update target information to the compute service processing unit 23 (S68). The compute service processing unit 15 ends the processing, and releases resources such as the CPU and memory that were occupied to perform the processing (S70).

[0057] Based on the passed software update target information, the compute service processing unit 23 transmits an HTTPS request for software update data to the API gateway unit 22 (S71). The API gateway unit 22 starts the compute service function unit 24 and passes the software update data request (S72). The compute service function unit 24 refers to the database unit 27 and acquires path information for the file storage unit 26 in which the software update data is stored (S73).

[0058] The compute service function unit 24 accesses the file storage unit 26 based on the acquired path information and acquires the software update data (S74). Then, the acquired software update data is passed to the API gateway unit 22 for transmission to the compute service processing unit 23 (S75). The compute service function unit 24 ends the processing, and releases resources such as the CPU and memory that were occupied for performing the processing (S76). The compute service function unit 24 is an example of a data management unit.

[0059] The API gateway unit 22 sends a software update response HTTPS response including the software update data to the compute service processing unit 23 (S77). The compute service processing unit 23 refers to the database unit 25 to identify the structure of the software package of the target vehicle (S78). Then, the compute service processing unit 23 processes the software update data so that it matches the identified software package structure, and generates a software package (S79). The compute service processing unit 23 stores the generated software package in the file storage unit 26 (S80). The compute service processing unit 23 is an example of a package generation unit.

[0060] The compute service processing unit 23 passes path information of the file storage unit 26 in which the software package is stored to the API gateway unit 22 (S81) in order to transmit the path information to the compute service processing unit 15. The compute service processing unit 23 ends the processing, and releases resources such as the CPU and memory that were occupied to perform the processing (S82).

[0061] The API gateway unit 22 starts the compute service processing unit 15 and passes the path information of the software package (S83). The compute service processing unit 15 links the passed path information of the software package with the case information and updates the search table registered in the database unit 19 (S84). The compute service processing unit 15 starts the compute service function unit 20 and passes case registration completion information (S85). The compute service processing unit 15 ends the processing and releases resources such as the CPU and memory that were occupied to perform that processing (S86).

[0062] The compute service function unit 20 passes the passed case registration completion information to the API gateway unit 11 to return it to the OTA operator 34 (S87). The compute service function unit 20 ends the processing, and releases resources such as the CPU and memory that were occupied to perform that processing (S88). The API gateway unit 11 transmits an HTTPS response of the case registration completion information to the OTA operator 34 (S89).

[0063] Furthermore, in the above processing, if necessary, the compute service function unit 20 may obtain the TCP port number stored by the compute service function unit 12 from the shared memory and request the API gateway unit 11 to deliver an HTTPS response to that TCP port number.

[0064] Next, the effects of this embodiment will be described. As shown in Fig. 10, the queuing buffer unit 13 accumulates a certain amount of stream data of vehicle configuration information transmitted from each car 31, and then passes the data to the compute service function unit 14 and the compute service processing unit 15 in the next stage. Assuming that the above function is realized by AWS Fargate, the consumption of computing resources can be reduced by reducing the frequency of processing execution.

[0065] Incidentally, while FIG. 10 shows an example of buffering vehicle configuration information transmitted from each car 31, when the OTA operator 34 registers for a campaign or registers case information, the queuing buffer unit 13 similarly accumulates a certain amount of information before passing it on to the next stage compute service function unit 14 and compute service processing unit 15.

[0066] Also, as shown in Fig. 11, in a conventional server model, application programs and servers are always running with resources occupied, and multiple processes are executed by one server. In contrast, in a model employing a serverless architecture like the present embodiment, when a request for each process occurs, the corresponding application program is started, and when the process ends, the program execution is stopped and deleted. Therefore, at this point, the resources used for the process are released.

[0067] As a result, as shown in Fig. 12, in the conventional server model, the fixed cost of running the server all the time is extra compared to the actual operation cost. In addition, if the server is made redundant as a backup, the cost will be further increased. In contrast, if the serverless architecture is adopted as in this embodiment, the running cost of the infrastructure can be significantly reduced because the cost is almost only the actual operation cost.

[0068] As described above, according to this embodiment, the OTA center 1 manages data to be written to multiple ECUs mounted in the vehicle 31, and executes multiple functions by application programs for transmitting update data to the vehicle 31 via wireless communication. In this case, the application programs that realize at least some of the functions are started when an event occurs, and a serverless architecture is adopted in which resources are dynamically allocated to the execution of the application program code in an on-demand manner, and the resources allocated to the application program are released when the execution of the code is completed.

[0069] In a program that employs serverless architecture, resources are dynamically allocated and the program is started each time an access is made from the vehicle 31, and the resources are released when the code execution is completed. Therefore, compared to the case of employing a server architecture that is executed as a resident process, it is possible to reduce the consumption of computing resources of the infrastructure, and as a result, the running costs of the infrastructure can be reduced.

[0070] Second embodiment Hereinafter, the same parts as those in the first embodiment will be denoted by the same reference numerals and the description thereof will be omitted, and the different parts will be described. Assuming that the communication between the vehicle 31 and the OTA center 1 is performed by TCP (Transmission Control Protocol), which is a connection-based communication, it is necessary to perform connection management between the transmission and reception.

[0071] First, when establishing a connection, The sender sends a TCP packet with the SYN (connection establishment request) flag enabled as an establishment request. The receiving side responds with an ACK (Acknowledge) and at the same time enables the SYN flag in the TCP header as a connection establishment request from the receiving side and sends it. The sender sends an ACK packet in response to the SYN from the receiver. A handshake process is required.

[0072] And when you disconnect, The sender first sends a FIN (connection termination request). The receiver sends an ACK, followed by a FIN. After receiving the FIN and sending the final ACK, the sender waits a certain period of time before terminating the connection. A handshake process is required.

[0073] In the configuration of the first embodiment, when considering the above-mentioned connection management, it is necessary to always link the compute service function units 12 and 20 shown in Fig. 1. In addition, since the compute service function units 12 and 20 need to keep their processes running until the processing in the subsequent stages is completed and a response is returned, it is not possible to maximize the benefits of adopting a serverless architecture.

[0074] 13, in the OTA center 1A of the second embodiment, a database unit 41 is placed between the compute service function unit 12A and the compute service processing unit 15A in the distribution system 2A. The database unit 41 is also accessible by the compute service function unit 20A. In the above, the compute service function units 12A, 20A and the database unit 41 are an example of a status management unit.

[0075] Fig. 14 shows an example of the configuration shown in Fig. 13 configured using the AWS cloud. Amazon Aurora, which corresponds to database units 16A and 41, is placed between AWS Lambda, which corresponds to the compute service function unit 12A, and AWS Fargate, which corresponds to the compute service processing unit 15A, and job IDs are managed in Amazon Aurora.

[0076] Next, the operation of the second embodiment will be described. <Receive vehicle configuration information → Send job ID and campaign information> As shown in Fig. 15, steps S1 and S2 are executed first, and the request in step S1 is "information request 1." It is assumed that this request is sent, for example, once every two weeks or once a month from one car 31. If it is assumed that information request 1 is sent once a month from one car 31, then about eight requests will be sent per second from 10 million cars 31.

[0077] Next, the compute service function unit 12A issues a new job ID and registers in the database unit 41 that the job ID is processing (S91). Note that a job ID is issued for each information request 1. Then, in order to return the job ID to the car 31, which is outside the OTA center 1A, the job ID information is passed to the API gateway unit 11A. The job ID information is, for example, "Job ID No.=1" (S92). Then, the API gateway unit 11A transmits an HTTPS response to the information request for the job ID information to the car 31 (S93).

[0078] The compute service function unit 12A passes the vehicle configuration information and job ID information received from the vehicle 31 to the queuing buffer unit 13A (S94). The queuing buffer unit 13A accumulates and buffers the passed vehicle configuration information and job ID information for a certain period of time, for example, several seconds (S95).

[0079] When steps S5 and S5A are executed, the queuing buffer unit 13A starts the compute service function unit 14A and passes the vehicle configuration information and job ID information accumulated within a certain period of time to the compute service function unit 14A (S96). The compute service function unit 14A interprets part of the contents of the passed vehicle configuration information and job ID information, starts a container application of the compute service processing unit 15A that can execute appropriate processing, and passes the vehicle configuration information and job ID information to the compute service processing unit 15A (S97).

[0080] The compute service processing unit 15A accesses the database unit 19A and determines whether or not there is campaign information corresponding to the passed vehicle configuration information and job ID information (S98). From this point, steps S9 and S12 are executed depending on whether or not there is campaign information. In the following step S99, the compute service processing unit 15A registers in the database unit 41 that the processing of the above job ID has been finished and the generated campaign information. Then, step S11 is executed, and the processing ends.

[0081] <Receive campaign information request → Check campaign information generation status and Send Campaign Information> As shown in Fig. 16, when the API gateway unit 11A receives an HTTPS request for campaign information (information request 2) from the vehicle 31 (S101), it starts the compute service function unit 20A and passes the received campaign information request (S102). The request includes a job ID number. The compute service function unit 20A checks the database unit 41 to confirm whether the status of the generation task for the above job ID number is complete (S103).

[0082] If the campaign generation task has been completed, the compute service function unit 20A obtains the generated campaign information from the database unit 41 (S104) and passes it to the API gateway unit 11 (S105). At this point, the compute service function unit 20A ends the processing and releases the occupied resources such as the CPU and memory (S106). The API gateway unit 11 transmits an HTTPS response to the campaign information request to the car 31 (S107).

[0083] On the other hand, if the campaign generation task is incomplete, the compute service function unit 20A passes campaign information indicating that the generation of the campaign information is incomplete to the API gateway unit 11A (S108), and then proceeds to step S106.

[0084] <Campaign information registration (information request 1) → Registering distribution packages to CDN Distribution Unit 21> 17, when steps S21 and S22 are executed (information request 1), the compute service function unit 12A issues a new job ID and registers in the database unit 41 that the job ID is being processed (S111). Then, in order to return the job ID number to the OTA operator 34, the compute service function unit 12A passes the job ID information to the API gateway unit 11A (S112).

[0085] The API gateway unit 11A transmits an HTTPS response to the campaign information request to the OTA operator 34 (S113). The compute service function unit 12A passes the passed campaign information and job ID information to the queuing buffer unit 13A (S114). The queuing buffer unit 13A accumulates and buffers the passed campaign information and job ID information for a certain period of time (S115). Then, steps S25 and S25A are executed.

[0086] The queuing buffer unit 13A starts the compute service function unit 14A and passes the campaign information and job ID information accumulated within a certain period of time to the compute service function unit 14A (S116). The compute service function unit 14A interprets part of the contents of the passed campaign information and job ID information, starts a container application of the compute service processing unit 15A that can execute appropriate processing, and passes the campaign information to the compute service processing unit 15A (S117).

[0087] The compute service processing unit 15A registers the campaign information in the database unit 19A in order to link the target vehicle included in the received campaign information and job ID information with the software package to be updated (S118). Next, the compute service processing unit 15A executes steps S31, S119, S32, and S33. In step S119, the compute service processing unit 15A registers in the database unit 41 that the processing of the above job ID has been completed.

[0088] <Campaign information registration (information request 2) → Registering distribution packages to CDN Distribution Unit 21> 18, when the API gateway unit 11A receives an HTTPS request for campaign information registration from the OTA operator 34 (S121), it starts the compute service function unit 20A and passes the received registration request, information request 2, to the compute service function unit 20A (S122). The compute service function unit 20A checks the database unit 41 to confirm whether the status of the registration task of the above job ID number is completed or not (S123).

[0089] If the campaign registration task has been completed, the compute service function unit 20A passes information indicating the completion of registration to the API gateway unit 11A (S124). At this point, the compute service function unit 20A ends the process and releases the occupied resources such as the CPU and memory (S125). The API gateway unit 11A transmits an HTTPS response to the campaign information registration request to the OTA operator 34 (S126).

[0090] On the other hand, if the campaign registration task is incomplete, the compute service function unit 20A passes campaign information indicating that the campaign information registration is incomplete to the API gateway unit 11A (S127), and then proceeds to step S125.

[0091] <Case Information (Information Request 1) → Generate Package> 19, when steps S61 and S62 are executed (information request 1), the compute service function unit 12 issues a new job ID and registers in the database unit 41 that the job ID is being processed (S131). Then, in order to return the job ID to the OTA operator 34, the compute service function unit 12 passes the job ID information to the API gateway unit 11 (S132). Then, the API gateway unit 11 transmits an HTTPS response to the information request for the case information to the OTA operator 34 (S133).

[0092] The compute service function unit 12A passes the passed case information and job ID information to the queuing buffer unit 13A (S134). The queuing buffer unit 13A accumulates and buffers the passed case information and job ID information for a certain period of time, for example, several seconds (S135).

[0093] When steps S65 and S65A are executed, the queuing buffer unit 13A starts the compute service function unit 14A and passes the case information and job ID information accumulated within a certain period of time to the compute service function unit 14A (S136). The compute service function unit 14A interprets part of the contents of the passed case information and job ID information, starts a container application of the compute service processing unit 15A that can execute appropriate processing, and passes the case information and job ID information to the compute service processing unit 15A (S137).

[0094] The compute service processing unit 15A launches the container application of the compute service processing unit 23 and passes the software update target information to the compute service processing unit 23 in order to generate a software package based on the software update information contained in the passed case information (S138).

[0095] Thereafter, steps S70 to S86 are executed, but step S139 is executed instead of step S85. In step S139, the compute service processing unit 15A registers in the database unit 41 that the processing of the job ID has ended.

[0096] <Case Information (Information Request 2) → Generate Package> 20, when the API gateway unit 11A receives an HTTPS request for registering case information (information request 2) from the OTA operator 34 (S141), it starts the compute service function unit 20A and passes the received request for registering case information (S142). The compute service function unit 20A checks the database unit 41 to confirm whether the status of the task with the job ID number attached to the request is complete (S143).

[0097] If the task of registering case information has been completed, the compute service function unit 20A passes information indicating that the case information registration has been completed to the API gateway unit 11A (S144), terminates the process, and releases the resources that it had occupied (S145). The API gateway unit 11A then transmits an HTTPS response to the case information registration request to the OTA operator 34 (S146). On the other hand, if the task of registering case information has not been completed, the compute service function unit 20A passes information indicating that the case information registration has not been completed to the API gateway unit 11A (S147) to be transmitted to the OTA operator 34, and then proceeds to step S145.

[0098] As described above, according to the second embodiment, the compute service function units 12A, 20A and the database unit 41 assign job ID information to a request received from the car 31, manage a status indicating whether the process corresponding to the request is being processed or has been completed, and return a response to the request for which the process has been completed to the car 31. This eliminates the need to keep the compute service function units 12A and 20A running until the process corresponding to the request is completed, making it possible to enjoy more of the benefits of adopting a serverless architecture.

[0099] Third embodiment In the configuration of the second embodiment, communication traffic between the car 31 and the API gateway unit 11 of the OTA center 1A increases, and this raises concerns about an increase in communication charges. Also, in this configuration, if there is a design error on the car 31 side or the OTA center 1A side, communication retries from the car 31 may occur in an infinite loop, and the OTA center 1A may fall into an overloaded state.

[0100] Therefore, as shown in Fig. 21, in the OTA center 1B of the third embodiment, compute service function units 42 and 43 are added to the configuration of the second embodiment. The compute service function unit 43 accesses the compute service function unit 42 and the database unit 41B, and the compute service function unit 42 accesses the API gateway unit 11B. The database unit 41B manages the connection ID number together with the job ID number and the status. The compute service function unit 20B is an example of a delivery destination management unit.

[0101] FIG. 22 shows an example in which the configuration shown in FIG. 21 is configured using AWS services. · Amazon API Gateway: Equivalent to API Gateway section 11B. · AWS Lambda: Corresponds to compute service function units 12B, 20B, and 42. · AWS Fargate: Corresponds to compute service processing units 14B and 15B. ·Amazon Aurora: corresponds to database parts 19B, 25 and 27. · CloudWatch: corresponds to Compute Service Function Unit 43.

[0102] Next, the operation of the third embodiment will be described. <Receive vehicle configuration information → Send job ID and campaign information> As shown in Fig. 23, after steps S1 and S2 are executed, the compute service function unit 12B issues a new job ID and registers in the database unit 41B the fact that the job ID is being processed and the connection ID number (S151). Thereafter, steps S92 to S11 are executed as in the second embodiment. The connection ID number is a so-called TCP port number. Note that the API gateway unit 11B does not store the job ID, but does store the connection ID number, which is the TCP port number used when communicating with the car 31.

[0103] <Receive campaign information request → Check campaign information generation status and Send Campaign Information> As shown in Fig. 24, when the API gateway unit 11B executes step S101, it starts the compute service function unit 20B and passes the received campaign information request (S152). The request includes connection ID information along with the job ID number. The compute service function unit 20B searches the database unit 41B by the job ID number and registers the connection information in the table of the corresponding job ID number (S153). Then, it executes step S106.

[0104] The process of steps S154 to S160 is started periodically, for example, every few seconds. The compute service function unit 43 periodically checks the database unit 41B at a certain cycle to confirm whether there is a new job ID number for which a task has been completed (S154). If there is a job ID number for which a task has been completed, the compute service function unit 43 acquires the connection ID information and campaign information for that job ID number from the database unit 41B (S155). Then, after passing the acquired connection ID information and campaign information to the compute service function unit 42 (S156), the compute service function unit 43 ends the process and releases the occupied resources (S157).

[0105] Next, the compute service function unit 42 passes the connection ID information and the campaign information to the API gateway unit 11B (S159). The API gateway unit 11B identifies the car 31 to which the information should be returned based on the connection ID information, and transmits an HTTPS response to the campaign information request to the car 31 (S160). On the other hand, if there is no job ID number for which the task has been completed in step S154, the same process as in step S157 is performed (S158) and then the process ends.

[0106] <Register campaign information (information request 2)> Registering distribution packages to CDN Distribution Unit 21> For information request 1, steps S21 to S33 are executed in the same manner as in the second embodiment. In step S91, the compute service function unit 12A issues a new job ID, and registers in the database unit 41 that the job ID is being processed (Processing), and the connection ID number. Then, as shown in FIG. 25, when the API gateway unit 11B executes step S121, it executes the same processes as steps S152 and S153 (S161, S162) and then executes step S125. The processes of steps S163 to S169 are the same as the processes of steps S154 to S160, but the destination of the response in step S169 is the OTA operator 34.

[0107] <Data access from the car → Delivery package sent from CDN to the car> <Registering software update data> These processes are similar to those in the first embodiment. <Registering project information and generating packages> This process is similar to that in the second embodiment.

[0108] <Receive a request to register project information → Check the project information registration status Sending case registration information (results)> As shown in Fig. 26, the processes of steps S171 and S172 are similar to steps S141 and S142, but the information passed to the compute service function unit 20B includes connection ID information. The processes of steps S173 to S181 are the same as the processes of steps S153 to S160 shown in Fig. 24, but for case information instead of campaign information.

[0109] As described above, according to the third embodiment, when the compute service function unit 20B receives a request to which a job number is assigned from the car 31 or the OTA operator 34, the compute service function unit 20B assigns a connection number linked to the job number and registers the request in the database unit 41B, and when there is a request for which processing has been completed by referring to the database unit 41, the compute service function units 42 and 43 identify the car 31 or the OTA operator 34 to which the response is to be sent based on the connection number corresponding to the job number of the request, and transmit the response to the identified car 31 or the OTA operator 34 via the API gateway unit 11B. This eliminates the need for a process in which the car 31 or the OTA operator 34 repeatedly sends a request to check whether the processing of the job number has been completed to the API gateway unit 11B, and reduces the amount of communication that occurred in the second embodiment, thereby reducing the amount of communication traffic between the car 31 or the OTA operator 34 and the API gateway unit 11B.

[0110] (Fourth embodiment) Here, in the configuration of the third embodiment, it is assumed that the processing load of AWS Fagate, which corresponds to the compute service processing unit 15B arranged in the rear stage of the queuing buffer unit 13B, is adjusted by auto-scaling. In this case, the target tracking scaling policy of ECS (Elastic Container Service) is usually used to control the number of tasks, etc., by using CloudWatch metrics and alarms in ECS.

[0111] However, because there is inevitably a time lag between CloudWatch metrics and the issuance of an alarm, scaling in units of a few seconds is difficult, and scaling basically has to be done on the order of minutes. Therefore, the problem with serverless implementations that simply apply AWS Fargate is that they cannot handle sudden increases in communication traffic from cars 31, as shown in Figure 27.

[0112] 28, in an OTA center 1C according to the fourth embodiment, a compute service function unit 44 is added to the configuration of the third embodiment in a distribution system 2C. The compute service function unit 14C accesses the compute service function unit 44, and the compute service function unit 44 accesses a compute service processing unit 15C.

[0113] The compute service function unit 44 actively executes scale-out. In order to auto-scale AWS Fargate, which corresponds to the compute service processing unit 15C, at high speed, for example, Step Functions is used to obtain the number of connections to the Fargate task, which is the data plane, every three seconds, and the upper limit of the number of tasks of ECS, which is the control plane, is raised according to the result. This adjusts the processing capacity of the compute service processing unit 15C. The compute service function unit 44 is an example of a processing capacity adjustment unit.

[0114] FIG. 29 shows an example in which the center device 1C shown in FIG. 28 is configured using the AWS cloud. · Amazon API Gateway: Equivalent to API Gateway section 11C. · AWS Lambda: Compute service function part 12C, 20C, 42C, Equivalent to 44. SQS: corresponds to the queuing buffer unit 13C. · AWS Step Functions: Equivalent to Compute Service Function Part 14C. ·Amazon Aurora: Equivalent to database section 16C and 41C. · CloudWatch: corresponds to the compute service function part 43C.

[0115] Next, the operation of the fourth embodiment will be described. <Receive vehicle configuration information → Send JOB_ID and generate campaign information> Steps S1 to S5A are executed in the same manner as in the second embodiment shown in Fig. 15. Then, as shown in Fig. 30, when the same process as step S96 is executed (S191), the compute service function unit 14C starts the compute service function unit 44 (S192). The compute service function unit 44 checks the following (1) to (3) (S192). The number of container applications launched in the compute service processing unit 15C Processing load rate of each container app The number of job IDs that are queued in the queuing buffer unit 13C

[0116] Next, the compute service function unit 44 checks whether any of the following conditions is satisfied (S194). The number of launches of (1) above exceeds the preset threshold. The load factor in (2) above exceeds the specified threshold. The number of job IDs in (3) above exceeds the default threshold.

[0117] If the threshold value is exceeded in any of the conditions, the compute service function unit 44 forcibly adds and starts the container application in order to scale out the container application of the compute service processing unit 15C (S195).

[0118] Next, the compute service function unit 14C passes the vehicle configuration information and the job ID to the container application started by the compute service processing unit 15C (S196). Then, the compute service function units 14C and 44 end the processing and release the occupied resources (S197). On the other hand, if the threshold is not exceeded under any condition in step S194, the compute service function unit 14C passes the vehicle configuration information and the job ID to the container application already started by the compute service processing unit 15C (S198) and then proceeds to step S197. Thereafter, steps S98 to S11 shown in FIG. 15 are executed.

[0119] As described above, according to the fourth embodiment, the compute service function unit 44 checks the processing load of the compute service processing unit 15C that generates campaign notification information for the car 31 and the number of pieces of vehicle configuration information received from the car 31, and then determines whether or not the processing capacity of the compute service processing unit 15C needs to be increased or decreased, and increases or decreases the processing capacity as necessary. This makes it possible to handle a sudden increase in the amount of communication traffic between the car 31 and the OTA operator 34.

[0120] Fifth embodiment The fifth embodiment shows a configuration that optimizes development costs. As shown in Fig. 31, an OTA center 1D of the fifth embodiment is a distribution center 2D in which the queuing buffer unit 13 and the compute service function unit 14 are deleted from the configuration of the second embodiment.

[0121] FIG. 32 shows an example of the center device 1D shown in FIG. 31 configured using the AWS cloud. · Amazon API Gateway: Equivalent to API Gateway section 11D. · AWS Lambda: Equivalent to compute service function unit 20D and 42D. · AWS Step Functions: Equivalent to Compute Service Function Part 12D. Dynamo DB: Database parts 16D, 41D and This corresponds to the compute service function unit 43D.

[0122] Next, the operation of the fifth embodiment will be described. <Receive vehicle configuration information → Send job ID and campaign information> 33, after steps S1 to S93 are executed, the compute service function unit 12D starts a container application of the compute service processing unit 15D that can execute appropriate processing, and passes vehicle configuration information to the compute service processing unit 15D (S201). Then, steps S5 to S11 are executed.

[0123] <Receive campaign information request → Check campaign information generation status and Send Campaign Information> This is similar to the process shown in FIG. 24 in the third embodiment.

[0124] <Registering campaign information → Registering a distribution package to the CDN distribution unit 21D> 34, after steps S21 to S113 are executed, the compute service function unit 12D starts a container application of the compute service processing unit 15D that can execute appropriate processing, and passes vehicle configuration information to the compute service processing unit 15D (S202). Then, steps S25, S118, and S31 to S33 are executed.

[0125] <Register campaign information → Register distribution package to CDN distribution unit 21> This is similar to the process shown in FIG. 25 in the second embodiment. <Data access from the car → Delivery package sent from CDN to the car> This is similar to the process shown in FIG. 6 in the first embodiment. <Registering software update data> This is similar to the process shown in FIG. 7 of the first embodiment.

[0126] <Register project information -> Generate package> As shown in Fig. 35, when steps S61 to S133 are executed in the same manner as in Fig. 19 of the second embodiment, the compute service function unit 12D starts a container application of the compute service processing unit 15D capable of executing appropriate processing, and passes vehicle configuration information to the compute service processing unit 15D (S203). Then, when steps S65 and S138 are executed, steps S70 to S86 are executed in the same manner as in Fig. 19 of the second embodiment.

[0127] <Receive a request to register project information → Check the project information registration status Sending case registration information (results)> This is similar to the process shown in FIG. 26 in the third embodiment.

[0128] As described above, according to the fifth embodiment, by deleting the queuing buffer unit 13 and the compute service function unit 14, the OTA center 1D can be configured at low cost.

[0129] Sixth embodiment In the sixth embodiment, in order to strengthen security, a signed URL with an expiration date is used. By using this signed URL, it is possible to specify the start date and time when a user can start accessing the content, the date and time or period when the user can access the content, and also to specify the IP address or range of IP addresses of the user who can access the content. The above signature is an example of access control information.

[0130] For example, the OTA center creates a signed URL using a private key and returns it to the car, and the car uses the signed URL to download or stream content from the CDN. At that time, the CDN verifies the signature using a public key and verifies that the user has the credentials to access the file.

[0131] As shown in Fig. 36, an OTA center 1E of the sixth embodiment is obtained by adding a compute service function unit 45 to the configuration of the second embodiment in a distribution system 2E. The compute service function unit 45 accesses a compute service processing unit 15E. A database unit 41E manages expiration dates and signed URLs.

[0132] FIG. 37 shows an example of the center device 1E shown in FIG. 36 configured using the AWS cloud. · Amazon API Gateway: Equivalent to API Gateway section 11E. · AWS Lambda: Compute service function part 12E, 14E, 20E, Equivalent to 45. · AWS Step Functions: Equivalent to Compute Service Function Part 14E. SQS: corresponds to the queuing buffer unit 13E. Dynamo DB: Database section 16E, 41E and It corresponds to the compute service function unit 42E.

[0133] Next, the operation of the sixth embodiment will be described. <Receive vehicle configuration information → Send job ID and campaign information> First, steps S1 to S5 and steps S92 to S11 are executed as in the process shown in FIG. 23 of the third embodiment. Then, steps S101 to S106 are executed as in the process shown in FIG. 24. Then, as shown in FIG. 38, when step S154 is executed, if there is a job ID number for which a task has been completed, the compute service function unit 43E acquires the connection ID information and campaign information, the expiration date, and the signed URL for that job ID number from the database unit 41E (S211). Then, when the above acquired information is passed to the compute service function unit 42E (S212), step S157 is executed. When the compute service function unit 42E passes the above information to the API gateway unit 11E (S213), step S160 is executed.

[0134] The process of steps S214 to S217 is executed periodically. The compute service function unit 45 periodically checks the database unit 41E to confirm whether there is any expired signed URL (S214). If there is an expired signed URL, a new expiration date is added to the signed URL (S215) and the database unit 41E is updated (S216). Then, the compute service function unit 45 ends the process and releases the occupied resources (S217).

[0135] <Register campaign information → Register distribution package to CDN distribution unit 21> This is the same processing as in the third embodiment.

[0136] <Data access from the car → Delivery package sent from CDN to the car> As shown in Fig. 39, the car 31 accesses the CDN distribution unit 21 based on the download URL information, expiration date, and signed URL included in the campaign information (S221). The CDN distribution unit 21 verifies whether the expiration date and the signature of the signed URL are correct using a public key (S222). If the verification result is OK, the CDN distribution unit 21 verifies whether the expiration date has expired (S223), and if the expiration date has not expired, executes steps S42 to S46. On the other hand, if the expiration date has expired, the CDN distribution unit 21 sends an error message to the car 31 (S224).

[0137] <Registering software update data> <Register project information -> Generate package> <Receive a request to register case information → Check the case information generation status and send the case information> These processes are similar to those in the third embodiment.

[0138] As described above, according to the sixth embodiment, the campaign information includes the expiration date and the signed URL together with the download URL information, and the OTA center 1E checks the expiration date and verifies the signature, so that the date and time when access to the content can be started and the date and time when access can be started can be specified, and the users who can access the content can be limited by the CDN distribution unit 21. Therefore, the security of the communication with the car 31 can be improved. In addition, in the first to sixth embodiments, when the OTA operator 34 accesses the API gateway unit 11, when the OEM back office 4 accesses the API gateway unit 22, or when the key management center 5 accesses the API gateway unit 22, processing may be performed by a program that employs a server architecture.

[0139] Seventh embodiment The seventh embodiment relates to processing of an in-vehicle system that performs wireless communication with the OTA center 1, etc. As shown in Fig. 40 and Fig. 41, an in-vehicle system 51 mounted on a car 31A includes an OTA master 52, ECUs 53(1) to 53(3), a user interface unit 54, etc. The OTA master 52 includes a downloader 55 and an installer 56. The ECU 53 includes a microcomputer 57, a memory 58, etc., and the user interface unit 54 includes a display device 59.

[0140] The vehicle-side system may have the following configuration. The vehicle-side system includes a DCM and a central ECU (also called a CGW). The DCM and the central ECU are connected to each other via a bus so that data communication can be performed. The bus may be an Ethernet or a CAN (registered trademark) bus, for example.

[0141] A part or all of the functions of the OTA master 52 may be realized in the central ECU. As an example, the DCM may only perform data communication with the outside, such as the CDN 21 or the OTA center 1F, and all of the functions of the OTA master 52 may be implemented in the central ECU. In this case, the DCM performs wireless communication with the outside, but transfers data to the central ECU. Alternatively, the DCM may function as a downloader 55 of the OTA master 52 in addition to performing data communication with the outside. The functions of the downloader 55 include, for example, generation of vehicle configuration information, metadata verification, package verification, and verification of campaign information. Alternatively, the functions of the OTA master 52 may be realized in the DCM. In this case, functions other than those of the OTA master 52 are implemented in the central ECU. Alternatively, the DCM and the central ECU may be integrated.

[0142] That is, the central ECU may have a part or all of the functions of the DCM, or the DCM may have a part or all of the functions of the central ECU. In the OTA master 52, the functions of the DCM and the central ECU may be divided in any manner. The OTA master 52 may be composed of two ECUs, a DCM and a central ECU, or may be composed of one integrated ECU having the functions of the DCM and the central ECU.

[0143] In the OTA center 1F shown in FIG. 41, only the functional parts related to the gist of the seventh embodiment are shown in blocks. The downloader 55 includes a vehicle configuration synchronization processing unit 60 and a campaign notification receiving unit 61. As shown in FIG. 42, the vehicle configuration synchronization processing unit 60 collects various data output by the ECU 53 and the like as vehicle configuration information, and generates digest information obtained by applying a hash function to the full data of the collected information. The digest information of the vehicle information is transmitted to the OTA center 1F together with an information request 1; a first request. In addition, a response response; an intermediate response corresponding to the information request 1 is received from the OTA center 1F together with a job ID and additional information.

[0144] The additional information includes parameters for switching processing on the vehicle side, and the parameters are used to perform processing for each vehicle or each service. In addition, the additional information may include a waiting time, which is a transmission condition from the time when the response is received until the time when the information request 2 is transmitted, as described later.

[0145] Based on the additional information, or when it is determined that a waiting time preset in the vehicle 31A has elapsed, the campaign notification receiving unit 61 accesses the OTA center 1F by transmitting an information request 2 (second request) with a job ID. In addition, the campaign notification receiving unit 61 receives a response (final response) corresponding to the information request 2 from the OTA center 1F together with the campaign information. The response includes campaign information indicating that there is a campaign, campaign information indicating that there is no campaign, a request to transmit full data of vehicle configuration information, and information request 1 has not yet been processed (in other words, is being processed).

[0146] A compute server unit 62 that employs a server architecture is added to the distribution system 2F. The compute server unit 62 transfers data between the API gateway unit 11F and the database unit 41F. Note that the in-vehicle system 51 mounted on the car 31A in the seventh embodiment is also applicable to the OTA center 1 described in the embodiments other than the seventh embodiment.

[0147] Next, the operation of the seventh embodiment will be described. <Transmission of vehicle configuration information → Reception of campaign information; OTA master side processing> As shown in Fig. 43, when the ignition switch of the car 31A is turned on, the OTA master 52 judges whether a certain period has changed since the date when the synchronization process of the vehicle configuration information with the OTA center 1F was last performed, or whether the vehicle configuration information has changed (S231). If either of these has changed, the OTA master 52 transmits an HTTPS request related to the synchronization process of the vehicle configuration information; information request 1, to the API gateway unit 11F of the OTA center 1F (S232). Alternatively, if a notification indicating that there is a campaign is received from the OTA center 1F in step S231, the process proceeds to step S232.

[0148] When the OTA master 52 receives a response corresponding to the information request 1 together with the job ID and additional information from the API gateway unit 11F (S233), it waits for the waiting time included in the additional information to elapse (S234). When the waiting time has elapsed, the OTA master 52 transmits the information request 2 with the job ID attached to the API gateway unit 11F to request a response including the campaign information (S235). Note that the waiting time is not limited to that given by the additional information, and may be preset in the in-vehicle system 51.

[0149] When the response is received and processed, the contents of the campaign information are judged (S236, S237). That is, it is judged whether a campaign to be updated is included, whether a request to transmit full data of the vehicle configuration information is made, etc. Depending on the contents, the process branches through the next step S238. If a campaign to be updated is included, a download process is performed as in the previous embodiment (S239). If a request to transmit full data is made, all data of the vehicle configuration information is transmitted to the OTA center 1F (S240).

[0150] Next, a case where full data transmission is requested will be described. 44, when transmitting full data of vehicle configuration information, the digest information in step S232 is replaced with all data and an HTTPS request is transmitted (S241). The subsequent processes of steps S242 to S248 are similar to the processes of steps S233 to S239. Note that step S241 corresponds to information request 1, step S242 to an intermediate response, step S244 to information request 2, and step S245 to a final response, respectively.

[0151] <Transmission of vehicle configuration information → Transmission of campaign information; Processing at the OTA center> 45, in the process corresponding to the reception of the information request 1, the API gateway unit 11F of the OTA center 1F receives an HTTPS request for synchronization of the vehicle configuration information from the car 31A, the mobile 32, or the PC 33 (S251). Then, the API gateway unit 11F distributes the request to either the car 31A, the mobile 32, or the PC 33 based on the URI information included in the request (S252).

[0152] If the request originates from the vehicle 31A, the API gateway unit 11F activates the compute service function unit 12F and passes the received vehicle configuration information (S253). The compute service function unit 12F issues a job ID, registers in the database unit 41F that the job with that ID is being processed (S255), and passes the job ID together with additional information to the API gateway unit 11F (S256). The API gateway unit 11F passes the job ID and additional information to the vehicle 31A. This becomes an intermediate response (S257).

[0153] Next, the compute service function unit 12F starts a container application of the compute service processing unit 15F capable of executing appropriate processing, and passes the vehicle configuration information (S258). Then, the compute service function unit 12F ends the processing, and releases the occupied resources (S259). Next, the compute service processing unit 15F judges whether the received vehicle configuration information is a hash value obtained by applying a hash function to the full data; that is, a digest value, or the full data itself (S260, S261). If it is a digest value, it judges whether it matches the value registered in the OTA center 1F (S262, S263).

[0154] If both values ​​match, the compute service processing unit 15F refers to the campaign information stored in the database unit 19F to determine whether or not a campaign, which is software update information, exists for the vehicle configuration information and job ID information passed (S269). If corresponding campaign information exists, the compute service processing unit 15F refers to the database unit 19F to generate campaign information to be distributed to the vehicle 31A (S270).

[0155] Then, the compute service processing unit 15F registers in the database unit 19F the fact that the processing corresponding to the job ID has been completed and the generated campaign information (S271).Then, the compute service processing unit 15F ends the processing and releases the occupied resources (S272).If there is no corresponding campaign information in step S269, the compute service processing unit 15F generates campaign information indicating that there is no corresponding campaign information (S273) and proceeds to step S271.

[0156] On the other hand, if the two values ​​do not match in step S263, the compute service processing unit 15F registers in the database unit 41F that the process corresponding to the job ID has been completed and that the full data of vehicle configuration information has been requested (S264). Then, the same process as in step S272 is performed (S265). Also, if the received vehicle configuration information is full data in step S261, it is determined whether it matches the value registered in the OTA center 1F (S266, S267). If the two data match, the process proceeds directly to step S269, and if the two data do not match, the vehicle configuration information database on the OTA center 1F side is updated (S268) and then the process proceeds to step S269. For example, the database unit 19F corresponds to the vehicle configuration information database.

[0157] In step S252, if the sender of the request is the smartphone 32 or the PC 33, the API gateway unit 11F passes the received vehicle configuration information to the compute server unit 62 (S254). Then, the process proceeds to step S274 shown in Fig. 46. The processes in the following steps S274 to S288 are executed by the compute server unit 62, which executes the processes performed by the compute service processing unit 15F in steps S255 to S257, S260 to S264, and S266 to S273 (except S272). When the request is transmitted from the smartphone 32 or the PC 33, the smartphone 32 or the PC 33 acquires and stores in advance a digest value of the vehicle configuration information and full data of the vehicle configuration information by communicating with the OTA master 52 of the car 31A. The smartphone 32 or the PC 33 also acquires and stores in advance the full data of the vehicle configuration information. When the smartphone 32 or the PC 33 transmits the full data of the vehicle configuration information to the API gateway unit 11F in step S251, the process always proceeds to step S266 in step S261.

[0158] <Transmission of vehicle configuration information → Transmission of campaign information; Processing at the OTA center> The processing of steps S291 to S294 shown in FIG. 47 corresponds to the processing of steps S251 to S254 performed in response to the reception of information request 2. In the following step S295, the compute service function unit 20F checks the database unit 41F to confirm whether the status of the task of the job ID is completed or not. If the task is completed, the compute service function unit 20F passes the processing result of the task, i.e., campaign information, to the API gateway unit 11F (S296). At this point, the car 31A may be requested to transmit full data of the vehicle configuration information. Then, the compute service function unit 20F ends the processing and releases the occupied resources (S297). The API gateway unit 11F passes an HTTPS response to the car 31A (S298). This is the second response.

[0159] In steps S300 to S302 following step S294, the processes performed by the compute service processing unit 20F in steps S295 to S298 (excluding S297) are executed by the compute server unit 62. In step S302, the API gateway unit 11F passes the HTTPS response to the smartphone 32 or the PC 33.

[0160] As described above, according to the seventh embodiment, when the in-vehicle system 51 transmits the information request 1 including the vehicle configuration information collected in the car 31A to the OTA center 1F, the API gateway unit 11F transmits an intermediate response including a job ID corresponding to the request to the in-vehicle system 51. Furthermore, when the in-vehicle system 51 receives the response, it transmits a response request of a final response corresponding to the information request 1 to the OTA center 1F as the information request 2 with the job ID attached.

[0161] That is, the in-vehicle system 51 only needs to send two information requests to communicate with the OTA center 1F. Then, the OTA center 1F can launch an application program corresponding to the requested processing between the two request transmissions and execute the processing. This allows the service to be used only for the period during which the necessary processing is executed, even when using an external computing service that employs a serverless architecture. Therefore, a system in which charges are based on the service usage time can reduce the operating costs of the OTA center 1F.

[0162] Furthermore, the API gateway unit 11F includes additional information including a transmission condition of the information request 2 in the intermediate response and transmits the intermediate response to the in-vehicle system 51. After receiving the response, the in-vehicle system 51 transmits the information request 2 when the transmission condition is satisfied. The transmission condition is, for example, a waiting time from when the in-vehicle system 51 receives the intermediate response until when the in-vehicle system 51 transmits the information request 2, and the in-vehicle system 51 transmits the information request 2 after the waiting time has elapsed. This allows the in-vehicle system 51 to wait before transmitting the information request 2 for a period of time that the OTA center 1F determines is necessary to execute the requested process. It is also possible to configure the system without the compute server unit 62. In that case, even if the request source is the mobile 32 or the PC 33, the compute service function unit 12F is activated.

[0163] Eighth embodiment 48 shows the eighth embodiment, which assumes that when there is campaign information to be transmitted to the vehicle 31A, the occupant of the vehicle 31A sequentially consents to program update, download, and activation by the campaign. The process performed between the OTA center 1F and the OTA master 52 at that time is shown.

[0164] The OTA master 52 displays the contents of the campaign on the display device 59 of the user interface 54, and requests the passenger (driver) to press a campaign acceptance button (S311). Then, the OTA master 52 waits until the driver presses the campaign acceptance button (S312). When the acceptance button is pressed, the OTA master 52 transmits the result of the campaign acceptance to the OTA center 1F (S313), and waits for and receives a response of the campaign acceptance from the OTA center 1F (S314). Steps S313 and S315 are processed in parallel.

[0165] Furthermore, after executing step S313, the OTA master 52 waits for a response response of campaign acceptance as in step S314 (S315), but here, if a predetermined time has passed, it moves to the next process even if a response has not actually been received. If a response is received before the predetermined time has passed, it moves to the next process. Similarly, in the subsequent processes, when waiting for a response from the OTA center 1F, if a response is received before the predetermined time has passed, it moves to the next process.

[0166] In the next step S316, the OTA master 52 displays the content of the download process, such as the time required for the download process, on the display device 59, and requests the driver to press the download consent button. Then, the OTA master 52 waits until the driver presses the download consent button (S317), and when the consent button is pressed, the OTA master 52 transmits the result of the download consent to the OTA center 1F (S318), and waits for and receives a response of the download consent from the OTA center 1F (S319). Steps S318 and S319 are also processed in parallel.

[0167] After executing step S318, the OTA master 52 waits for a download approval response as in step S319 (S320), but proceeds to the next process after a predetermined time has elapsed even if a response has not actually been received. In the following step S321, the OTA master 52 accesses the CDN distribution unit 21F based on the download URL information included in the campaign information, and downloads the software package. The OTA master 52 then displays progress information of the download process on the display device 59 to show it to the driver, and also transmits the progress information to the OTA center 1F (S322).

[0168] When the download process is completed, the OTA master 52 displays an activation consent button on the display device 59 and requests the driver to press it (S323). Then, the OTA master 52 waits until the activation consent button is pressed by the driver (S324). When the consent button is pressed, the OTA master 52 transmits the result of activation consent to the OTA center 1F (S325) and waits for and receives a response of activation consent from the OTA center 1F (S326). Steps S325 and S326 are also processed in parallel.

[0169] After executing step S325, the OTA master 52 waits for a response response of activation acceptance as in step S326 (S325), but also proceeds to the next process after a predetermined time has elapsed even if a response has not actually been received. In the following step S328, the OTA master 52 executes activation at an appropriate timing when activation can be executed.

[0170] As described above, according to the eighth embodiment, the in-vehicle system 51 includes the user interface unit 54 through which the occupant of the vehicle 31A performs an input operation. When the process based on the input operation performed in the user interface unit 54 involves receiving a response from the OTA center 1F, the process proceeds to the next user interface process when the response is received or a predetermined time has elapsed. This makes it possible to prevent the occupant from feeling that there is a delay in the execution of the user interface process even when it takes a relatively long time to receive a response from the OTA center 1F.

[0171] Ninth embodiment The ninth embodiment shown in Fig. 49 is a modification of the eighth embodiment, and steps S315, S320, and S327 are removed from the process shown in Fig. 48. Therefore, the process immediately moves to the next process without waiting for a predetermined time to elapse in those processes. Also, after executing step S328, the OTA master 52 determines whether or not the driver has given consent for each process (S329), and if consent has not been given for at least one process, an error notification is sent to the OTA center 1F (S330).

[0172] Tenth embodiment The tenth embodiment is a variation of the seventh embodiment, and illustrates a case in which some of the drivers of the vehicle 31A are registered in advance as premium members in the OTA center 1F, so that requests made by the premium members are given priority in processing. In addition, the premium member is an example of the vehicle currently eligible for renewal, and the premium member's VIN list is an example of the VIN list of the vehicle currently eligible for renewal. In order to prevent concentrated access to the OTA center and distribution system, the campaign information is notified to only a portion of the vehicles eligible for renewal.

[0173] <VIN list registration for premium members> As shown in FIG. 50, when the OTA center 1F receives the premium member's VIN list from the OEM back office 4 (S331), the OTA center 1F registers the list in the database unit 41F (S332). The premium member's VIN list is an example of a priority processing list. Note that the OTA center 1F may create a priority processing list based on the owner information of the car 31A instead of the premium member's VIN list. The premium member's VIN list is an example of a VIN list of vehicles that are subject to software updates.

[0174] It is assumed that the software update is performed for a portion of the vehicles that are subject to the software update and that are identified by the OEM back office 4; for example, for premium members. For example, if there are 10 million vehicles that are subject to the software update, it is assumed that the software update is performed for only the vehicles 31A designated as premium members before other vehicles, taking into consideration the communication load between the vehicles 31A and the OTA center 1F and the processing load at the OTA center 1F. In this case, the VIN list of the vehicles 31A designated as premium members is registered in the OTA center 1F from the OEM back office 4. For non-premium members, even if an HTTPS request for vehicle configuration information synchronization is sent from the vehicle 31A, smartphone 32, or PC 33 at this point, it is processed as no campaign information in step S333 or S341 described later.

[0175] The VIN list registered from the OEM back office 4 to the OTA center 1F is updated when the OEM back office 4 updates the VIN list or when a request is made from the OTA center 1F. As a result, non-premium member cars 31A that were initially unable to update their software are registered in the VIN list and their software is updated. Note that if the OEM back office 4 does not register a VIN list to the OTA center 1F or if a blank VIN list is registered, all cars 31A may be treated as premium members, and vehicle configuration information synchronization, campaign confirmation, and the like may be performed.

[0176] <Transmission of vehicle configuration information → Transmission of campaign information; Processing at the OTA center> If the request originates from the vehicle 31A, the following processing is carried out. When steps S251 to S255 are executed as in the seventh embodiment, as shown in Fig. 51, the compute service function unit 12F judges whether the VIN included in the vehicle configuration information is included in the premium member's VIN list (S333). If it is included in the list, steps S256 and after are executed. The VIN is an example of vehicle ID information.

[0177] If the job ID is not included in the VIN list, the compute service function unit 12F passes the job ID and the additional information to the API gateway unit 11F, and includes the following transmission conditions in the additional information (S334). The timing for sending a request to the OTA center 1F when the ignition switch is turned on. For example, every time, the next day, N days later, stop, etc. However, if there is a push notification from the OTA center 1F, it may be sent accordingly. Whether or not to send the vehicle configuration information collected this time to the OTA Center 1F. For example, the additional information can specify the next time to transmit a request to the OTA center 1F. It can also instruct not to include vehicle configuration information when transmitting the next request. The processes in steps S335 to S340 are the same as those in steps S257 to S272.

[0178] Moreover, if the request is sent from the smartphone 32 or the PC 33, the following processing is performed. As shown in Fig. 52, after executing step S274, the compute server unit 62 performs a determination similar to that of step S333 (S341). If the VIN is included in the premium member VIN list, the compute server unit 62 performs steps S275 and onward. If the VIN is not included in the VIN list, the compute server unit 62 performs a determination similar to that of step S334 (S342). The subsequent steps S343 to S345 are the same processes as steps S335, S338, and S339, and S338 and S339 are executed by the compute server unit 62 instead of the compute service function unit 12F.

[0179] As described above, according to the tenth embodiment, if the VIN of the car 31A corresponding to the information request 1 is not registered in the VIN list of the premium member, the compute service function unit 12F does not determine whether there is campaign information for the car 31A, and causes the in-vehicle system 51 to transmit information indicating that there is no campaign information as a final response to the request via the API gateway unit 11F. This makes it possible to preferentially transmit campaign information to some users registered as premium members.

[0180] Eleventh embodiment In the above embodiment, an HTTPS request for vehicle configuration information, an HTTPS request for campaign information registration, and an HTTPS request for project information for project information registration have been described as information request 1, but information request 1 may be other information. Information request 1 may be information for identifying a vehicle, such as a VIN (Vehicle Identification Number). For example, a VIN may be transmitted from the car 31A, the smartphone 32, or the PC 33 to the OTA center as information request 1. Vehicle identification information is an example of vehicle information. For example, campaign information transmitted to the car 31A from the OTA center as a response to information request 2 has been described. Information request 2 may be various instructions that the OTA center requests of the OTA master 52.

[0181] (Other embodiments) Application programs that employ a serverless architecture are not limited to those that use AWS, and may use other cloud computing services. The portable information terminal is not limited to a smartphone or a personal computer. The external parties with which the OTA center communicates are not limited to vehicles and OTA operators. Access control information is not limited to expiration dates and signed URLs. The transmission condition may be an area in which transmission of the information request 2 is permitted, such as a parking lot.

[0182] Although the present disclosure has been described based on the embodiment, it is understood that the present disclosure is not limited to the embodiment or structure. The present disclosure also includes various modifications and modifications within the equivalent range. In addition, various combinations and forms, and other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and concept of the present disclosure.

[0183] The means and / or functions provided by each device, etc., can be provided by software recorded in a tangible memory device and a computer that executes the software, software alone, hardware alone, or a combination of these. For example, when a control device is provided by an electronic circuit that is hardware, it can be provided by a digital circuit including a large number of logic circuits, or an analog circuit.

[0184] The control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described in the present disclosure may be realized by one or more special-purpose computers configured by a combination of a processor and a memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits. In addition, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executed by a computer.

Claims

1. A plurality of functions are executed by an application program to manage data to be written to an electronic control unit (52, 53) mounted on a vehicle and to transmit update data to the vehicle by wireless communication, Application programs that realize some functions use a server architecture in which resources are always allocated and executed as resident processes. an application program for realizing at least a part of the other functions is started in response to the occurrence of an event, and resources are dynamically allocated to the execution of the code of the application program in an on-demand manner; A serverless architecture is adopted in which resources allocated to the application program are released when the execution of the code is completed, a campaign determination unit (15) that receives vehicle configuration information from a vehicle and determines whether or not there is campaign information for the vehicle; a campaign generation unit (15) that generates campaign notification information for the vehicle if the campaign information is available; a status management unit (12, 20, 41, 43) for managing a generation status of the campaign information; a campaign transmission unit (11) that distributes the campaign notification information to a vehicle according to the generation state; a center device in which an application program implementing the functions of the campaign determination unit, the status management unit, and the campaign generation unit employs the serverless architecture; In a vehicle communication system including the electronic control device and an in-vehicle system that performs wireless communication with the center device, When the in-vehicle system transmits a first request including vehicle information to the center device, the campaign transmission unit transmits an intermediate response to the vehicle-mounted system, the intermediate response including a job ID corresponding to the request; A vehicle communication system in which, when the vehicle-mounted system receives the intermediate response, it transmits a response request for a final response corresponding to the first request to the center device as a second request with the job ID attached.

2. A plurality of functions are executed by an application program to manage data to be written to an electronic control unit (52, 53) mounted on a vehicle and to transmit update data to the vehicle by wireless communication, An application program that realizes at least a part of the functions is started in response to the occurrence of an event, and resources are dynamically allocated to the execution of the code of the application program in an on-demand manner; A serverless architecture is adopted in which resources allocated to the application program are released when the execution of the code is completed, a campaign determination unit (15) that receives vehicle configuration information from a vehicle and determines whether or not there is campaign information for the vehicle; a campaign generation unit (15) that generates campaign notification information for the vehicle if the campaign information is available; a status management unit (12, 20, 41, 43) for managing a generation status of the campaign information; a campaign transmission unit (11, 20) that distributes the campaign notification information to a vehicle according to the generation state; a center device in which an application program implementing the functions of the campaign determination unit, the status management unit, and the campaign generation unit employs the serverless architecture; In a vehicle communication system including the electronic control device and an in-vehicle system that performs wireless communication with the center device, When the in-vehicle system transmits a first request including vehicle information to the center device, the campaign transmission unit transmits an intermediate response to the vehicle-mounted system, the intermediate response including a job ID corresponding to the request; A vehicle communication system in which, when the vehicle-mounted system receives the intermediate response, it transmits a response request for a final response corresponding to the first request to the center device as a second request with the job ID attached.

3. 3. The vehicle communication system according to claim 1, wherein the vehicle-mounted system transmits the second request to the center device when a predetermined time has elapsed after receiving the intermediate response.

4. the campaign transmission unit transmits the intermediate response to the vehicle-mounted system by including additional information including a transmission condition of the second request in the intermediate response; The vehicle communication system according to claim 1 , wherein the in-vehicle system transmits the second request when the transmission condition is satisfied after receiving the intermediate response.

5. the transmission condition is a waiting time from when the in-vehicle system receives the intermediate response to when the in-vehicle system transmits the second request, The vehicle communication system according to claim 4 , wherein the vehicle-mounted system transmits the second request when the standby time has elapsed.

6. 5. The vehicle communication system according to claim 4, wherein the transmission condition is a designation of an area in which the transmission of the second request is permitted.

7. The vehicle communication system according to claim 1 , wherein the in-vehicle system includes in the first request a hash value obtained by applying a hash function to the vehicle configuration information collected in the vehicle.

8. the campaign transmission unit transmits the final response to the in-vehicle system, the final response including a request for transmission of all data of the vehicle configuration information collected in the vehicle; The vehicle communication system according to claim 7 , wherein the vehicle-mounted system includes all of the data in the second request in response to the transmission request.

9. The vehicle communication system according to claim 7 , wherein the campaign transmission unit transmits, as the final response, information indicating that there is campaign information for the vehicle or that there is no campaign information to the in-vehicle system depending on the judgment result of the campaign judgment unit.

10. The vehicle communication system of claim 9, wherein the campaign determination unit determines whether the ID information of the vehicle corresponding to the first request is registered in a priority processing list, and if the ID information is not registered in the priority processing list, the campaign determination unit transmits information indicating that there is no campaign information to the in-vehicle system via the campaign transmission unit as the final response without determining whether there is campaign information for the vehicle.

11. the in-vehicle system includes a user interface unit through which a vehicle occupant performs an input operation; 2. The vehicle communication system according to claim 1, wherein when a process based on an input operation performed in the user interface section involves receiving a response from the center device, the system proceeds to a next user interface process without waiting for the response to be received.

12. the in-vehicle system includes a user interface unit through which a vehicle occupant performs an input operation; A vehicle communication system as described in claim 1, wherein when a processing based on an input operation performed in the user interface unit involves receiving a response from the center device, the system proceeds to the next user interface processing when the response is received or a predetermined time has elapsed.

13. A plurality of functions are executed by an application program to manage data to be written to an electronic control unit (52, 53) mounted on a vehicle and to transmit update data to the vehicle by wireless communication, Application programs that realize some functions use a server architecture in which resources are always allocated and executed as resident processes. An application program that realizes at least a part of the other functions adopts a serverless architecture in which the application program is started in response to an event, resources are dynamically allocated to the execution of the code of the application program in an on-demand manner, and the resources allocated to the application program are released when the execution of the code is completed; a campaign determination unit (15) that receives vehicle information from a vehicle and determines whether or not there is campaign information for the vehicle; a campaign generation unit (15) that generates campaign notification information for the vehicle if the campaign information is available; a status management unit (12, 20, 41, 43) for managing a generation status of the campaign information; a campaign transmission unit (11) that distributes the campaign notification information to a vehicle according to the generation state; an application program that realizes functions of the campaign determination unit, the status management unit, and the campaign generation unit wirelessly communicates with a center device that employs the serverless architecture, the vehicle-mounted system including the electronic control unit, Transmitting a first request including vehicle information to the center device; receiving an intermediate response including a job ID corresponding to the request from the center device; When the intermediate response is received, the vehicle-mounted system transmits a response request for a final response corresponding to the first request to the center device as a second request to which the job ID is assigned.

14. A plurality of functions are executed by an application program to manage data to be written to an electronic control unit (52, 53) mounted on a vehicle and to transmit update data to the vehicle by wireless communication, An application program that realizes at least a part of the functions is started in response to the occurrence of an event, resources are dynamically allocated to the execution of the code of the application program in an on-demand manner, and when the execution of the code is completed, the resources allocated to the application program are released, adopting a serverless architecture; a campaign determination unit (15) that receives vehicle information from a vehicle and determines whether or not there is campaign information for the vehicle; a campaign generation unit (15) that generates campaign notification information for the vehicle if the campaign information is available; a status management unit (12, 20, 41, 43) for managing a generation status of the campaign information; a campaign transmission unit (11, 20) that distributes the campaign notification information to the vehicle according to the generation state; an application program that realizes functions of the campaign determination unit, the status management unit, and the campaign generation unit wirelessly communicates with a center device that employs the serverless architecture, the vehicle-mounted system including the electronic control unit, Transmitting a first request including vehicle information to the center device; receiving an intermediate response including a job ID corresponding to the request from the center device; When the intermediate response is received, the vehicle-mounted system transmits a response request for a final response corresponding to the first request to the center device as a second request to which the job ID is assigned.

Images