Center device and method for distributing campaign notification information

Abstract

In the present invention, an over-the-air (OTA) center 1A executes, by means of an application program, a plurality of functions for: managing data to be written to a plurality of ECUs incorporated into a car 31; and transmitting update data to the car 31 through wireless communications. An application program which implements at least some of the functions uses a server-less architecture. By using computing service function units 12A, 20A and a database unit 41, job ID information is assigned to a request received from the car 31 and the status indicating whether processing corresponding to the request is in progress or has been completed is managed, and as a result thereof, a response is returned to the car 31 with respect to a request for which processing has been completed.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a center device that manages data to be written to an electronic control device mounted on a vehicle, and a campaign for the vehicle. notification Regarding how information is delivered. [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. 40, and it is assumed that each management block constituting the center device is realized by an architecture that generally assumes the use of a server. In this application, the environment or configuration for executing application programs that assumes the use of a server is called a "server architecture." In other words, in a server architecture, resources are always allocated to application programs, and the programs are executed as resident processes.

[0006] However, as shown in Fig. 41, 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, operating the server at night will result in a lot of waste in costs.

[0007] In addition, regulations require that center equipment compatible with connected cars 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 running servers in areas with few vehicles (see Figure 42). The present disclosure has been made in consideration of the above circumstances, and has an object to configure a center device that performs wireless communication with a plurality of vehicles at a lower cost.

[0008] According to the center device of claim 1 or 2, a plurality of functions are executed by an application program to manage data to be written to an electronic control unit mounted on a vehicle and to transmit update data to the vehicle by wireless communication. 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 by an on-demand method, and the resources allocated to the application program are released when the execution of the code is completed.

[0009] 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.

[0010] 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 notification The campaign notification information is sent to the vehicle according to the status of the campaign generated by the campaign determination unit, the status management unit, and the campaign generation unit. The application program that realizes the functions of the campaign determination unit, the status management unit, and the campaign generation unit employs a serverless architecture.

[0011] For example, even in communications that require connection management, the status management unit notification Since the information generation state is managed, the campaign generation unit and the campaign transmission unit do not need to continue operating until the campaign notification information is delivered to the vehicle, which allows greater benefits to be enjoyed from the realization of these functions using a serverless architecture. [Brief description of the drawings]

[0012] 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. [Figure 23] FIG. 23 is a flowchart showing a 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 a 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 a 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 a CDN delivery unit. [Diagram 40] FIG. 40 is a functional block diagram assuming that the functions of the OTA center are configured mainly by applying a server architecture. [Diagram 41] FIG. 41 is a diagram showing server access trends by time period in a connected car service. [Diagram 42] Figure 42 shows the difference in car sales in each region. [Diagram 43]FIG. 43 is a functional block diagram showing a configuration of an OTA center in the seventh embodiment; [Diagram 44] FIG. 44 shows an example of the center device 1E shown in FIG. 43 configured using the AWS cloud. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] (First embodiment) 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.

[0014] 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. 40, 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.

[0015] 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.

[0016] 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 a 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, etc.

[0017] 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.

[0018] 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. For ease of explanation, the drawings show the transmission and reception of commands and data with lines. However, even if lines are not used, it is possible to call a processing unit, a function unit, or a management unit, and to access a database unit or a storage unit.

[0019] 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."

[0020] 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. Note that, when the execution of the code is completed, the resources are dynamically released. 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.

[0021] 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.

[0022] 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. Furthermore, since Lamdba and Fargate can realize equivalent functions, in the embodiments and figures, the parts marked as Lamdba can also be configured with Fargate, and the parts marked as Fargate can also be configured with Lamdba.

[0023] 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. The CDN distribution unit 21 is not limited to the CDN 77 or the Amazon CloudFront service, but corresponds to any service or server that realizes a content delivery network. Also, the AWS (Amazon Web Service) cloud is an example of a cloud service that provides a serverless architecture. The configurations described in the embodiments and the configurations shown in the drawings are appropriately changed depending on the functions provided by the cloud service.

[0024] Next, the operation of this embodiment will be described. As shown in FIG. 3, in the phase of "vehicle configuration information synchronization", the 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. When a campaign occurs, a short message is transmitted from the fourth server 9 to the vehicle that is the target of the campaign, and the short message may be used as a trigger to transmit the vehicle configuration information to the OTA center 1. The vehicle configuration information is information about the hardware and software of the ECU mounted on the vehicle. Based on the transmitted vehicle configuration information, the OTA center 1 checks whether there is campaign information applicable to software update. 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 vehicle configuration information synchronization process.

[0025] 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.

[0026] 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.

[0027] Each of the above processes will now be described in detail. <Receive vehicle configuration information → Send campaign information> 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).

[0028] 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. The container applications of the compute service processing unit 15 include a container application related to the generation of campaign information, a container application related to the registration of a distribution package, a container application related to the generation of a package, etc. The compute service function unit 14 interprets the information passed to it and starts up the corresponding container application.

[0029] 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).

[0030] 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.

[0031] The compute service processing unit 15 accesses the database unit 19 and determines whether or not there is campaign information, which is software update information, corresponding to the passed vehicle configuration information (S8). If there is campaign information, 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. Also, 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. Note that in step S9, if there is campaign information and all the information necessary for distribution to the car 31 is present, the process proceeds to step S10.

[0032] 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 information in step S8, it generates campaign information to be distributed to the car 31 to notify "no campaign" (S12) and then proceeds to step S10. In step S10, the compute service processing unit 15 passes the campaign information to notify "campaign available" or the campaign information to notify "no campaign" to the compute service function unit 20.

[0033] 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). As a result, the car 31 receives the HTTPS response including the campaign information. The API gateway unit 11 is an example of a campaign transmission unit.

[0034] 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.

[0035] <Register campaign information → Register distribution package to CDN distribution unit 21> 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).

[0036] 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.

[0037] 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).

[0038] 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). In step S30, the API gateway unit 11 transmits an HTTPS response including a notification that the registration of the campaign information has been completed to the OTA operator 34. The compute service processing unit 15 is an example of a campaign registration unit, and corresponds to a fourth compute service unit.

[0039] 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. An origin server is a server where original data exists. The file storage unit 18 saves all of the software packages to be updated and URL information for downloading.

[0040] <Data access from the car → Delivery package sent from CDN to the car> 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).

[0041] 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).

[0042] <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).

[0043] 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). Furthermore, in step S55, the compute service function unit 24 may notify the API gateway unit 22 that the processing has been completed, and the API gateway unit 22 may send an HTTPS response to the OEM back office 4 including information that registration of the software update data and its related information has been completed.

[0044] <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).

[0045] 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.

[0046] 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).

[0047] 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).

[0048] 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).

[0049] 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.

[0050] 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.

[0051] 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).

[0052] 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).

[0053] 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).

[0054] 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.

[0055] 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. In addition, the queuing buffer unit 13 accumulates campaign information and case information for a certain period of time, similar to vehicle configuration information, before passing it on to the next stage, the compute service function unit 14, thereby reducing the frequency of processing execution and suppressing the consumption of computing resources. In addition, the queuing buffer unit 13 may store vehicle configuration information, campaign information, and case information in a single queuing buffer, or may have multiple queuing buffer units 13 and store information in different queuing buffer units 13 depending on the type of information.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] Second embodiment Hereinafter, the same parts as those in the first embodiment are 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-oriented communication, connection management is required between the transmission and reception. Similarly, assuming that the communication between the OTA operator 34 and the OTA center 1 is performed by TCP (Transmission Control Protocol), which is a connection-oriented communication, connection management is required between the transmission and reception.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] Fig. 14 shows an example of the configuration shown in Fig. 13 when configured using the AWS cloud. Amazon Aurora corresponding to database units 16A and 41 is placed between AWS Lambda corresponding to the compute service function unit 12A and AWS Fargate corresponding to the compute service processing unit 15A, and job IDs are managed in Amazon Aurora. Note that Fig. 14 shows an example of communication between a car 31 and an OTA center 1.

[0067] 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.

[0068] 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).

[0069] 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).

[0070] 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).

[0071] 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.

[0072] <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).

[0073] 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).

[0074] 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.

[0075] <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).

[0076] 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.

[0077] 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).

[0078] 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.

[0079] <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).

[0080] 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).

[0081] 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.

[0082] <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).

[0083] 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).

[0084] 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).

[0085] 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).

[0086] 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.

[0087] <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).

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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 S106 are executed. 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.

[0094] <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.

[0095] 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).

[0096] 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.

[0097] <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.

[0098] <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.

[0099] <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.

[0100] 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.

[0101] (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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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

[0107] 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. 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).

[0108] 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. Note that, although the process from sending and receiving vehicle configuration information to sending JOB_ID and generating campaign information is described as an example here, the present invention can be applied to all processes in which scaling out of the compute service processing units 15A and 15B is expected.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] <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.

[0114] <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 the vehicle configuration information to the compute service processing unit 15DD (S202). Then, steps S25, S118, and S31 to S33 are executed.

[0115] <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.

[0116] <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.

[0117] <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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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).

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

[0126] <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).

[0127] <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.

[0128] 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.

[0129] Seventh embodiment In the above embodiment, a case where a serverless architecture is adopted for the OTA center has been described. The OTA center is assumed to communicate with cars, PCs, smartphones, OTA operators, OEM back offices, and key management centers. A server architecture may be adopted for at least a part of the processing, judgment, and management functions of the OTA center.

[0130] For example, if a system has been developed based on a server architecture, there may be verified programs that have been designed and implemented, and modules that are also called development assets. In such a case, if the entire system is to be rebuilt as a serverless architecture, assets such as developed programs and modules, and development knowledge, etc. cannot be used. In such a situation, there is a risk of increased development costs and longer development times.

[0131] The inventors of the present application have focused on combining processes employing a serverless architecture with processes employing a server architecture in a system, thereby taking advantage of the advantages of the serverless architecture while effectively utilizing past development assets. The serverless architecture is advantageous for processes with large fluctuations in the number of requests from the outside. Specifically, the number of requests processed from cars, PCs, and smartphones, hereinafter referred to as cars, etc., varies greatly depending on the region, time of day, vehicle price range, etc. On the other hand, the number of requests processed from OTA operators, OEM back offices, and key management centers, hereinafter referred to as OTA operators, etc., is smaller than the number of requests from cars, etc., and the fluctuations in the number of requests tend to be small.

[0132] Therefore, in the seventh embodiment, a serverless architecture is adopted for processing based on requests from vehicles, etc., and a server architecture is adopted for processing based on requests from OTA operators, etc. Note that details of the operation when the OTA center is configured with a serverless architecture are omitted since they have been described in the above embodiments. Also, details of modules that adopt the server architecture are omitted since they are described in, for example, JP 2020-132042 A.

[0133] Next, the seventh embodiment will be described with reference to Fig. 43, mainly focusing on the differences from the sixth embodiment. The differences from the sixth embodiment are that the compute service processing unit 15E is deleted and integrated into the compute service function unit 14F, and that an operation and service infrastructure 46 is added as a module that employs a server architecture.

[0134] FIG. 44 shows an example of the center device 1E shown in FIG. 43 configured using the AWS cloud. · Amazon API Gateway: Equivalent to API Gateway section 11E. · AWS Lambda: Corresponds to Compute Service Functions 12E, 14F, 20E, and 45. · AWS Step Functions: Equivalent to the compute service function part 14F. SQS: corresponds to the queuing buffer unit 13E. Dynamo DB: corresponds to the database units 16E and 41E and the compute service function unit 42E. In the sixth embodiment, AWS Fargate is provided as the compute service processing unit 15E, but in the seventh embodiment, AWS Lambda is provided as the compute service function unit 14F.

[0135] Next, the operation of the seventh embodiment will be described. When the car, PC, smartphone, and OTA operator make a request to the OTA center, or when the OTA center responds to the car, PC, smartphone, and OTA operator, the request is made via the API gateway unit 11E. When the OEM back office makes a request to the OTA center, or when the OTA center returns a response to the OEM back office, the request is made via the API gateway unit 22. The API gateway unit 11E interprets, for example, a part of the content of the received information in response to the received request, and determines whether to pass the information to the compute service function unit 12E or to the operation and service platform 46. Similarly, the API gateway unit 22 interprets, for example, a part of the content of the received information in response to the received request, and determines the next request destination. The part of the content of the received information is, for example, information indicating the sender or information indicating the transmission content.

[0136] <Receive vehicle configuration information → Send job ID and campaign information> <Data access from the car → Delivery package sent from CDN to the car> These processes are similar to those in the sixth embodiment.

[0137] <Register campaign information → Register distribution package to CDN distribution unit 21> <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 involve interactions between the OTA operator and the OTA center, and are handled by modules that employ a server architecture.

[0138] <Registering software update data> This process involves interaction between the OEM back office and the OTA center, and is handled by a module that employs a server architecture.

[0139] As described above, according to the seventh embodiment, in addition to the effects obtained in the sixth embodiment, it is possible to effectively utilize development products such as programs and modules that have been developed on the premise of a server architecture, and at the same time, to obtain the benefits of a serverless architecture. This provides effects such as reduction in development costs and shortening of development time.

[0140] (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.

[0141] Below are some examples of the features of serverless architecture. Serverless architecture is an event-driven architecture where services are loosely coupled. Loose coupling means that services have low dependency on each other. Furthermore, servers are stateless, and processes and functions must be designed so that they do not have an internal state. In serverless architecture, requests must be connected in a stateless manner from one service to the next. Serverless architecture is designed to allow resources to be changed flexibly in response to changes in system usage and load. In this way, designing a serverless architecture requires satisfying matters that are not considered in the design of a server architecture. Therefore, a system that adopts a serverless architecture cannot be built based on software system configuration, design, specifications, etc. that assume a server architecture.

[0142] 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.

[0143] 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.

[0144] 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 mounted in a vehicle and to transmit update data to the vehicle via 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 notification 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 that realizes the functions of the campaign determination unit, the status management unit, and the campaign generation unit employs the serverless architecture.

2. A plurality of functions are executed by an application program to manage data to be written to an electronic control unit mounted in a vehicle and to transmit update data to the vehicle via wireless communication, An application program for realizing 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 notification 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 that realizes the functions of the campaign determination unit, the status management unit, and the campaign generation unit employs the serverless architecture.

3. The application program a first compute service unit (14) that transfers vehicle configuration information received from the vehicle via a gateway unit (11) to the campaign determination unit; a second compute service unit (15) that serves as the campaign determination unit and the campaign generation unit and determines whether or not there is campaign information for the vehicle based on the vehicle configuration information, and generates campaign notification information for the vehicle if the campaign information is present; a database unit (41) for managing a generation state of the campaign notification information, 3. The center device according to claim 1 or 2, wherein the first compute service unit registers the generation status of the campaign notification information in the database unit in accordance with the contents of the vehicle configuration information, and selects and launches an application program possessed by the second compute service unit.

4. a package distribution unit (15) that distributes to the vehicle a package including update data to be distributed to the vehicle; The package distribution unit distributes the update package linked to the campaign information by transferring it to a network distribution unit (21); 4. The center device according to claim 3, wherein an application program that realizes the function of the package distribution unit employs the serverless architecture.

5. 5. The center device according to claim 4, wherein the application program that realizes the function of the package distribution unit includes a third compute service unit (15) that transfers a received update package to the network distribution unit.

6. a campaign registration section (15) for registering campaign information on vehicle configuration information and update data for the vehicle, and update data to be distributed together with the campaign information; 2. The center device according to claim 1, wherein an application program that realizes the function of the campaign registration unit employs the serverless architecture.

7. The application program realizing the function of the campaign registration unit includes a fourth compute service unit (15) that registers the campaign information in a database and also registers the update data in a file storage unit (17); a fifth compute service unit (12) that transfers the received campaign information to the fourth compute service unit; a gateway unit (11) that transfers campaign information to the fourth compute service unit when a registration request for the campaign information is input by either an operation person or a manufacturing information management system; 7. The center device according to claim 6, wherein the fourth compute service section selects and starts an application program included in the fifth compute service section in accordance with the content of the campaign information.

8. A package generating unit (23) that generates a package including update data to be distributed to the vehicle, The package generation unit processes the received update data into an update package in a format that can be interpreted by a master device that is mounted on the vehicle and transfers the update data to an electronic control device that is to be updated; 8. The center device according to claim 7, wherein an application program that realizes the function of the package generation unit employs the serverless architecture.

9. a data management unit (24) that transfers the vehicle configuration information and corresponding update data registered in the file storage unit to the package generation unit in response to a request from the package generation unit, 9. The center device according to claim 8, wherein an application program that realizes the function of the data management unit employs the serverless architecture.

10. 2. The center device according to claim 1, wherein said status management section (12A) assigns a job number to a request received from the outside and also assigns status information indicating whether said request is being processed or has been completed.

11. 11. The center device according to claim 10, wherein the campaign transmission unit (11A) assigns the job number when transmitting a response to the request to the outside.

12. The application program includes a destination management unit (12B, 20B, 42, 43) that manages to which external party the campaign notification information should be distributed, 12. The center device according to claim 11, wherein an application program that realizes the function of the distribution destination management unit employs the serverless architecture.

13. A database unit (41) for managing a generation state of the campaign notification information, When the delivery destination management unit (20B) receives a request to which the job number is assigned from the outside, it assigns a connection number linked to the job number and registers it, The status management unit (42, 43) refers to the database unit, and when there is a request whose processing has been completed, identifies an external device to which a response is to be sent based on a connection number corresponding to the job number of the request, The center device according to claim 12 , wherein the campaign transmission unit transmits a response to the specified external party.

14. 11. The center device according to claim 10, wherein the external party is an in-vehicle device or an operation staff member.

15. the application program includes a processing capacity adjustment unit (44) that, when checking a processing load of a second compute service unit that generates campaign notification information for the vehicle and the number of pieces of vehicle configuration information received from the vehicle, determines whether or not it is necessary to increase or decrease the processing capacity of the second compute service unit, and increases or decreases the processing capacity of the second compute service unit as necessary; The center device according to claim 3 , wherein the processing capacity adjustment unit employs the serverless architecture.

16. The application program includes an information control unit (45) that includes access control information in information for acquiring the update package linked to the campaign information; a network distribution unit (18E, 21E) that performs access control by confirming that the access from the vehicle includes the access control information, The center device according to claim 4 , wherein the information control unit and the network distribution unit employ the serverless architecture.

17. 17. The center device according to claim 16, wherein the information control unit checks whether the validity period of the access control information has expired, and if the validity period has expired, generates access control information updated to a new validity period.

18. A method for managing data to be written to an electronic control device mounted in a vehicle and transmitting update data to the vehicle by wireless communication, the method comprising the steps of: 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, receiving vehicle configuration information from the vehicle and determining whether or not there is campaign information for the vehicle; If the campaign information is available, generate campaign notification information for the vehicle; managing a generation state of the campaign notification information, and distributing the campaign notification information to a vehicle in accordance with the generation state; A method for distributing campaign notification information that employs the serverless architecture, wherein an application program that realizes the functions of determining whether or not the campaign information exists, managing the generation status of the campaign notification information, and generating the campaign notification information is provided.

19. A method for managing data to be written to an electronic control device mounted in a vehicle and transmitting update data to the vehicle by wireless communication, the method comprising the steps of: An application program for realizing 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, receiving vehicle configuration information from a vehicle and determining whether or not there is campaign information for the vehicle; If the campaign information is available, generate campaign notification information for the vehicle; managing a generation state of the campaign notification information, and distributing the campaign notification information to a vehicle in accordance with the generation state; A method for distributing campaign notification information that employs the serverless architecture, wherein an application program that realizes the functions of determining whether or not the campaign information exists, managing the generation status of the campaign notification information, and generating the campaign notification information is provided.

Images