Center Device

Abstract

In one embodiment of the present disclosure, an OTA center 1 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. At that time, an application program that executes at least some of the functions employs a server-less architecture in which: the application program is started up when triggered by the occurrence of an event; a resource is dynamically allocated to the execution of the application program code by means of an on-demand scheme; and when execution of the code has been completed, the resource allocated to the application program is released.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2021-176558 filed on October 28, 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 in a vehicle. [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. 24, for example, 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 an application program on the assumption that a server is used is called a "server architecture." In other words, in a server architecture, resources are always assigned to an application program, and the program is executed as a resident process.

[0006] However, as shown in Fig. 25, 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, due to regulations, a center device compatible with connected cars must be installed in each country. Therefore, if the same scale system is built for each country, there will be a lot of waste in the cost of operating servers in areas with few vehicles (see Figure 26). The present invention has been made in view of the above circumstances, and an object of the present invention is to provide 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. [Brief description of the drawings]

[0010] 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 registration of case information to generation of 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 illustrating 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 diagram showing a state of data distribution to each queue in a queuing buffer unit in the second embodiment; [Figure 14] FIG. 14 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information. [Figure 15] FIG. 15 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information in the third embodiment. [Figure 16] FIG. 16 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information in the fourth embodiment. [Figure 17] FIG. 17 is a diagram showing a state of data distribution to each queue in a queuing buffer unit in a fifth embodiment; [Figure 18]FIG. 18 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information. [Figure 19] FIG. 19 is a functional block diagram showing a configuration of an OTA center according to the sixth embodiment. [Figure 20] FIG. 20 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information. [Figure 21] FIG. 21 is a functional block diagram showing a configuration of an OTA center in the eighth embodiment; [Figure 22] FIG. 22 is a flowchart showing a part of a process from receiving vehicle configuration information to transmitting campaign information. [Diagram 23] FIG. 23 is a diagram showing an example in which the function of the OTA center is realized by applying AWS in the ninth embodiment. [Figure 24] FIG. 24 is a functional block diagram assuming that the functions of the OTA center are configured mainly by applying a server architecture. [Diagram 25] FIG. 25 is a diagram showing server access trends by time period in a connected car service. [Figure 26] FIG. 26 shows the difference in the number of cars sold in each region. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0012] When the common system 3 generates a package, necessary data is transmitted and received between the common system 3 and an OEM (Original Equipment Manufacturer) back office 4, which is an external server system, and a 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. 24, 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.

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

[0014] An API (Application Programming Interface) gateway unit (1) 11 of the distribution system 2 performs wireless communication with the cars 31 and the OTA operator 34. Data received by the API gateway unit 11 is transferred in sequence to a compute service function unit (1) 12, a queuing buffer unit 13, a compute service function unit (2) 14, and a compute service processing unit (1) 15. The compute service function unit 12 accesses a database unit (1) 16. The compute service processing unit 15 accesses file storage units (1) 17 and (2) 18 and a database unit (2) 19. The database unit 19 stores campaign information, which is software update information corresponding to the cars 31 that require program updates.

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

[0016] 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 a database unit (3) 25 and a file storage unit (3) 26. The compute service function unit 24 accesses the file storage unit 26 and a 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. In the illustrated configuration, for the sake of convenience, the transmission and reception of commands and data are shown by lines. However, even if they are not shown by lines, it is possible to call the processing unit, function unit, and management unit, and to access the database unit and storage unit.

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

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

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

[0020] 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. · AWS Fargate: Compute Service Functions Part 14 and It corresponds to the compute service processing unit 15 . · Amazon S3: corresponds to file storage units 17, 18 and 26. ·Amazon Aurora: corresponds to database parts 19, 25 and 27. Incidentally, CDN77 corresponds to the CDN distribution unit 21, which is a service provided by CDN77 Inc. This may be replaced with the Amazon CloudFront service provided by AWS.

[0021] Furthermore, the CDN distribution unit 21 is not limited to CDN77 provided by CDN77 Inc. or Amazon CloudFront service provided by AWS, but corresponds to any service or server that realizes a content delivery network. Furthermore, AWS (Amazon Web Service) cloud is an example of a cloud service that provides a serverless architecture. In the embodiments, the configurations described and illustrated are appropriately changed depending on the functions provided by the cloud service.

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

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

[0024] 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. Each of the above processes will now be described in detail.

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

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

[0027] 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). 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, and a container application related to the generation of a package. The compute service function unit 14 interprets the information passed to it and starts up the corresponding container application.

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

[0029] 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 but it is incomplete, the compute service processing unit 15 generates campaign information to be distributed to the car 31 by referring to the database unit 19 (S9). An incomplete form is, for example, a state in which information necessary for distribution to the car 31 is missing. Here, the compute service processing unit 15 is an example of a campaign determination unit and a campaign generation unit. Furthermore, the compute service function unit 14 corresponds to a first compute service unit, and the compute service processing unit 15 corresponds to a second compute service unit. In step S9, if there is campaign information and all the information necessary for distributing the information to the car 31 is available, the process proceeds to step S10.

[0030] The compute service processing unit 15 starts the compute service function unit 20 and passes the generated campaign information (S10). At this point, the compute service processing unit 15 ends the processing and releases resources such as the CPU and memory that were occupied to perform that processing (S11). If there is no campaign in step S8, 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.

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

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

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

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

[0035] When the above-mentioned certain period 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 to the compute service function unit 14 (S26). The compute service function unit 14 interprets part of the content of the passed campaign information, and when it starts a container application of the compute service processing unit 15 that can execute appropriate processing, passes the campaign information to the compute service processing unit 15 (S27). The compute service function unit 14 is an example of a campaign registration unit, and corresponds to a sixth compute service unit.

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

[0037] 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. The origin server is a server in which original data exists. In this embodiment, the file storage unit 18 stores all of the software packages to be updated and URL information for downloading them.

[0038] <Data access from the car → Delivery package sent from CDN to the car> 6, the car 31, more specifically, the OTA master consisting of a DCM (Data Communication Module) and a central ECU mounted on the car 31, accesses the CDN distribution unit 21 based on the download URL information included in the campaign information (S41). The CDN distribution unit 21 determines whether or not the software package requested by the car 31 is held in its own cache memory (S42). If the software package is held in the cache memory, the CDN distribution unit 21 transmits the software package to the car 31 (S43).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0054] In addition, the queuing buffer unit 13 accumulates campaign information and case information for a certain period of time, just like 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. Furthermore, the queuing buffer unit 13 may store the vehicle configuration information, the campaign information, and the case information in one queuing buffer, or may store each type of information in a different queuing buffer unit 13.

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

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

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

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

[0059] 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. As shown in Fig. 13, the share of the number of cars varies depending on the price range of the cars 31, with the share of high-end models being low and the share of mid-range and low-end models being high. Therefore, in the queuing buffer unit 13A, queues are divided according to the price range of the cars 31, and OTA processing for high-end models is preferentially executed.

[0060] <Receive vehicle configuration information → Send campaign information> As shown in Fig. 14, when steps S1 and S2 are executed, the compute service function unit 12 checks the database unit 16 to confirm the VIN of the car 31 included in the vehicle configuration information, checks the price table based on the VIN, and identifies a queue in the queuing buffer unit 13A that stores the vehicle configuration information. For example, a high-class vehicle is queue A, a middle-class vehicle is queue B, and a low-class vehicle is queue C (S91). The compute service function unit 12 is an example of an access buffer control unit and a queuing buffer control unit. Alternatively, the vehicle configuration information may include information indicating a price range.

[0061] The compute service function unit 12 inputs the passed vehicle configuration information to the queuing buffer unit 13A so that it is stored in the specified queue (S92). The queuing buffer unit 13A accumulates the passed vehicle configuration information for a fixed period of time, and the fixed period is set for each queue. For example, the period is 100 ms for queue A, 1 second for queue B, and 3 seconds for queue C (S91). Then, steps S5 to S15 are executed in the same manner as in the first embodiment. The accumulation periods by the queuing buffer unit 13A are set to be longer in the order of queue A, queue B, and queue C.

[0062] As described above, according to the second embodiment, even when the embodiment is applied to a large-scale vehicle fleet of tens of millions of vehicles, the vehicle configuration information of high-class cars 31, which have a low share and low traffic of vehicle configuration information, is preferentially processed, thereby preventing a decrease in the quality of connected services. In that sense, this is a kind of QoS (Quality of Service) control.

[0063] Third embodiment In the third embodiment, instead of the price range of the vehicle in the second embodiment, a timeout time in the queuing buffer unit 13A is set in the vehicle configuration information of each vehicle. The timeout time is an index for the time it takes for data input to the queuing buffer unit 13A to be output through the buffer unit 13A. Therefore, as shown in FIG. 15, in step S94 instead of step S91, the compute service function unit 12 checks the database unit 16 to confirm the timeout time of each car 31 included in the vehicle configuration information, and specifies the queue of the queuing buffer unit 13A that stores the information. The timeout time here does not need to be a specific numerical value, and if the vehicle is "short", it is queue A, if the vehicle is "normal", it is queue B, and if the vehicle is "long", it is queue C. The process thereafter is the same as that of the second embodiment. The timeout time may be a predetermined numerical value such as 100 ms, 1 second, or 3 seconds.

[0064] (Fourth embodiment) In the fourth embodiment, instead of the timeout period setting in the third embodiment, the priority of the delivery order is set in the vehicle configuration information of each vehicle based on the importance and urgency of the campaign, the presence or absence of a paid application, and the like, for example, as "high", "normal", or "low". Therefore, as shown in FIG. 16, in step S95 instead of step S94, the compute service function unit 12 checks the database unit 16 to confirm the priority of the delivery order of each car 31 included in the vehicle configuration information, and identifies the queue in the queuing buffer unit 13A that stores the information. If the vehicle is "high", it is queue A, if the vehicle is "normal", it is queue B, and if the vehicle is "low", it is queue C. The subsequent processing is the same as that in the third embodiment.

[0065] In other words, in the fourth embodiment, the priority of the delivery order is set, for example, as "high," "normal," or "low," based on the attributes of the campaign. The attributes of the campaign are, for example, at least one of the conditions such as the importance or urgency of the campaign, or whether or not the content is chargeable.

[0066] Fifth embodiment In the fifth embodiment, as in the second embodiment, the price table of the car 31 included in the vehicle configuration information is checked to identify a queue in which to store the information. In addition, when the vehicle configuration information can be transmitted not only from the car 31 but also from an information communication terminal such as a smartphone 32 or a personal computer (PC) 33, the compute service function unit 12 identifies the transmission source and identifies the queue in the queuing buffer unit 13B according to the transmission source. The compute service function unit 12 is an example of a transmission source determination unit.

[0067] Regarding the communication processing of the vehicle configuration information whose transmission source is the car 31, if it is assumed that the processing is performed in the background as in the embodiment described later, the response speed from the OTA center 1 is not a major issue. On the other hand, regarding the communication processing of the vehicle configuration information whose transmission source is the smartphone 32 or the PC 33, since the processing is performed in the foreground, a slow response speed will be a problem in terms of UX (User eXperience).

[0068] 17 and 18, in the fifth embodiment, for example, in step S96 instead of step S95 in the fourth embodiment, the compute service function unit 12 checks the database unit 16 to identify whether the vehicle configuration information is transmitted from the car 31, the smartphone 32, or the PC 33. At the same time, the price table of the car 31 is checked to identify the source. In the queuing buffer unit 13B, there are a queue group V of the car 31, a queue group S of the smartphone 32, and a queue group P of the PC 33, and each queue group has queues A to C. The allocation of queues A to C according to the price table is the same as in the second embodiment.

[0069] In step S97, which replaces step S93, the process of storing the vehicle configuration information passed to the queuing buffer unit 13B for a certain period of time is similar. However, the waiting time setting for the queue groups V, S, and P differs depending on the combination of the transmission source and the price table. For example, it is set as follows. <Queue Group V> A: 100ms B:1s C:3s <Queue Group S> A: 50 ms B: 70 ms C: 90 ms <Queue Group P> A: 100ms B: 200 ms C: 300ms

[0070] As described above, according to the fifth embodiment, by changing the waiting time setting of each queue in the queuing buffer unit 13B depending on the sender of the vehicle configuration information and the price table of the car 31, it is possible to provide a high-quality OTA service that enhances the user's value experience, or so-called UX.

[0071] Sixth embodiment In the serverless architecture, resources are allocated when an event occurs, so startup takes a relatively long time. Therefore, in the sixth embodiment, the compute service function units 12, 14, 20, and 24 and the compute service processing units 15 and 23 that employ the serverless architecture are placed in a warm standby state, thereby shortening the startup time.

[0072] As one method for achieving this, in an OTA center 1A of the sixth embodiment shown in FIG. 19, a compute server unit 28 is added to a distribution system 2A. The compute server unit 28 employs a server architecture, and transmits, for example, a ping command to the compute service function units 12, 14, 20, and 24 and the compute service processing units 15 and 23 at regular intervals, for example, at one-minute intervals, as a command for checking whether communication is possible (see FIG. 20, S98(1)). This makes it possible to maintain each of the compute service function units and the compute service processing units in a warm standby state. The compute server unit 28 is an example of a reserve state setting unit.

[0073] The method shown in step S98 (2) is for the case where AWS is applied, and a warm standby state can be established by reserving and temporarily allocating a plurality of resources in advance for the compute service function units 12, 14, 20, and 24 and the compute service processing units 15 and 23. The warm standby state can also be established by setting provisioned concurrent execution for the compute service function units 12, 14, 20, and 24.

[0074] Seventh embodiment In an OTA center 1B of the seventh embodiment shown in Fig. 21, a compute server unit 29 is added to a distribution system 2B. The compute server unit 29 employs a server architecture, and inputs and outputs data between the API gateway unit 11, the file storage unit 17, and the database unit 19. The compute server unit 29 is an example of an information processing server.

[0075] As shown in FIG. 22, when the API gateway unit 11 receives an HTTPS request for vehicle configuration information from the car 31, the smartphone 32, or the PC 33 (S121), it performs a source allocation process based on the URL information included in the HTTPS request (S122).

[0076] If the sender is the car 31, the process from step S22 onwards is executed as in the first embodiment. From step S25 onwards, as in the first embodiment, the API gateway unit 11 sends an HTTPS response including the campaign information to the car 31. If the sender is the smartphone 32 or the PC 33, the API gateway unit 11, which is an example of an information processing control unit, passes the received vehicle configuration information to the compute server unit 29 (S123). The compute server unit 29 generates campaign information for software updates to be distributed to the car 31 by referring to the database unit 19 (S124). Next, the compute server unit 29 passes the generated campaign information to the API gateway unit 11 to distribute it to the corresponding smartphone 32 or PC 33 (S125). Then, the API gateway unit 11 sends an HTTPS response of the campaign information to the smartphone 32 or the PC 33 (S126).

[0077] When the sender is the car 31, the compute service function unit 12 and the like processes the data, whereas when the sender is the smartphone 32 or PC 33, the compute server unit 29 processes the data. When the sender is the car 31, the processing is performed using a serverless architecture, so the response speed is slower than in the case of the server architecture, but the running costs required for the infrastructure can be significantly reduced. Also, when the sender is the smartphone 32 or PC 33, the processing is performed using the server architecture, so the response speed can be maintained, and an improvement in the value experience of the user can be realized.

[0078] Eighth embodiment The eighth embodiment shown in Fig. 23 shows a variation of the OTA center configured using AWS shown in Fig. 2 of the first embodiment. The main difference from Fig. 2 is that part of the function of "AWS Fargate" is assigned to "Elastic Load Balancing", so that "Elastic Load Balancing" corresponds to the compute service function unit 14 and "AWS Fargate" corresponds to the compute service processing unit 15.

[0079] (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 command that the compute server unit 28 periodically transmits is not limited to a ping command, but may be any command that checks whether communication is possible. The portable information terminal is not limited to a smartphone or a personal computer.

[0080] 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 internal state. In serverless architecture, requests must be connected statelessly 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.

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

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

[0083] 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 center device that employs a serverless architecture in which resources allocated to the application program are released when the execution of the code is completed.

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 center device that employs a serverless architecture in which resources allocated to the application program are released when the execution of the code is completed.

3. 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 campaign transmission unit (11) that delivers the campaign notification information to a vehicle; 3. The center device according to claim 1, wherein an application program that realizes the functions of the campaign determination unit and the campaign generation unit employs the serverless architecture.

4. 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, as the campaign determination unit and the campaign generation unit, 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; 4. The center device according to claim 3, wherein the first compute service unit selects and starts an application program included in the second compute service unit in accordance with the contents of the vehicle configuration information.

5. The first compute service unit is started in response to an event that the vehicle configuration information is received, 5. The center device according to claim 4, wherein the second compute service unit is started in response to a start instruction from the first compute service unit as an event.

6. 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.

7. 7. The center device according to claim 6, wherein an 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.

8. 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; 4. The center device according to claim 3, wherein an application program that realizes the function of the campaign registration unit employs the serverless architecture.

9. An application program for implementing the function of the campaign registration unit includes: a gateway unit (11) that transfers the campaign information to a fifth compute service unit when a registration request for the campaign information is input; a fifth compute service unit (12) that transfers the received campaign information to a sixth compute service unit; a sixth compute service unit (14) that selects and starts an application program owned by the fourth compute service unit according to the content of the campaign information; 9. The center device according to claim 8, further comprising 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.

10. The fifth compute service unit is activated when the campaign information is received as an event, The sixth compute service unit is started in response to the start instruction as an event, and receives campaign information; 10. The center device according to claim 9, wherein the fourth compute service unit is started in response to a start instruction from the sixth compute service unit as an event.

11. 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; 10. The center device according to claim 9, wherein an application program that realizes the function of the package generation unit employs the serverless architecture.

12. 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, 12. The center device according to claim 11, wherein an application program that realizes the function of the data management unit employs the serverless architecture.

13. The center device according to claim 3, further comprising an access buffer control unit (13) that buffers and stores the vehicle configuration information received from the vehicle for a certain period of time before transferring the vehicle configuration information to the campaign determination unit, and transfers all of the vehicle configuration information received within the certain period of time to the campaign determination unit in one go.

14. The access buffer control unit includes a plurality of queuing buffers (13A) to which priority is assigned in a processing order for each vehicle model; a queuing buffer control unit (12) that interprets the vehicle model based on the vehicle configuration information and stores the vehicle model in a corresponding queuing buffer; 14. The center device according to claim 13, wherein an application program that realizes the function of the queuing buffer control unit employs the serverless architecture.

15. the access buffer control unit includes a plurality of queuing buffers each having a priority order according to a length of a timeout period, the time being an index of a time period from when input data is output from the access buffer control unit, the queuing buffers being set for each vehicle model; a queuing buffer control unit that interprets the length of the timeout period based on the vehicle configuration information and stores the timeout period in a corresponding queuing buffer; 14. The center device according to claim 13, wherein an application program that realizes the function of the queuing buffer control unit employs the serverless architecture.

16. The access buffer control unit includes a plurality of queuing buffers to which priority is assigned in a processing order according to an attribute of the campaign information; a queuing buffer control unit that interprets an attribute of the campaign information based on the vehicle configuration information and stores the attribute in a corresponding queuing buffer; 14. The center device according to claim 13, wherein an application program that realizes the function of the queuing buffer control unit employs the serverless architecture.

17. When the vehicle configuration information is transmitted from an information communication terminal other than the vehicle, A transmission source determination unit (12) that determines a transmission source of the vehicle configuration information, The access buffer control unit includes a plurality of queuing buffers to which priority is assigned in a processing order according to the transmission source; a queuing buffer control unit that determines the transmission source based on the vehicle configuration information and stores the transmission source in a corresponding queuing buffer; 14. The center device according to claim 13, wherein an application program that realizes the function of the queuing buffer control unit employs the serverless architecture.

18. 18. The center device according to claim 17, wherein the information communication terminal is a smartphone (32) or a personal computer (33).

19. The center device according to claim 3, further comprising a reserve state setting unit (28) that sets resources to be used in a reserved state before at least one of the application programs employing the serverless architecture is launched.

20. 20. The center device according to claim 18, wherein the reserve state setting unit transmits a command to the target application program periodically to check whether communication is possible.

21. 21. The center device according to claim 20, wherein the command is a Ping command.

22. When the vehicle configuration information is transmitted from an information communication terminal other than the vehicle, a transmission source discrimination unit (12) for discriminating a transmission source of the vehicle configuration information; An information processing server (29) that processes the vehicle configuration information by adopting a server architecture in which resources are always allocated and the server architecture is executed as a resident process; 4. The center device according to claim 3, further comprising an information processing control section (11) for causing the information processing server to process the received vehicle configuration information if the transmission source is the information communication terminal.

23. 23. The center device according to claim 22, wherein the information communication terminal is a smartphone (32) or a personal computer (33).

Images