WO2023074091A1 - センタ装置 - Google Patents

センタ装置 Download PDF

Info

Publication number
WO2023074091A1
WO2023074091A1 PCT/JP2022/031103 JP2022031103W WO2023074091A1 WO 2023074091 A1 WO2023074091 A1 WO 2023074091A1 JP 2022031103 W JP2022031103 W JP 2022031103W WO 2023074091 A1 WO2023074091 A1 WO 2023074091A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
vehicle
information
campaign
compute service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2022/031103
Other languages
English (en)
French (fr)
Inventor
英朗 吉見
雄三 原田
那央 小嶋
真晃 安部
古都 東松
一浩 上原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Corp
Original Assignee
Denso Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Denso Corp filed Critical Denso Corp
Priority to CN202280071974.1A priority Critical patent/CN118159942A/zh
Priority to DE112022005159.0T priority patent/DE112022005159T5/de
Priority to JP2023556140A priority patent/JP7662046B2/ja
Publication of WO2023074091A1 publication Critical patent/WO2023074091A1/ja
Priority to US18/645,001 priority patent/US20240272896A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Definitions

  • the present disclosure relates to a center device that manages data to be written to an electronic control device mounted on a vehicle.
  • Patent Literature 1 discloses a technique for distributing an ECU update program from a server to an in-vehicle device by OTA (Over The Air) and rewriting the update program on the vehicle side.
  • Patent Document 1 An attempt to actually configure the center device disclosed in Patent Document 1 results in, for example, the configuration shown in FIG. assumed to be realized.
  • server architecture an environment or configuration in which application programs are executed on the premise of using a server.
  • application programs are always allocated resources and run as resident processes.
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to construct a center device for wireless communication with a plurality of vehicles at a lower cost.
  • an application program executes a plurality of functions for managing data to be written to an electronic control device mounted on a vehicle and transmitting updated data to the vehicle by wireless communication. do. At that time, an application program that implements at least a part of the functions is activated by the occurrence of an event, and resources are dynamically allocated for the execution of the code of the application program by an on-demand method, and the code is executed. Adopt a serverless architecture in which the resources allocated to the application program are released once the is completed.
  • FIG. 1 is a functional block diagram showing the configuration of the OTA center in the first embodiment
  • FIG. 2 is a diagram showing an example of implementing the functions of the OTA center by applying AWS.
  • FIG. 3 is a flow diagram schematically showing the processing performed between the vehicle-side system and the OTA center
  • FIG. 4A is a flowchart (part 1) showing processing from reception of vehicle configuration information to transmission of campaign information
  • FIG. 4B is a flowchart (part 2) showing processing from reception of vehicle configuration information to transmission of campaign information
  • FIG. 1 is a functional block diagram showing the configuration of the OTA center in the first embodiment
  • FIG. 2 is a diagram showing an example of implementing the functions of the OTA center by applying AWS.
  • FIG. 3 is a flow diagram schematically showing the processing performed between the vehicle-side system and the OTA center
  • FIG. 4A is a flowchart (part 1) showing processing from reception of vehicle configuration information to transmission of campaign information
  • FIG. 4B is a flowchart (part 2) showing processing from
  • FIG. 5A is a flowchart (part 1) showing processing from registration of campaign information to registration of distribution packages in the CDN distribution unit
  • FIG. 5B is a flowchart (part 2) showing processing from registration of campaign information to registration of distribution packages in the CDN distribution unit
  • FIG. 6 is a flowchart showing processing from data access by the car to package distribution by the CDN distribution unit.
  • FIG. 7 is a flowchart showing registration processing of software update data
  • FIG. 8A is a flowchart (Part 1) showing processing from registration of item information to generation of a package
  • FIG. 8B is a flowchart (part 2) showing processing from registration of item information to generation of a package
  • FIG. 9 is a flowchart (part 3) showing processing from registration of item information to generation of a package
  • FIG. 10 is a diagram for explaining the effect of accumulating data in the queuing buffer unit for a certain period of time and then passing it to the compute service function unit in the next stage.
  • FIG. 11 is a diagram for explaining the processing modes of the server model and the serverless model.
  • FIG. 12 is a diagram showing the running costs of the server model and the serverless model.
  • FIG. 13 is a diagram showing how data is distributed to each queue in the queuing buffer section in the second embodiment;
  • FIG. 14 is a flowchart showing part of the process from receiving vehicle configuration information to transmitting campaign information.
  • FIG. 15 is a flowchart showing part of the processing from reception of vehicle configuration information to transmission of campaign information in the third embodiment.
  • FIG. 16 is a flowchart showing part of the processing from reception of vehicle configuration information to transmission of campaign information in the fourth embodiment.
  • FIG. 17 is a diagram showing how data is distributed to each queue in the queuing buffer unit in the fifth embodiment;
  • FIG. 18 is a flowchart showing part of the process from receiving vehicle configuration information to transmitting campaign information;
  • FIG. 19 is a sixth embodiment and is a functional block diagram showing the configuration of the OTA center,
  • FIG. 20 is a flow chart showing part of the process from receiving vehicle configuration information to sending campaign information.
  • FIG. 21 is a functional block diagram showing the configuration of the OTA center in the eighth embodiment;
  • FIG. 22 is a flowchart showing part of the process from receiving vehicle configuration information to transmitting campaign information;
  • 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;
  • FIG. 24 is a functional block diagram assuming that the functions of the OTA center are mainly configured by applying the server architecture;
  • FIG. 25 is a diagram showing the trend of server access by time zone in the connected car service,
  • FIG. 26 is a diagram showing differences in the number of cars sold in each region.
  • an OTA center 1 which is a center device of the present embodiment, comprises a distribution system 2 and a common system 3.
  • a distribution package containing ECU update programs and data to be distributed to a vehicle 31 is generated and managed. is delivered to the car 31 by.
  • the OEM back office 4 comprises a first server 6 to a fourth server 9 and so on.
  • These servers 6 to 9 are similar to those shown in FIG. 24, and are systems for manufacturing information management system, customer management system, telematics contract, and SMS (Short Message Service) distribution, respectively.
  • the key management center 5 has a fifth server 10 which is a system for issuing and managing keys used for OTA.
  • the first server 6 to fifth server 10 employ the aforementioned server architecture, resources are always allocated to application programs, and the programs are executed as resident processes.
  • the API (Application Programming Interface) gateway section (1) 11 of the distribution system 2 performs wireless communication with the car 31 and the OTA operator 34 .
  • the data received by the API gateway unit 11 is transferred 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 in sequence.
  • the compute service function part 12 accesses the database part (1) 16 .
  • the compute service processing unit 15 accesses the file storage units (1) 17 and (2) 18 and the database unit (2) 19 .
  • the database unit 19 stores campaign information, which is software update information corresponding to a car 31 that requires program update.
  • 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 OTA.
  • the CDN distribution unit 21 is an example of a network distribution unit.
  • the API gateway unit (2) 22 of the common system 3 communicates with the compute service processing unit 15 of the distribution system 2, the compute service processing unit (2) 23 and the compute service function unit (4) 24 provided in the common system 3, and data input. output.
  • 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 database unit (4) 27 .
  • the API gateway section 22 also accesses each of the servers 6 to 10 provided in the OEM back office 4 and the key management center 5 .
  • the transmission and reception of commands and data are indicated by lines for convenience of explanation. However, even if the line is not displayed, it is possible to call the processing part, the function part, the management part, and access the database part and the storage part.
  • the compute service function units 12, 14, 20 and 24 and the compute service processing units 15 and 23 employ a serverless architecture.
  • a "serverless architecture” is triggered by the occurrence of an event, and automatically allocates resources to the execution of application program code in an on-demand manner. When the execution of the code is completed, the allocated resources are automatically released.
  • serverless architecture is triggered by the occurrence of an event, dynamically allocates resources for the execution of application program code, and releases the allocated resources when the code execution is completed. be.
  • the resource is released dynamically when the code execution is completed.
  • the resource may be released immediately after the execution of the code is completed, or may be released after waiting for a predetermined period of time, such as 10 seconds, after the completion of execution.
  • FIG. 2 is an example of the case where the center device 1 shown in FIG. 1 is configured using the AWS (Amazon Web Service) cloud.
  • Amazon API Gateway corresponds to the API gateway units 11 and 22.
  • - AWS Lambda Corresponds to the compute service function units 12, 20, and 24.
  • Amazon Kinesis Corresponds to the queuing buffer unit 13 .
  • - AWS Fargate Corresponds to the compute service function unit 14 and the compute service processing unit 15 .
  • Amazon S3 Corresponds to the file storage units 17, 18 and 26.
  • Amazon Aurora Corresponds to the database units 19, 25 and 27.
  • the CDN 77 corresponds to the CDN distribution unit 21, and this is a service provided by CDN77. You can replace this with the Amazon CloudFront service provided by AWS.
  • the CDN distribution unit 21 is not limited to the CDN77 provided by CDN77 Inc. or the Amazon CloudFront service provided by AWS, but corresponds to any service or server that realizes a content delivery network.
  • the 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 modified as appropriate according to the functions provided by the cloud service.
  • 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.
  • a short message may be sent from the fourth server 9 to the vehicle targeted for the campaign, and the vehicle configuration information may be sent to the OTA center 1 using this short message as a trigger.
  • the vehicle configuration information is information about the hardware and software of the ECU installed in the vehicle.
  • the OTA center 1 checks whether or not there is campaign information applicable to the software update. Then, when there is corresponding campaign information, the campaign information is transmitted to the car 31.
  • - ⁇ Also when the vehicle configuration information is transmitted from the vehicle 31, the information is compared with the vehicle configuration information of the vehicle 31 held in the OTA center 1 side, and updated to the newer information. This is called vehicle configuration information synchronization processing.
  • the API gateway unit 11 receives an HTTPS (Hypertext Transfer Protocol Secure) request for vehicle configuration information from the vehicle 31 (S1).
  • the contents of the request are, for example, a VIN (Vehicle Identification Number), a hardware ID of each ECU, a software ID of each ECU, and the like.
  • VIN Vehicle Identification Number
  • the API gateway unit 11 activates the compute service function unit 12, it passes the received vehicle configuration information to the function unit 12 (S2).
  • 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 transferred vehicle configuration information for a certain period of time, for example, one second or several seconds (S4).
  • the compute service function unit 12 terminates the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S5).
  • the compute service function unit 12 may receive the TCP port number from the API gateway unit 11 and store it in the shared memory as necessary.
  • the queuing buffer unit 13 activates the compute service function unit 14, and transfers the vehicle configuration information accumulated within the predetermined 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 a part of the delivered vehicle configuration information, and when the container application of the compute service processing unit 15 that can execute appropriate processing is started, the vehicle configuration information is sent to the compute service processing unit 15. Pass (S7).
  • the container applications of the compute service processing unit 15 include a container application related to campaign information generation, a container application related to distribution package registration, and a container application related to package generation.
  • the compute service function unit 14 interprets the passed information and activates the corresponding container application.
  • a container is a container that is created as a logical partition on the host OS, and is a collection of libraries, programs, etc. necessary for running an application. To logically separate OS resources and share them among multiple containers.
  • An application that runs in a container is called a container app.
  • the compute service processing unit 15 accesses the database unit 19 and determines whether there is campaign information, which is software update information, corresponding to the transferred vehicle configuration information (S8). If there is campaign information and it is incomplete, the compute service processing unit 15 refers to the database unit 19 and generates campaign information to be delivered to the car 31 (S9). An incomplete form is, for example, a state in which information necessary for distribution to the car 31 is lacking.
  • the compute service processing unit 15 is an example of a campaign determination unit and a campaign generation unit.
  • the compute service function unit 14 corresponds to the first compute service unit, and the compute service processing unit 15 corresponds to the second compute service unit. In step S9, if there is campaign information and the information necessary for distribution to the car 31 is complete, the process proceeds to step S10.
  • the compute service processing unit 15 activates the compute service function unit 20 and delivers the generated campaign information (S10).
  • the compute service processing unit 15 terminates the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S11). If there is no campaign in step S8, after generating campaign information for notifying "no campaign" to be delivered to the car 31 (S12), the process proceeds to step S10.
  • step S ⁇ b>10 the compute service processing unit 15 passes to the compute service function unit 20 campaign information that notifies “there is a campaign” or campaign information that notifies “there is no campaign”.
  • the compute service function unit 20 passes the passed campaign information to the API gateway unit 11 in order to distribute it to the corresponding car 31 .
  • the compute service function unit 20 terminates the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S14).
  • the API gateway unit 11 transmits an HTTPS response including campaign information to the car 31 (S15).
  • Car 31 receives the HTTPS response containing the campaign information.
  • the API gateway section 11 is an example of a campaign transmission section.
  • the compute service function unit 20 acquires the TCP port number saved by the compute service function unit 12 from the shared memory as necessary, and distributes the HTTPS response to that TCP port number.
  • the request may be made to the API gateway unit 11 .
  • the OTA operator 34 transmits an HTTPS request for campaign information registration (S21).
  • the API gateway unit 11 activates the compute service function unit 12, it passes the received campaign information (S22).
  • 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).
  • the compute service function unit 12 terminates the processing and releases the resources such as the CPU and memory that have been occupied for 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.
  • the queuing buffer section 13 activates the compute service function section 14 and passes the campaign information accumulated within the constant period to the compute service function section 14 (S26).
  • the compute service function unit 14 interprets part of the content of the passed campaign information, and when the container application of the compute service processing unit 15 that can execute appropriate processing is started, the compute service function unit 14 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.
  • the compute service processing unit 15 registers the campaign information in the database unit 19 in order to associate the target vehicle included in the delivered campaign information with the software package to be updated (S28).
  • the compute service processing unit 15 also activates the compute service function unit 20 and passes a notification that the registration of the campaign information is 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.
  • the compute service processing unit 15 stores the update target software package and the download URL information in the file storage unit 18 (S31).
  • the compute service processing unit 15 terminates the processing and releases the resources such as the CPU and memory occupied for the processing (S32).
  • the file storage unit 18 then operates as an origin server for the CDN distribution unit 21 (S33).
  • the compute service processing unit 15 is an example of a package delivery unit and corresponds to a third compute service unit.
  • the origin server is a server where original data exists.
  • the file storage unit 18 stores all of the software package to be updated and the URL information for download.
  • the car 31 more specifically, the OTA master consisting of a DCM (Data Communication Module) and a central ECU mounted on the car 31, based on the download URL information included in the campaign information.
  • the CDN distribution unit 21 is accessed (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 it is held in the cache memory, the CDN distribution unit 21 transmits the software package to the car 31 (S43).
  • the CDN delivery section 21 requests the above software package from the file storage section 18, which is the origin server (S44). Then, the file storage unit 18 transmits the requested software package to the CDN distribution unit 21 (S45). The CDN distribution unit 21 holds the software package received from the file storage unit 18 in its own cache memory and also transmits it to the car 31 (S46).
  • the API gateway unit 22 receives a registration request for software update data and related information as an HTTPS request from the first server 6 of the OEM back office 4 (S51).
  • the API gateway section 22 activates the compute service function section 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).
  • the compute service function unit 24 updates the search table stored in the database unit 27 so that it can be referenced where the software update data and related information are stored (S54).
  • the compute service function unit 24 terminates the processing and releases the resources such as the CPU and memory occupied for the processing (S55).
  • the OTA operator 34 transmits an HTTPS request for item information to the API gateway unit 11 in order to register the item information (S61).
  • Item information is a collection of hardware information and software information of ECUs to which a certain distribution package can be applied.
  • the API gateway unit 11 activates the compute service function unit 12, it passes the received item information to the function unit 12 (S62).
  • the compute service function unit 12 passes the item information to the queuing buffer unit 13 (S63).
  • the queuing buffer unit 13 accumulates and buffers the passed item information for a certain period of time (S64).
  • the compute service function unit 12 terminates the processing and releases the resources such as the CPU and memory occupied for the processing (S65). Note that the compute service function unit 12 may receive the TCP port number from the API gateway unit 11 and store it in the shared memory as necessary.
  • the queuing buffer section 13 activates the compute service function section 14, and passes the item information accumulated within the fixed period of time to the compute service function section 14 (S66).
  • the compute service function unit 14 interprets part of the content of the passed item information, and when the container application of the compute service processing unit 15 that can execute appropriate processing is started, the compute service function unit 14 passes the item information to the compute service processing unit 15 ( S67).
  • the compute service processing unit 15 accesses the database unit 19 and activates the container application of the compute service processing unit 23 in order to generate a software package based on the software update target information included in the passed item information. , the software update target information is passed to the compute service processing unit 23 (S68). The compute service processing unit 15 ends the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S70).
  • the compute service processing unit 23 transmits an HTTPS request for software update data to the API gateway unit 22 based on the passed software update target information (S71).
  • the API gateway section 22 activates the compute service function section 24 and passes the software update data request (S72).
  • the compute service function unit 24 refers to the database unit 27 and acquires the path information of the file storage unit 26 in which the software update data is stored (S73).
  • the compute service function unit 24 accesses the file storage unit 26 based on the acquired path information and acquires software update data (S74). Then, in order to transmit the acquired software update data to the compute service processing unit 23, it is passed to the API gateway unit 22 (S75). The compute service function unit 24 ends the processing and releases the resources such as the CPU and memory occupied for the processing (S76).
  • the compute service function unit 24 is an example of a data management unit.
  • the API gateway section 22 sends a software update response HTTPS response including the software update data to the compute service processing section 23 (S77).
  • the compute service processing unit 23 refers to the database unit 25 to specify the structure of the software package of the target vehicle (S78). Then, the software update data is processed so as to match the structure of the specified software package to generate the 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.
  • the compute service processing unit 23 passes the path information of the file storage unit 26 in which the software package is stored to the API gateway unit 22 in order to transmit it to the compute service processing unit 15 (S81).
  • the compute service processing unit 23 ends the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S82).
  • the API gateway section 22 activates the compute service processing section 15 and passes the path information of the software package (S83).
  • the compute service processing unit 15 associates the passed software package path information with the item information, and updates the search table registered in the database unit 19 (S84).
  • the compute service processing unit 15 activates the compute service function unit 20 and passes the matter registration completion information (S85).
  • the compute service processing unit 15 ends the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S86).
  • the compute service function unit 20 passes the passed item registration completion information to the API gateway unit 11 in order to return it to the OTA operator 34 (S87).
  • the compute service function unit 20 ends the processing and releases the resources such as the CPU and memory that have been occupied for the processing (S88).
  • the API gateway unit 11 transmits an HTTPS response of item registration completion information to the OTA operator 34 (S89).
  • the compute service function unit 20 acquires the TCP port number saved by the compute service function unit 12 from the shared memory as necessary, and distributes the HTTPS response to that TCP port number.
  • the request may be made to the API gateway unit 11 .
  • the queuing buffer unit 13 accumulates the campaign information and item information for a certain period of time in the same manner as the vehicle configuration information, and then transfers them to the computing service function unit 14 at the next stage. reducing the consumption of processing resources.
  • the queuing buffer unit 13 may store vehicle configuration information, campaign information, and item information in one queuing buffer, or may store different queuing buffer units 13 for each type of information.
  • the application program and the server are always running with their resources occupied, and one server executes multiple processes.
  • the corresponding application program is started, and when the process ends, the execution of the program is stopped and deleted. be done. Therefore, at this point, the resources used for processing are released.
  • the fixed cost associated with the constant operation of the server is extra compared to the cost of the actual operation. Moreover, if the server is made redundant in advance, the cost will be further increased. On the other hand, if a serverless architecture is adopted as in the present embodiment, only the cost of actually operating will be borne, so the running cost of the infrastructure can be greatly reduced.
  • the OTA center 1 has a plurality of functions for managing data to be written to a plurality of ECUs mounted on the vehicle 31 and for transmitting update data to the vehicle 31 by wireless communication. Executed by the application program. At that time, an application program that implements at least some of the functions is activated when an event occurs, and resources are dynamically allocated for the execution of the application program code by the on-demand method. Once completed, it employs a serverless architecture that frees up the resources allocated to the application program.
  • a program that uses a serverless architecture dynamically allocates resources and starts the program each time an access from the car 31 occurs, and the resources are released when the code execution is completed. Therefore, compared to the case of adopting a server architecture that is executed as a resident process, the consumption of infrastructure computing resources can be saved, and as a result, the running cost of the infrastructure can be reduced.
  • 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, and based on that VIN, to identify the queue of 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 controller and a queuing buffer controller. Alternatively, information indicating the price range may be included in the vehicle configuration information.
  • the compute service function unit 12 inputs the delivered 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 transferred vehicle configuration information for a certain period of time, and the certain period of time is set for each queue. For example, the cue is 100 ms, the cue B is 1 second, and the cue C is 3 seconds (S91). Then, steps S5 to S15 are executed in the same manner as in the first embodiment.
  • the accumulation period of the queuing buffer unit 13A is set to be longer in the order of queue A, queue B, and queue C. As shown in FIG.
  • the vehicle configuration of the high-class car 31 with a low market share and low traffic of vehicle configuration information Prioritize information processing and prevent the quality of connected services from deteriorating. In that sense, this is a kind of QoS (Quality of Service) control.
  • QoS Quality of Service
  • the timeout period in the queuing buffer section 13A is set in the vehicle configuration information of each vehicle.
  • the timeout time is an index for the time until the data input to the queuing buffer section 13A is output via the buffer section 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 period of each car 31 included in the vehicle configuration information, A queue of the queuing buffer unit 13A that stores the information is specified.
  • the time-out time here does not need to be a specific numerical value, and queue A is for a "short” vehicle, queue B is for a "normal” vehicle, and queue C is for a "long” vehicle. do. Subsequent processing is the same as that of the second embodiment. Also, the timeout time may be a predetermined numerical value such as 100 ms, 1 second, or 3 seconds.
  • the priority of the distribution order is set based on the importance and urgency of campaigns, the presence or absence of billing applications, etc. in the vehicle configuration information of each vehicle. For example, “high”, “normal”, and “low” are set. 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 determine the priority of the delivery order of each car 31 included in the vehicle configuration information. Then, the queue of the queuing buffer unit 13A that stores the information is specified. If the vehicle is "expensive", it is cue A, if it is "normal”, it is cue B, and if it is "low”, it is cue C. After that, the processing is the same as that of the third embodiment.
  • the priority of the distribution order is set, for example, "high”, “normal”, “low” based on the attributes of the campaign.
  • Campaign attributes are, for example, at least one or more of conditions such as the importance and urgency of the campaign, and whether or not the content is chargeable content.
  • the price table of the car 31 included in the vehicle configuration information is confirmed to identify the queue in which the information is stored.
  • vehicle configuration information can be transmitted from a smartphone 32 or an information communication terminal such as a personal computer (PC) 33 in addition to the vehicle 31, the compute service function unit 12 determines the transmission source.
  • the queue of the queuing buffer unit 13B is specified according to the transmission source.
  • the compute service function unit 12 is an example of a transmission source determination unit.
  • the response speed from the OTA center 1 is not much of a problem assuming that background processing is performed as in the embodiment described later.
  • communication processing of vehicle configuration information transmitted from the smartphone 32 or the PC 33 is foreground processing, and a slow response speed poses a problem in terms of UX (User experience).
  • step S96 instead of step S95 in the fourth embodiment, the compute service function unit 12 checks the database unit 16 and checks the vehicle configuration information. Specifies whether the transmission is from the car 31 , the smart phone 32 or the PC 33 . At the same time, the price table of the car 31 is confirmed and specified.
  • the queuing buffer unit 13B there are a queue group V for the car 31, a queue group S for the smart phone 32, and a queue group P for the PC 33, and each queue group has queues A to C. Distribution to each queue A to C by the price table is the same as in the second embodiment.
  • step S97 which replaces step S93, the process of accumulating the vehicle configuration information passed to the queuing buffer unit 13B for a certain period of time is the same.
  • the queue groups V, S, and P have different waiting time settings. For example, set as follows. ⁇ Cue group V> A: 100ms B: 1s C: 3s ⁇ Queue group S> A: 50ms B: 70ms C: 90ms ⁇ Queue group P> A: 100ms B: 200ms C: 300ms
  • the fifth embodiment by changing the waiting time setting of each queue in the queuing buffer unit 13B according to the transmission source of the vehicle configuration information and the price table of the car 31, the value of the user is reduced. It is possible to provide a high-quality OTA service with enhanced experience, so-called UX.
  • a compute server section 28 is added to the distribution system 2A.
  • the compute server unit 28 employs a server architecture, and can communicate with 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 intervals of one minute. For example, a ping command is transmitted as a command to check whether or not (see FIG. 20, S98(1)). As a result, each compute service function unit and compute service processing unit can be maintained in a warm standby state.
  • the compute server section 28 is an example of a reserve state setting section.
  • step S98 (2) is a case where AWS is applied, and a plurality of Warm standby can be achieved by reserving and provisionally allocating resources.
  • a warm standby state may be established.
  • a compute server section 29 is added to the distribution system 2B.
  • the compute server section 29 employs a server architecture and inputs and outputs data to and from the API gateway section 11 , file storage section 17 and database section 19 .
  • the compute server unit 29 is an example of an information processing server.
  • the API gateway unit 11 when the API gateway unit 11 receives an HTTPS request for vehicle configuration information from the car 31, smartphone 32, or PC 33 (S121), the API gateway unit 11, based on the URL information included in the HTTPS request, Distribution processing is performed (S122).
  • the API gateway unit 11 transmits an HTTPS response including campaign information to the car 31, as in the first embodiment.
  • the API gateway section 11 which is an example of an information processing control section, passes the received vehicle configuration information to the compute server section 29 (S123).
  • the compute server unit 29 refers to the database unit 19 to generate software update campaign information to be distributed to the car 31 (S124).
  • the compute server unit 29 delivers the generated campaign information to the API gateway unit 11 in order to distribute it to the corresponding smartphone 32 or PC 33 (S125).
  • the API gateway unit 11 transmits an HTTPS response of campaign information to the smart phone 32 or PC 33 (S126).
  • the compute service function unit 12 or the like processes, whereas when the transmission source is the smartphone 32 or the PC 33, the compute server unit 29 processes.
  • the car 31 is the transmission source
  • processing is performed by the serverless architecture, so the response speed is slower than in the case of the server architecture, but the running cost for the infrastructure can be greatly reduced.
  • the smartphone 32 or the PC 33 is the transmission source, the response speed can be maintained because the processing is performed by the server architecture, and the user's experience of value can be improved.
  • FIG. 23 shows a variation of the OTA center configured using AWS shown in FIG. 2 of the first embodiment.
  • the main difference from Figure 2 is that part of the function of "AWS Fargate” is handled by "Elastic Load Balancing", “Elastic Load Balancing” corresponds to the compute service function part 14, and "AWS Fargate” The difference is that it is configured to correspond to the compute service processing unit 15 .
  • Application programs that employ a serverless architecture are not limited to using AWS, and may use other cloud computing services.
  • the command periodically transmitted by the compute server unit 28 is not limited to the ping command, and may be any command for checking whether communication is possible.
  • Mobile information terminals are not limited to smart phones and personal computers.
  • a serverless architecture is an event-driven architecture with loose coupling between services. Loose coupling means low dependencies between services.
  • the server should be stateless, meaning that processes and functions should be designed to have no internal state.
  • Serverless architectures require stateless chaining of requests from one service to the next.
  • Serverless architecture is designed to flexibly change resources according to changes in system usage and load. In order to design a serverless architecture in this way, it is necessary to satisfy matters that are not considered in server architecture design. Therefore, it is not possible to build a system that adopts a serverless architecture based on software system configuration, design, specifications, etc. that assume a server architecture.
  • each device can be provided by software recorded in a physical memory device and a computer that executes it, software only, hardware only, or a combination thereof.
  • the controller is provided by an electronic circuit that is hardware, it can be provided by a digital circuit, including a number of logic circuits, or an analog circuit.
  • the controller and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by the computer program.
  • the controls and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits.
  • the control units and techniques described in this disclosure can be implemented by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. It may also be implemented by one or more dedicated computers configured.
  • the computer program may also be stored as computer-executable instructions on a computer-readable non-transitional tangible recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mechanical Engineering (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本開示の一態様は、ＯＴＡセンタ１が、クルマ３１に搭載される複数のＥＣＵに書込むデータを管理し、無線通信により更新データをクルマ３１に送信するための複数の機能をアプリケーションプログラムにより実行する。その際に、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式によりアプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用する。

Description

センタ装置 関連出願の相互参照
　本出願は、２０２１年１０月２８日に出願された日本出願番号２０２１－１７６５５８号に基づくもので、ここにその記載内容を援用する。
　本開示は、車両に搭載される電子制御装置に書込むデータを管理するセンタ装置に関する。
　近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。
特開２０２０－２７６２４号公報
　特許文献１に開示されているセンタ装置を実際に構成しようとすると、例えば図２４に示すような構成となり、センタ装置を構成する各管理ブロック等は、一般にサーバを用いることを前提としたアーキテクチャにより実現されるもの、と想定される。尚、本願では、サーバを用いることを前提としてアプリケーションプログラムを実行させる環境又は構成を、「サーバアーキテクチャ」と称する。換言すれば、サーバアーキテクチャにおいては、アプリケーションプログラムには常にリソースが割り当てられており、当該プログラムは常駐型プロセスとして実行される。
　しかしながら、図２５に示すように、車両からセンタ装置が備えるサーバに対するアクセスは、日中に多くなり、夜間は少なくなると想定される。そのため、夜間にサーバを稼働させると、そのコストに無駄が多くなってしまう。
　また、法規的に、コネクッテッドカーに対応したセンタ装置は、各国毎に設置する必要がある。そのため、各国に対して同じ規模のシステムを構築すると、車両が少ない地域では、やはりサーバを稼働させるコストに無駄が多くなってしまう（図２６参照）。
　本発明は上記事情に鑑みてなされたものであり、その目的は、複数台の車両と無線通信を行なうセンタ装置を、より低コストで構成することにある。
　請求項１又は２記載のセンタ装置によれば、車両に搭載される電子制御装置に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行する。その際に、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用する。
　上述したように、車両からセンタ装置へのアクセスは時間帯によって多寡があると共に、車両の数自体も地域によって異なる。そして、少なくとも一部の機能を実現するアプリケーションプログラムにサーバレスアーキテクチャを採用すれば、車両からのアクセスが発生する毎に、リソースが動的に割り当てられてプログラムが起動され、コードの実行が完了すればリソースが開放されるようになる。したがって、常駐型のプロセスとして実行されるサーバアーキテクチャを採用する場合に比較して、コンピューティングリソースの消費を節約でき、結果としてインフラに掛かるランニングコストを低減させることができる。
　本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、第１実施形態において、ＯＴＡセンタの構成を示す機能ブロック図であり、 図２は、ＯＴＡセンタの機能を、ＡＷＳを適用して実現した一例を示す図であり、 図３は、車両側システムとＯＴＡセンタとの間で行われる処理を概略的に示すフロー図であり、 図４Ａは、車両構成情報の受信からキャンペーン情報の送信までの処理を示すフローチャート（その１）であり、 図４Ｂは、車両構成情報の受信からキャンペーン情報の送信までの処理を示すフローチャート（その２）であり、 図５Ａは、キャンペーン情報の登録からＣＤＮ配信部への配信パッケージの登録までの処理を示すフローチャート（その１）であり、 図５Ｂは、キャンペーン情報の登録からＣＤＮ配信部への配信パッケージの登録までの処理を示すフローチャート（その２）であり、 図６は、クルマによるデータアクセスから、ＣＤＮ配信部によりパッケージの配信までの処理を示すフローチャートであり、 図７は、ソフトウェア更新データの登録処理を示すフローチャートであり、 図８Ａは、案件情報の登録からパッケージの生成までの処理を示すフローチャート（その１）であり、 図８Ｂは、案件情報の登録からパッケージの生成までの処理を示すフローチャート（その２）であり、 図９は、案件情報の登録からパッケージの生成までの処理を示すフローチャート（その３）であり、 図１０は、キューイングバッファ部においてデータを一定時間蓄積してから、次段のコンピュートサービス関数部に渡すことによる効果を説明する図であり、 図１１は、サーバモデル及びサーバレスモデルそれぞれの処理形態を説明する図であり、 図１２は、サーバモデル及びサーバレスモデルそれぞれのランニングコストを示す図であり、 図１３は、第２実施形態において、キューイングバッファ部における各キューへのデータの振り分け状態を示す図であり、 図１４は、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図１５は、第３実施形態において、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図１６は、第４実施形態において、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図１７は、第５実施形態において、キューイングバッファ部における各キューへのデータの振り分け状態を示す図であり、 図１８は、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図１９は、第６実施形態であり、ＯＴＡセンタの構成を示す機能ブロック図であり、 図２０は、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図２１は、第８実施形態において、ＯＴＡセンタの構成を示す機能ブロック図であり、 図２２は、車両構成情報の受信からキャンペーン情報の送信までの処理の一部を示すフローチャートであり、 図２３は、第９実施形態において、ＯＴＡセンタの機能を、ＡＷＳを適用して実現した一例を示す図であり、 図２４は、ＯＴＡセンタの機能を、主にサーバアーキテクチャを適用して構成した場合を想定した機能ブロック図であり、 図２５は、コネクテッドカーサービスにおいて時間帯によるサーバアクセスの傾向を示す図であり、 図２６は、各地域におけるクルマの販売台数の違いを示す図である。
　　（第１実施形態）
　以下、第１実施形態について説明する。図１に示すように、本実施形態のセンタ装置であるＯＴＡセンタ１は、配信システム２及び共通システム３を備えている。共通システム３においては、車両であるクルマ３１に配信するＥＣＵの更新プログラムやデータを含む配信パッケージが生成されて管理され、生成された配信パッケージは配信システム２を介して、無線通信により、すなわちＯＴＡによってクルマ３１に配信される。
　共通システム３がパッケージを生成する際には、外部のサーバシステムであるＯＥＭ（Original Equipment Manufacturer）バックオフィス４や、鍵管理センタ５との間で必要なデータの送受信が行われる。ＯＥＭバックオフィス４は、第１サーバ６～第４サーバ９等を備えている。これらのサーバ６～９は図２４に示すものと同様であり、それぞれ製造情報管理系、顧客管理系、テレマティクス契約、ＳＭＳ（Short Message Service）配信用のシステムである。鍵管理センタ５は、ＯＴＡに使用する鍵の発行や管理を行うシステムである第５サーバ１０を備えている。
　第１サーバ６～第５サーバ１０では、前述したサーバアーキテクチャが採用されており、アプリケーションプログラムには常にリソースが割り当てられ、当該プログラムは常駐型プロセスとして実行される。
　配信システム２のＡＰＩ（Application Programming Interface）ゲートウェイ部（１）１１は、クルマ３１やＯＴＡ運用者３４と無線通信を行う。ＡＰＩゲートウェイ部１１が受信したデータは、コンピュートサービス関数部（１）１２、キューイングバッファ部１３、コンピュートサービス関数部（２）１４、コンピュートサービス処理部（１）１５に順次転送される。コンピュートサービス関数部１２は、データベース部（１）１６にアクセスする。コンピュートサービス処理部１５は、ファイルストレージ部（１）１７及び（２）１８並びにデータベース部（２）１９にアクセスする。データベース部１９には、プログラム更新が必要なクルマ３１に対応したソフトウェアの更新情報であるキャンペーン情報が格納されている。
　コンピュートサービス処理部１５が出力したデータは、コンピュートサービス関数部（３）２０を介してＡＰＩゲートウェイ部１１に出力される。ＣＤＮ（Contents Delivery Network）配信部２１は、ファイルストレージ部１８にアクセスし、ファイルストレージ部１８にバッファリングされているデータをクルマ３１にＯＴＡにより配信する。ＣＤＮ配信部２１は、ネットワーク配信部の一例である。
　共通システム３のＡＰＩゲートウェイ部（２）２２は、配信システム２のコンピュートサービス処理部１５、並びに共通システム３が備えるコンピュートサービス処理部（２）２３及びコンピュートサービス関数部（４）２４とデータの入出力を行う。コンピュートサービス処理部２３は、データベース部（３）２５及びファイルストレージ部（３）２６にアクセスする。コンピュートサービス関数部２４は、ファイルストレージ部２６及びデータベース部（４）２７にアクセスする。また、ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４及び鍵管理センタ５が備える各サーバ６～１０にもアクセスする。
　尚、図示した構成では、説明の便宜上、指令やデータの送受信を線で示している。しかし、線で表示されていなくても、処理部や関数部、管理部の呼出しや、データベース部やストレージ部へのアクセスは可能である。
　以上の構成において、コンピュートサービス関数部１２，１４，２０及び２４、並びにコンピュートサービス処理部１５及び２３は、サーバレスアーキテクチャを採用している。「サーバレスアーキテクチャ」は、イベントの発生を契機として起動され、オンデマンド方式によりアプリケーションプログラムのコードの実行に対してリソースが自動的に割り当てられる。そして、コードの実行が完了すれば、割り当てられたリソースが自動的に開放されるように構成され、前述の「サーバアーキテクチャ」に対向した設計思想に基づいている。
　また、「サーバレスアーキテクチャ」は、イベントの発生を契機として起動され、アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、割り当てられたリソースが開放される。尚、コードの実行が完了すれば、リソースが動的に開放される。リソースの開放は、コードの実行完了後に直ちに開放しても良いし、実行完了後、所定時間、例えば１０秒間待機した後に開放しても良い。
　ここで、サーバレスアーキテクチャを構成するための４つの原則を挙げると、
・オンデマンドでプログラムコードを実行するため、サーバを使用することなく、コンピューティングサービスを使用する。
・目的が１つだけの、ストレートな関数とする。
・プッシュベースのイベント駆動型パイプラインを構成する。
・より厚く強力なフロントエンドを構成する。
といったものになる。
　図２は、図１に示すセンタ装置１を、ＡＷＳ（Amazon Web Service）クラウドを利用して構成した場合の一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１、２２に相当する。
・AWS Lambda　　　　 ：コンピュートサービス関数部１２、２０、２４に相当する。
・Amazon Kinesis　　：キューイングバッファ部１３に相当する。
・AWS Fargate　　　　：コンピュートサービス関数部１４及び
コンピュートサービス処理部１５に相当する。
・Amazon S3　　　　　：ファイルストレージ部１７、１８及び２６に相当する。
・Amazon Aurora　　　：データベース部１９、２５及び２７に相当する。
尚、ＣＤＮ７７はＣＤＮ配信部２１に相当するが、これはＣＤＮ７７（株）が提供しているサービスである。これをＡＷＳが提供しているAmazon CloudFrontサービスに置き換えてもよい。
　また、ＣＤＮ配信部２１は、ＣＤＮ７７（株）により提供されるＣＤＮ７７やＡＷＳが提供しているAmazon CloudFrontサービスに限定されず、コンテンツデリバリネットワークを実現する任意のサービス又はサーバに相当する。また、ＡＷＳ（Amazon Web Service）クラウドは、サーバレスアーキテクチャを提供するクラウドサービスの一例である。実施形態において、説明される構成や図示される構成は、クラウドサービスにより提供される関数により適宜変更される。
　次に、本実施形態の作用について説明する。図３に示すように、「車両構成情報同期」のフェーズでは、クルマ３１において、例えば２週間毎に、イグニッションスイッチがＯＮされたタイミングで車両構成情報がＯＴＡセンタ１に送信される。尚、キャンペーンが発生すると、第４サーバ９からキャンペーン対象の車両へショートメッセージが送信され、このショートメッセージをトリガとして車両構成情報がＯＴＡセンタ１へ送信されても良い。車両構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する情報である。ＯＴＡセンタ１では、送信された車両構成情報を元に、ソフトウェアの更新について適用されるキャンペーン情報があるか否かをチェックする。そして、対応するキャンペーン情報がある場合には、そのキャンペーン情報をクルマ３１に送信する。また、クルマ３１により車両構成情報が送信された際に、当該情報を、ＯＴＡセンタ１側に保持されている前記クルマ３１の車両構成情報と比較して、新しい方の情報に更新する処理を、車両構成情報の同期処理と称する。
　「キャンペーン承諾＋ＤＬ承諾」のフェーズでは、キャンペーン情報を受信したクルマ３１のドライバが、車載装置の画面に表示されたダウンロードを承諾するためのボタンを押下すると、ＣＤＮ配信部２1からプログラム更新用のデータパッケージがダウンロードされる。そのダウンロード中は、ダウンロード処理の進捗率がクルマ３１からＯＴＡセンタ１に通知される。
　ダウンロードが完了して「インストール承諾」となり、インストールが実行されると、そのインストール処理の進捗率がクルマ３１からＯＴＡセンタ１に通知される。インストール処理が完了して、クルマ３１において「アクティベート実施」となり、アクティベートが完了すると、アクティベートの完了がＯＴＡセンタ１に通知される。
　以下、上記の各処理の詳細について説明する。
　　＜車両構成情報の受信→キャンペーン情報の送信＞
　図４に示すように、ＡＰＩゲートウェイ部１１が、クルマ３１から車両構成情報のＨＴＴＰＳ（Hypertext Transfer Protocol Secure）リクエストを受信する（Ｓ１）。そのリクエスト内容は、例えばＶＩＮ（Vehicle Identification Number）と、各ＥＣＵのハードウェアＩＤと、各ＥＣＵのソフトウェアＩＤなどである。次に、ＡＰＩゲートウェイ部１１はコンピュートサービス関数部１２を起動すると、受信した車両構成情報を当該関数部１２に渡す（Ｓ２）。
　コンピュートサービス関数部１２は、車両構成情報をキューイングバッファ部１３に渡す（Ｓ３）。キューイングバッファ部１３は、渡された車両構成情報を一定期間、例えば１秒又は数秒蓄積し、バッファリングする（Ｓ４）。ここで、コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ５）。尚、コンピュートサービス関数部１２は、必要に応じて、ＡＰＩゲートウェイ部１１からＴＣＰポート番号を受け取り、共有メモリに保存しても良い。
　上記の一定期間が経過すると（Ｓ５Ａ）、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積された車両構成情報をコンピュートサービス関数部１４に渡す（Ｓ６）。キューイングバッファ部１３は、アクセスバッファ制御部の一例である。コンピュートサービス関数部１４は、渡された車両構成情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、車両構成情報をコンピュートサービス処理部１５に渡す（Ｓ７）。
　尚、コンピュートサービス処理部１５のコンテナアプリとしては、キャンペーン情報の生成に関わるコンテナアプリ、配信パッケージの登録に関わるコンテナアプリ、パッケージの生成に関わるコンテナアプリ、が含まれている。コンピュートサービス関数部１４は、渡された情報を解釈して対応するコンテナアプリを起動する。
　ここで、コンテナとは、ホストＯＳ上に論理的な区画としてのコンテナを作り、アプリケーションを動作させるのに必要なライブラリやプログラム等を１つにまとめたものである。ＯＳのリソースを論理的に分離して、複数のコンテナで共有して使用する。コンテナにて実行されるアプリケーションを、コンテナアプリと称する。
　コンピュートサービス処理部１５は、データベース部１９にアクセスし、渡された車両構成情報に対応した、ソフトウェア更新情報であるキャンペーン情報が存在するか否かを判断する（Ｓ８）。キャンペーン情報があり、それが不完全な形態であれば、コンピュートサービス処理部１５は、クルマ３１に配信するキャンペーン情報を、データベース部１９を参照して生成する（Ｓ９）。不完全な形態とは、例えば、クルマ３１に配信する上で必要な情報が欠けている状態である。ここで、コンピュートサービス処理部１５は、キャンペーン判定部及びキャンペーン生成部の一例である。また、コンピュートサービス関数部１４は第１コンピュートサービス部に相当し、コンピュートサービス処理部１５は第２コンピュートサービス部に相当する。
　尚、ステップＳ９において、キャンペーン情報があり、クルマ３１に配信する上で必要な情報が揃っている場合は、ステップＳ１０に移行する。
　コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動し、生成したキャンペーン情報を渡す（Ｓ１０）。ここで、コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１１）。ステップＳ８において、キャンペーンがなければ、クルマ３１に配信する「キャンペーンなし」を通知するキャンペーン情報を生成してから（Ｓ１２）、ステップＳ１０に移行する。ステップＳ１０において、コンピュートサービス処理部１５は、「キャンペーンあり」を通知するキャンペーン情報か、「キャンペーンなし」を通知するキャンペーン情報をコンピュートサービス関数部２０に渡す。
　コンピュートサービス関数部２０は、渡されたキャンペーン情報を対応するクルマ３１に配信するため、ＡＰＩゲートウェイ部１１に渡す。ここで、コンピュートサービス関数部２０は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１４）。ＡＰＩゲートウェイ部１１は、クルマ３１にキャンペーン情報を含むＨＴＴＰＳレスポンスを送信する（Ｓ１５）。クルマ３１は、キャンペーン情報を含むＨＴＴＰＳレスポンスを受信する。ＡＰＩゲートウェイ部１１は、キャンペーン送信部の一例である。
　尚、上記の処理において、コンピュートサービス関数部２０は、必要に応じて、コンピュートサービス関数部１２が保存したＴＣＰポート番号を共有メモリから取得し、そのＴＣＰポート番号に対するＨＴＴＰＳレスポンスを配信するように、ＡＰＩゲートウェイ部１１に要求するようにしても良い。
　　＜キャンペーン情報の登録→ＣＤＮ配信部２１への配信パッケージの登録＞
　図５に示すように、ＯＴＡ運用者３４は、キャンペーン情報登録のＨＴＴＰＳリクエストを送信する（Ｓ２１）。ＡＰＩゲートウェイ部１１はコンピュートサービス関数部１２を起動すると、受信したキャンペーン情報を渡す（Ｓ２２）。
　コンピュートサービス関数部１２は、キャンペーン情報をキューイングバッファ部１３に渡す（Ｓ２３）。キューイングバッファ部１３は、渡されたキャンペーン情報を一定期間蓄積し、バッファリングする（Ｓ２４）。ここで、コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ２５）。コンピュートサービス関数部１２は、キャンペーン登録部の一例であり、第５コンピュートサービス部に相当する。
　上記の一定期間が経過すると（Ｓ２５Ａ）、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積されたキャンペーン情報をコンピュートサービス関数部１４に渡す（Ｓ２６）。コンピュートサービス関数部１４は、渡されたキャンペーン情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、キャンペーン情報をコンピュートサービス処理部１５に渡す（Ｓ２７）。コンピュートサービス関数部１４は、キャンペーン登録部の一例であり、第６コンピュートサービス部に相当する。
　コンピュートサービス処理部１５は、渡されたキャンペーン情報の中に含まれている対象車両と、更新対象のソフトウェアパッケージとの紐付けを行うため、データベース部１９にキャンペーン情報を登録する（Ｓ２８）。また、コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動し、キャンペーン情報の登録が完了した通知をＡＰＩゲートウェイ部１１に渡す（Ｓ３０）。コンピュートサービス処理部１５は、キャンペーン登録部の一例であり、第４コンピュートサービス部に相当する。
　次に、コンピュートサービス処理部１５は、ファイルストレージ部１８に、更新対象のソフトウェアパッケージとダウンロード用のＵＲＬ情報とを格納する（Ｓ３１）。ここで、コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ３２）。そして、ファイルストレージ部１８は、ＣＤＮ配信部２１のオリジンサーバとして動作する（Ｓ３３）。コンピュートサービス処理部１５は、パッケージ配信部の一例であり、第３コンピュートサービス部に相当する。
　尚、オリジンサーバとは、オリジナルのデータが存在するサーバである。本実施形態では、ファイルストレージ部１８には、更新対象のソフトウェアパッケージとダウンロード用のＵＲＬ情報の全てが保存される。
　　＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
　図６に示すように、クルマ３１、より具体的にはクルマ３１に搭載されているＤＣＭ（Data Communication Module）及びセントラルＥＣＵからなるＯＴＡマスタが、キャンペーン情報に含まれているダウンロードＵＲＬ情報を元に、ＣＤＮ配信部２１にアクセスする（Ｓ４１）。ＣＤＮ配信部２１は、クルマ３１から要求されたソフトウェアパッケージを、自身のキャッシュメモリに保持しているか否かを判断する（Ｓ４２）。キャッシュメモリに保持していれば、ＣＤＮ配信部２１は、クルマ３１にソフトウェアパッケージを送信する（Ｓ４３）。
　一方、要求されたソフトウェアパッケージをキャッシュメモリに保持していなければ、ＣＤＮ配信部２１は、オリジンサーバであるファイルストレージ部１８に、上記のソフトウェアパッケージを要求する（Ｓ４４）。すると、ファイルストレージ部１８は、要求されたソフトウェアパッケージをＣＤＮ配信部２１に送信する（Ｓ４５）。ＣＤＮ配信部２１は、ファイルストレージ部１８から受け取ったソフトウェアパッケージを、自身のキャッシュメモリに保持すると共に、クルマ３１に送信する（Ｓ４６）。
　　＜ソフトウェア更新データの登録＞
　図７に示すように、ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４の第１サーバ６から、ソフトウェア更新データ及びその関連情報の登録要求を、ＨＴＴＰＳリクエストとして受信する（Ｓ５１）。ＡＰＩゲートウェイ部２２は、コンピュートサービス関数部２４を起動して、ソフトウェア更新データ及び関連情報を渡す（Ｓ５２）。コンピュートサービス関数部２４は、ソフトウェア更新データ及び関連情報をファイルストレージ部２６に格納する（Ｓ５３）。
　コンピュートサービス関数部２４は、ソフトウェア更新データ及び関連情報をどこに格納したのか参照できるように、データベース部２７に格納されている検索テーブルを更新する（Ｓ５４）。ここで、コンピュートサービス関数部２４は、処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ５５）。
　　＜案件情報→パッケージの生成＞
　図８に示すように、ＯＴＡ運用者３４が、案件情報の登録を行うため、ＡＰＩゲートウェイ部１１に対して案件情報のＨＴＴＰＳリクエストを送信する（Ｓ６１）。案件情報は、ある配信パッケージを適用可能なＥＣＵのハードウェア情報やソフトウェア情報を纏めたものである。ＡＰＩゲートウェイ部１１は、コンピュートサービス関数部１２を起動すると、受信した案件情報を当該関数部１２に渡す（Ｓ６２）。
　コンピュートサービス関数部１２は、案件情報をキューイングバッファ部１３に渡す（Ｓ６３）。キューイングバッファ部１３は、渡された案件情報を一定期間蓄積し、バッファリングする（Ｓ６４）。コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ６５）。尚、コンピュートサービス関数部１２は、必要に応じて、ＡＰＩゲートウェイ部１１からＴＣＰポート番号を受け取り、共有メモリに保存しておいても良い。
　上記の一定期間が経過すると、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積された案件情報をコンピュートサービス関数部１４に渡す（Ｓ６６）。コンピュートサービス関数部１４は、渡された案件情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、案件情報をコンピュートサービス処理部１５に渡す（Ｓ６７）。
　コンピュートサービス処理部１５は、データベース部１９にアクセスし、渡された案件情報に含まれているソフトウェア更新対象情報を元に、ソフトウェアパッケージを生成するため、コンピュートサービス処理部２３のコンテナアプリを起動し、コンピュートサービス処理部２３にソフトウェア更新対象情報を渡す（Ｓ６８）。コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ７０）。
　コンピュートサービス処理部２３は、渡されたソフトウェア更新対象情報を元に、ＡＰＩゲートウェイ部２２に対して、ソフトウェア更新データ要求のＨＴＴＰＳリクエストを送信する（Ｓ７１）。ＡＰＩゲートウェイ部２２は、コンピュートサービス関数部２４を起動し、ソフトウェア更新データ要求を渡す（Ｓ７２）。コンピュートサービス関数部２４は、データベース部２７を参照し、ソフトウェア更新データが格納されているファイルストレージ部２６のパス情報を取得する（Ｓ７３）。
　コンピュートサービス関数部２４は、取得したパス情報を元にファイルストレージ部２６にアクセスし、ソフトウェア更新データを取得する（Ｓ７４）。そして、取得したソフトウェア更新データをコンピュートサービス処理部２３に送信するため、ＡＰＩゲートウェイ部２２に渡す（Ｓ７５）。コンピュートサービス関数部２４は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ７６）。コンピュートサービス関数部２４は、データ管理部の一例である。
　ＡＰＩゲートウェイ部２２は、コンピュートサービス処理部２３に対して、ソフトウェア更新データを含んだソフトウェア更新応答のＨＴＴＰＳレスポンスを送信する（Ｓ７７）。コンピュートサービス処理部２３は、データベース部２５を参照して、対象車両のソフトウェアパッケージの構造を特定する（Ｓ７８）。そして、ソフトウェア更新データを、特定したソフトウェアパッケージの構造に合致するように加工し、ソフトウェアパッケージを生成する（Ｓ７９）。コンピュートサービス処理部２３は、生成したソフトウェアパッケージをファイルストレージ部２６に格納する（Ｓ８０）。コンピュートサービス処理部２３は、パッケージ生成部の一例である。
　コンピュートサービス処理部２３は、ソフトウェアパッケージが格納されているファイルストレージ部２６のパス情報をコンピュートサービス処理部１５に送信するため、ＡＰＩゲートウェイ部２２に渡す（Ｓ８１）。コンピュートサービス処理部２３は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８２）。
　ＡＰＩゲートウェイ部２２は、コンピュートサービス処理部１５を起動し、ソフトウェアパッケージのパス情報を渡す（Ｓ８３）。コンピュートサービス処理部１５は、渡されたソフトウェアパッケージのパス情報を案件情報と紐付けて、データベース部１９に登録されている検索テーブルを更新する（Ｓ８４）。コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動して、案件登録完了情報を渡す（Ｓ８５）。コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８６）。
　コンピュートサービス関数部２０は、渡された案件登録完了情報をＯＴＡ運用者３４に返却するため、ＡＰＩゲートウェイ部１１に渡す（Ｓ８７）。コンピュートサービス関数部２０は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８８）。ＡＰＩゲートウェイ部１１は、ＯＴＡ運用者３４に対して案件登録完了情報のＨＴＴＰＳレスポンスを送信する（Ｓ８９）。
　尚、上記の処理において、コンピュートサービス関数部２０は、必要に応じて、コンピュートサービス関数部１２が保存したＴＣＰポート番号を共有メモリから取得し、そのＴＣＰポート番号に対するＨＴＴＰＳレスポンスを配信するように、ＡＰＩゲートウェイ部１１に要求するようにしても良い。
　次に、本実施形態の効果について説明する。図１０に示すように、キューイングバッファ部１３においては、各クルマ３１より送信される車両構成情報のストリームデータを一定量蓄積してから、次段のコンピュートサービス関数部１４及びコンピュートサービス処理部１５に渡すようになっている。上記の機能をAWS Fargateによって実現することを想定すると、処理の実行頻度を低減することによって、コンピューティングリソースの消費を節約できる。
　尚、キューイングバッファ部１３では、キャンペーン情報、案件情報も車両構成情報と同様に一定期間蓄積してから、次段のコンピュートサービス関数部１４に渡すことで、処理の実行頻度を低減し、コンピューティングリソースの消費を抑制している。
　また、キューイングバッファ部１３は、車両構成情報、キャンペーン情報、案件情報を１つのキューイングバッファに格納しても良いし、情報の種類ごとに異なるキューイングバッファ部１３に格納しても良い。
　また、図１１に示すように、従来のサーバモデルでは、アプリケーションプログラム及びサーバがリソースを占有した状態で常時稼働しており、１つのサーバで複数の処理を実行する。これに対して、本実施形態のように、サーバレスアーキテクチャを採用したモデルでは、各処理の要求が発生した際に対応するアプリケーションプログラムが起動され、処理が終了するとプログラムの実行は停止され、削除される。したがって、この時点で、処理に用いていたリソースは開放されることになる。
　その結果、図１２に示すように、従来のサーバモデルでは、実際に稼働したコストに比較して、サーバを常時稼働させることに伴う固定的なコストが余分にかかっている。また、サーバを予備的に冗長化すれば、さらにコストがかかってしまう。これに対して、本実施形態のようにサーバレスアーキテクチャを採用すれば、略実際に稼働したコストのみを負担するようになるから、インフラに掛かるランニングコストを大きく低減できる。
　以上のように本実施形態によれば、ＯＴＡセンタ１は、クルマ３１に搭載される複数のＥＣＵに書込むデータを管理し、無線通信により更新データをクルマ３１に送信するための複数の機能をアプリケーションプログラムにより実行する。その際に、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式によりアプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用する。
　サーバレスアーキテクチャを採用したプログラムは、クルマ３１からのアクセスが発生する毎に、リソースが動的に割り当てられてプログラムが起動され、コードの実行が完了すればリソースが開放されるようになる。したがって、常駐型のプロセスとして実行されるサーバアーキテクチャを採用する場合に比較して、インフラのコンピューティングリソースの消費を節約でき、結果としてインフラに掛かるランニングコストを低減できる。
　　（第２実施形態）
　以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。図１３に示すように、一般に、クルマ３１の価格帯によって台数のシェアは異なり、ハイエンドモデルのシェアは低く、ミドル、ローエンドモデルのシェアは高い。そこで、キューイングバッファ部１３Ａにおいて、クルマ３１の価格帯によりキューを分けて、ハイエンドモデルのＯＴＡ処理を優先的に実行させる。
　　＜車両構成情報の受信→キャンペーン情報の送信＞
　図１４に示すように、ステップＳ１及びＳ２を実行すると、コンピュートサービス関数部１２は、データベース部１６をチェックして、車両構成情報に含まれているクルマ３１のＶＩＮを確認し、そのＶＩＮに基づいて価格テーブルを確認し、当該車両構成情報を格納するキューイングバッファ部１３Ａのキューを特定する。例えばハイクラスの車両であればキューＡ，ミドルクラスの車両であればキューＢ、ロークラスの車両であればキューＣとする（Ｓ９１）。コンピュートサービス関数部１２は、アクセスバッファ制御部及びキューイングバッファ制御部の一例である。或は、車両構成情報に価格帯を示す情報が含まれていても良い。
　コンピュートサービス関数部１２は、渡された車両構成情報が特定したキューに格納されるようにキューイングバッファ部１３Ａに入力する（Ｓ９２）。キューイングバッファ部１３Ａは、渡された車両構成情報を一定期間蓄積するが、その一定期間を各キュー毎に設定する。例えば、キューは１００ｍｓ、キューＢは１秒、キューＣは３秒とする（Ｓ９１）。それから、ステップＳ５～Ｓ１５を第１実施形態と同様に実行する。キューＡ、キューＢ、キューＣの順に、キューイングバッファ部１３Ａによる蓄積期間が長くなるように設定する。
　以上のように第２実施形態によれば、数１０００万台の大規模の車両群に本実施形態を適用する場合でも、シェアが低く車両構成情報のトラフィックが少ないハイクラスのクルマ３１の車両構成情報を優先させて処理し、コネクテッドサービスの品質が低下することを防止できる。その意味で、これは一種のＱｏＳ（Quality of Service）制御である。
　　（第３実施形態）
　第３実施形態では、第２実施形態における車両の価格帯に替えて、各車両の車両構成情報に、キューイングバッファ部１３Ａにおけるタイムアウト時間が設定されている。タイムアウト時間は、キューイングバッファ部１３Ａに入力されたデータが、当該バッファ部１３Ａを経て出力されるまでの時間に対する指標である。そこで、図１５に示すように、ステップＳ９１に替わるステップＳ９４では、コンピュートサービス関数部１２は、データベース部１６をチェックして、車両構成情報に含まれている各クルマ３１のタイムアウト時間を確認し、当該情報を格納するキューイングバッファ部１３Ａのキューを特定する。ここでのタイムアウト時間は、具体的な数値である必要はなく、「短い」の車両であればキューＡ、「普通」の車両であればキューＢ、「長い」の車両であればキューＣとする。以降は第２実施形態の処理と同様である。また、タイムアウト時間は、１００ｍｓ、１秒、３秒など、所定の数値でも良い。
　　（第４実施形態）
　第４実施形態では、第３実施形態におけるタイムアウト時間の設定に替えて、各車両の車両構成情報に、キャンペーンの重要度や緊急度、課金アプリの有無等に基づいて、配信順序の優先度が例えば「高い」、「普通」、「低い」といったように設定されている。そこで、図１６に示すように、ステップＳ９４に替わるステップＳ９５では、コンピュートサービス関数部１２は、データベース部１６をチェックして、車両構成情報に含まれている各クルマ３１の配信順序の優先度を確認し、当該情報を格納するキューイングバッファ部１３Ａのキューを特定する。「高い」の車両であればキューＡ、「普通」の車両であればキューＢ、「低い」の車両であればキューＣとする。以降は第３実施形態の処理と同様である。
　換言すると、第４実施形態では、キャンペーンの属性に基づいて、配信順序の優先度が例えば「高い」、「普通」、「低い」といったように設定されている。キャンペーンの属性とは、例えば、キャンペーンの重要性や緊急度、又は課金コンテンツであるか否かといった条件のうち、少なくとも１つ以上の条件である。
　　（第５実施形態）
　第５実施形態では、第２実施形態と同様に車両構成情報に含まれているクルマ３１の価格テーブルを確認して当該情報を格納するキューを特定する。それに加えて、車両構成情報の送信が、クルマ３１以外にスマートフォン３２や、パーソナルコンピュータ（ＰＣ）３３のような情報通信端末からも可能である場合に、コンピュートサービス関数部１２において送信元を判別し、送信元にも応じてキューイングバッファ部１３Ｂのキューを特定する。コンピュートサービス関数部１２は、送信元判別部の一例である。
　クルマ３１を送信元とする車両構成情報の通信処理に関しては、後述する実施形態のようにバックグラウンド処理を行うことを前提とすれば、ＯＴＡセンタ１からのレスポンス速度はあまり問題にならない。一方、スマートフォン３２やＰＣ３３を送信元とする車両構成情報の通信処理に関しては、フォアグラウンド処理となるため、レスポンス速度が遅くなるとＵＸ（User eXperience）的に問題となる。
　そこで、第５実施形態では、図１７及び図１８に示すように、例えば第４実施形態のステップＳ９５に替わるステップＳ９６において、コンピュートサービス関数部１２は、データベース部１６をチェックし、車両構成情報の送信が、クルマ３１、スマートフォン３２、又はＰＣ３３の何れであるかを特定する。それと共に、クルマ３１の価格テーブルを確認して特定する。キューイングバッファ部１３Ｂでは、クルマ３１のキューグループＶ、スマートフォン３２のキューグループＳ、ＰＣ３３のキューグループＰがあり、各キューグループにキューＡ～Ｃがある。価格テーブルによる各キューＡ～Ｃに対する振り分けは、第２実施形態と同様である。
　ステップＳ９３に替わるステップＳ９７では、キューイングバッファ部１３Ｂに渡された車両構成情報を一定時間蓄積する処理は同様である。但し、送信元及び価格テーブルの組み合わせによって、キューグループＶ、Ｓ、Ｐの待ち時間設定が異なる。例えば以下のように設定する。
＜キューグループＶ＞
　Ａ：１００ｍｓ
　Ｂ：１ｓ
　Ｃ：３ｓ
＜キューグループＳ＞
　Ａ：５０ｍｓ
　Ｂ：７０ｍｓ
　Ｃ：９０ｍｓ
＜キューグループＰ＞
　Ａ：１００ｍｓ
　Ｂ：２００ｍｓ
　Ｃ：３００ｍｓ
　以上のように第５実施形態によれば、車両構成情報の送信元とクルマ３１の価格テーブルとに応じて、キューイングバッファ部１３Ｂにおける各キューの待ち時間設定を変化させることで、ユーザの価値体験、所謂ＵＸを高めた高品質なＯＴＡサービスを提供することができる。
　　（第６実施形態）
　サーバレスアーキテクチャでは、イベントが発生した時点でリソースが割り当てられるため、起動するのに比較的時間を要する。そこで、第６実施形態では、サーバレスアーキテクチャを採用するコンピュートサービス関数部１２，１４，２０及び２４、並びにコンピュートサービス処理部１５及び２３をウォームスタンバイ状態にすることで、起動時間の短縮を図る。
　その一手法として、図１９に示す第６実施形態のＯＴＡセンタ１Ａでは、配信システム２Ａにおいて、コンピュートサーバ部２８が追加されている。コンピュートサーバ部２８は、サーバアーキテクチャを採用しており、コンピュートサービス関数部１２，１４，２０及び２４、並びにコンピュートサービス処理部１５及び２３に対して、一定周期、例えば１分間隔で、通信可能か否かを調べるコマンドとして、例えばｐｉｎｇコマンドを送信する（図２０、Ｓ９８（１）参照）。これにより、各コンピュートサービス関数部及びコンピュートサービス処理部をウォームスタンバイ状態に維持できる。コンピュートサーバ部２８は、リザーブ状態設定部の一例である。
　また、ステップＳ９８の（２）に示す手法は、ＡＷＳを適用する場合であり、コンピュートサービス関数部１２，１４，２０及び２４、並びにコンピュートサービス処理部１５及び２３に対して、事前に複数個のリソースを予約、仮割り当てすることでウォームスタンバイ状態にできる。尚、コンピュートサービス関数部１２，１４，２０及び２４にプロビジョニングされた同時実行を設定することで、ウォームスタンバイ状態にしても良い。
　　（第７実施形態）
　図２１に示す第７実施形態のＯＴＡセンタ１Ｂでは、配信システム２Ｂにおいて、コンピュートサーバ部２９が追加されている。コンピュートサーバ部２９は、サーバアーキテクチャを採用しており、ＡＰＩゲートウェイ部１１、ファイルストレージ部１７及びデータベース部１９との間でデータを入出力する。コンピュートサーバ部２９は、情報処理サーバの一例である。
　図２２に示すように、ＡＰＩゲートウェイ部１１は、クルマ３１、スマートフォン３２又はＰＣ３３から車両構成情報のＨＴＴＰＳリクエストを受信すると（Ｓ１２１）、そのＨＴＴＰＳリクエストに含まれているＵＲＬ情報に基づいて送信元の振り分け処理を行う（Ｓ１２２）。
　送信元がクルマ３１であれば、第１実施形態と同様にステップＳ２２以降の処理を実行する。ステップＳ２５以降では第１実施形態と同様に、ＡＰＩゲートウェイ部１１は、クルマ３１にキャンペーン情報を含むＨＴＴＰＳレスポンスを送信する。送信元がスマートフォン３２又はＰＣ３３であれば、情報処理制御部の一例であるＡＰＩゲートウェイ部１１は、コンピュートサーバ部２９に受信した車両構成情報を渡す（Ｓ１２３）。コンピュートサーバ部２９は、クルマ３１に配信するソフトウェア更新のキャンペーン情報を、データベース部１９を参照して生成する（Ｓ１２４）。続いて、コンピュートサーバ部２９は、生成したキャンペーン情報を対応するスマートフォン３２又はＰＣ３３に配信するため、ＡＰＩゲートウェイ部１１に渡す（Ｓ１２５）。すると、ＡＰＩゲートウェイ部１１は、スマートフォン３２又はＰＣ３３に対してキャンペーン情報のＨＴＴＰＳレスポンスを送信する（Ｓ１２６）。
　送信元がクルマ３１の場合は、コンピュートサービス関数部１２などが処理するのに対して、送信元がスマートフォン３２又はＰＣ３３の場合は、コンピュートサーバ部２９が処理する。クルマ３１が送信元の場合は、サーバレスアーキテクチャにより処理するため、レスポンス速度がサーバアーキテクチャの場合に比べて遅くなるものの、インフラに掛かるランニングコストを大きく低減できる。また、スマートフォン３２又はＰＣ３３が送信元の場合は、サーバアーキテクチャにより処理するためレスポンス速度を維持でき、ユーザの価値体験の向上を実現できる。
　　（第８実施形態）
　図２３に示す第８実施形態は、第１実施形態の図２に示した、ＡＷＳを用いて構成したＯＴＡセンタのバリエーションを示す。図２との主な相違点は、「AWS Fargate」の機能の一部を「Elastic Load Balancing」に担わせて、「Elastic Load Balancing」がコンピュートサービス関数部１４に相当し、「AWS Fargate」がコンピュートサービス処理部１５に相当するように構成した点である。
　　（その他の実施形態）
　サーバレスアーキテクチャを採用するアプリケーションプログラムは、ＡＷＳを利用するものに限らず、その他のクラウドコンピューティングサービスを利用しても良い。
　コンピュートサーバ部２８が周期的に送信するコマンドはｐｉｎｇコマンドに限らず、通信可能か否かを調べるコマンドであれば良い。
　情報携帯端末は、スマートフォンやパーソナルコンピュータに限らない。
　サーバレスアーキテクチャの特徴の例を説明する。サーバレスアーキテクチャは、イベントドリブンなアーキテクチャであり、サービス間は疎結合な状態にある。疎結合とはサービス同士の依存性が低いことを意味する。更には、サーバはステートレスであって、処理や関数が内部でステート、つまり状態を持たないように設計する必要がある。サーバレスアーキテクチャでは、１つのサービスから次のサービスへと、ステートレスにリクエストを繋ぐ必要がある。サーバレスアーキテクチャでは、システムの利用や負荷の変化に応じて柔軟にリソースを変化できるように設計される。
　このようにサーバレスアーキテクチャを設計するには、サーバアーキテクチャの設計では考慮しない事項を満たす必要がある。そのため、サーバアーキテクチャを前提とするソフトウェアシステム構成、設計、仕様などに基づいて、サーバレスアーキテクチャを採用するシステムは構築できない。
　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
　各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。
　本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。
 

Claims (23)

  1. 　車両に搭載される電子制御装置に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、
    　一部の機能を実現するアプリケーションプログラムは、常にリソースが割り当てられて常駐型のプロセスとして実行されるサーバアーキテクチャを採用しており、
    　その他の機能のうち少なくとも一部を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、
    　前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しているセンタ装置。
  2. 　車両に搭載される電子制御装置に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、
    　少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、
    　前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しているセンタ装置。
  3. 　車両から車両構成情報を受信し、その車両に対するキャンペーン情報があるか否か判定するキャンペーン判定部（１５）と、
    　前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成するキャンペーン生成部（１５）と、
    　前記キャンペーン通知情報を車両に配信するキャンペーン送信部（１１）とを備え、
    　前記キャンペーン判定部及び前記キャンペーン生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１又は２記載のセンタ装置。
  4. 　前記アプリケーションプログラムは、
    　ゲートウェイ部（１１）を介して前記車両から受信した車両構成情報を、前記キャンペーン判定部に転送する第１コンピュートサービス部（１４）と、
    　前記キャンペーン判定部及び前記キャンペーン生成部として、前記車両構成情報に基づいて前記車両に対するキャンペーン情報があるか否かを判定し、前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成する第２コンピュートサービス部（１５）とを備え、
    　前記第１コンピュートサービス部は、前記車両構成情報の内容に応じて、前記第２コンピュートサービス部が有するアプリケーションプログラムを選択して起動する請求項３記載のセンタ装置。
  5. 　前記第１コンピュートサービス部は、車両構成情報を受け取ったことをイベントして起動し、
    　前記第２コンピュートサービス部は、前記第１コンピュートサービス部による起動指示をイベントとして起動する請求項３記載のセンタ装置。
  6. 　前記車両に配信する更新データを含んだパッケージを前記車両に配信するパッケージ配信部（１５）を備え、
    　前記パッケージ配信部は、前記キャンペーン情報に紐づけられた更新パッケージをネットワーク配信部（２１）に転送することで配信を行い、
    　前記パッケージ配信部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項３記載のセンタ装置。
  7. 　前記パッケージ配信部の機能を実現するアプリケーションプログラムは、受信した更新パッケージを前記ネットワーク配信部に転送する第３コンピュートサービス部（１５）を備える請求項６記載のセンタ装置。
  8. 　車両構成情報とその車両に対する更新データのキャンペーン情報と、このキャンペーン情報と共に配信する更新データとを登録するキャンペーン登録部（１５）を備え、
    　前記キャンペーン登録部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項３から７の何れか一項に記載のセンタ装置。
  9. 　前記キャンペーン登録部の機能を実現するアプリケーションプログラムは、
    　前記キャンペーン情報の登録要求が入力されると、前記キャンペーン情報を第５コンピュートサービス部に転送するゲートウェイ部（１１）と、
    　受信したキャンペーン情報を、第６コンピュートサービス部に転送する第５コンピュートサービス部（１２）と、
    　前記キャンペーン情報の内容に応じて、第４コンピュートサービス部が有するアプリケーションプログラムを選択して起動する第６コンピュートサービス部（１４）と、
    　前記キャンペーン情報をデータベースに登録すると共に、前記更新データをファイルストレージ部に登録する第４コンピュートサービス部（１５）とを備える請求項８記載のセンタ装置。
  10. 　前記第５コンピュートサービス部は、キャンペーン情報を受け取ったことをイベントとして起動し、
    　前記第６コンピュートサービス部は、起動指示をイベントとして起動し、キャンペーン情報を受け取り、
    　前記第４コンピュートサービス部は、第６コンピュートサービス部による起動指示をイベントとして起動する請求項９記載のセンタ装置。
  11. 　前記車両に配信する更新データを含んだパッケージを生成するパッケージ生成部（２３）を備え、
    　前記パッケージ生成部は、車両に搭載され、受信した更新データを更新対象である電子制御装置に転送するマスタ装置が解釈可能なフォーマットの更新パッケージに加工し、
    　前記パッケージ生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項９記載のセンタ装置。
  12. 　前記パッケージ生成部からの要求に応じて、前記ファイルストレージ部に登録されている前記車両構成情報及び対応する更新データを、前記パッケージ生成部に転送するデータ管理部（２４）を備え、
    　前記データ管理部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１１記載のセンタ装置。
  13. 　車両から受信した車両構成情報を前記キャンペーン制御部に転送する前に、前記両構成情報を一定時間バッファリングして貯留し、前記一定時間内に受信した車両構成情報を一括して前記キャンペーン制御部に転送するアクセスバッファ制御部（１３）を備える請求項３記載のセンタ装置。
  14. 　前記アクセスバッファ制御部は、車両モデル毎の処理順に優先順位が付与された複数のキューイングバッファ（１３Ａ）と、
    　前記車両構成情報に基づいて前記車両モデルを解釈し、該当するキューイングバッファに格納するキューイングバッファ制御部（１２）とを備え、
    　前記キューイングバッファ制御部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１３記載のセンタ装置。
  15. 　前記アクセスバッファ制御部は、車両モデル毎に設定された、入力されたデータが当該アクセスバッファ制御部より出力されるまでの時間の指標であるタイムアウト時間の長さに応じて優先順位が付与された複数のキューイングバッファと、
    　前記車両構成情報に基づいて前記タイムアウト時間の長さを解釈し、該当するキューイングバッファに格納するキューイングバッファ制御部とを備え、
    　前記キューイングバッファ制御部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１３記載のセンタ装置。
  16. 　前記アクセスバッファ制御部は、前記キャンペーン情報の属性に応じて処理順に優先順位が付与された複数のキューイングバッファと、
    　前記車両構成情報に基づいて前記キャンペーン情報の属性を解釈し、該当するキューイングバッファに格納するキューイングバッファ制御部とを備え、
    　前記キューイングバッファ制御部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１３記載のセンタ装置。
  17. 　前記車両構成情報が、前記車両以外の情報通信端末からも送信される際に、
    　前記車両構成情報の送信元を判別する送信元判別部（１２）を備え、
    　前記アクセスバッファ制御部は、前記送信元に応じて処理順に優先順位が付与された複数のキューイングバッファと、
    　前記車両構成情報に基づいて前記送信元を判別し、該当するキューイングバッファに格納するキューイングバッファ制御部とを備え、
    　前記キューイングバッファ制御部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用している請求項１３記載のセンタ装置。
  18. 　前記情報通信端末は、スマートフォン（３２）又はパーソナルコンピュータ（３３）である請求項１５記載のセンタ装置。
  19. 　前記サーバレスアーキテクチャを採用するアプリケーションプログラムのうち少なくとも１つ以上を、起動される以前において、使用される予定のリソースをリザーブ状態に設定しておくリザーブ状態設定部（２８）を備える請求項３記載のセンタ装置。
  20. 　リザーブ状態設定部は、対象とするアプリケーションプログラムに対し、周期的に通信可能かを調べるコマンドを送信する請求項１８記載のセンタ装置。
  21. 　前記コマンドは、Ｐｉｎｇコマンドである請求項２０記載のセンタ装置。
  22. 　前記車両構成情報が、前記車両以外の情報通信端末からも送信される際に、
    　前記車両構成情報の送信元を判別する送信元判別部（１２）と、
    　常にリソースが割り当てられて常駐型のプロセスとして実行されるサーバアーキテクチャを採用して、前記車両構成情報の処理を行なう情報処理サーバ（２９）と、
    　前記送信元が前記情報通信端末であれば、受信した車両構成情報を前記情報処理サーバに処理させる情報処理制御部（１１）とを備える請求項１記載のセンタ装置。
  23. 　前記情報通信端末は、スマートフォン（３２）又はパーソナルコンピュータ（３３）である請求項２２記載のセンタ装置。
     
PCT/JP2022/031103 2021-10-28 2022-08-17 センタ装置 Ceased WO2023074091A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202280071974.1A CN118159942A (zh) 2021-10-28 2022-08-17 中心装置
DE112022005159.0T DE112022005159T5 (de) 2021-10-28 2022-08-17 Zentralvorrichtung
JP2023556140A JP7662046B2 (ja) 2021-10-28 2022-08-17 センタ装置
US18/645,001 US20240272896A1 (en) 2021-10-28 2024-04-24 Center device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-176558 2021-10-28
JP2021176558 2021-10-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/645,001 Continuation-In-Part US20240272896A1 (en) 2021-10-28 2024-04-24 Center device

Publications (1)

Publication Number Publication Date
WO2023074091A1 true WO2023074091A1 (ja) 2023-05-04

Family

ID=86159334

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/031103 Ceased WO2023074091A1 (ja) 2021-10-28 2022-08-17 センタ装置

Country Status (5)

Country Link
US (1) US20240272896A1 (ja)
JP (1) JP7662046B2 (ja)
CN (1) CN118159942A (ja)
DE (1) DE112022005159T5 (ja)
WO (1) WO2023074091A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200073783A1 (en) * 2018-09-05 2020-03-05 Amazon Technologies, Inc. Automated software verification service
WO2021166617A1 (ja) * 2020-02-19 2021-08-26 株式会社デンソー マスタ装置、データ配信システム及び更新制御プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7408936B2 (ja) 2018-08-10 2024-01-09 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
JP6920020B2 (ja) 2019-04-12 2021-08-18 株式会社Ｈｅｒｂｉｏ 臍部測定装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200073783A1 (en) * 2018-09-05 2020-03-05 Amazon Technologies, Inc. Automated software verification service
WO2021166617A1 (ja) * 2020-02-19 2021-08-26 株式会社デンソー マスタ装置、データ配信システム及び更新制御プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YOSHIDA, SHINGO: "Chapter 1. Cutting edge serverless environments and their potential. An overview, from definitions to use cases", SOFTWARE DESIGN, vol. 416, 2019, pages 18 - 27, XP009545902, ISSN: 0916-6297 *

Also Published As

Publication number Publication date
DE112022005159T5 (de) 2024-08-14
JPWO2023074091A1 (ja) 2023-05-04
CN118159942A (zh) 2024-06-07
JP7662046B2 (ja) 2025-04-15
US20240272896A1 (en) 2024-08-15

Similar Documents

Publication Publication Date Title
CN112099829B (zh) 车辆升级控制方法及系统、ota后台、车辆
CN108572833B (zh) 自动应用更新
CN101576828B (zh) 软件版本升级方法及装置、服务器
CN112000434A (zh) 一种基于Kubernetes动态管理服务治理规则配置方法和系统
CN102855152B (zh) 升级应用程序中资源文件的方法及系统
US8032588B2 (en) System and method for hosting one or more versions of a service using a service proxy
CN105208127A (zh) 一种网页缓存处理方法及系统以及智能终端
CN115136122B (zh) 主装置、数据分发系统以及更新控制程序
KR102658819B1 (ko) 리소스 캐싱 방법 및 이를 지원하는 전자 장치
AU2019256257A1 (en) Processor core scheduling method and apparatus, terminal, and storage medium
KR102266089B1 (ko) Mec 시스템 및 그 제어방법
CN114125028A (zh) 微应用的运行方法、装置、设备、存储介质及程序产品
CN102984225A (zh) 移动装置的空中预订
CN103036916A (zh) 远程硬件资源的调用方法及其装置、系统
WO2023185166A1 (zh) 服务调用方法、装置、设备及存储介质
WO2021082733A1 (zh) 移动通信方法及装置、存储介质、电子装置
KR20090039155A (ko) 이기종 어플리케이션을 연동하기 위한 방법 및 스마트폰
CN114969223A (zh) 一种地图更新方法、装置及系统
CN115242970B (zh) 车机摄像头数据共享系统、方法、电子设备及存储介质
US20240311135A1 (en) Center device and campaign information distribution method
WO2023074091A1 (ja) センタ装置
CN115857985A (zh) 一种座舱升级系统、运行方法及存储介质
CN118708205A (zh) 动态配置更新方法、系统、电子设备及存储介质
JP6194731B2 (ja) 決済システム
CN115016685A (zh) 显示控制方法、装置、穿戴设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22886425

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023556140

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202280071974.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112022005159

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22886425

Country of ref document: EP

Kind code of ref document: A1