Application management device and application management server

Abstract

This application management device comprises a display device, a program execution unit, and a storage device that stores a software development kit, wherein the program execution unit is programmed to implement: an application development function for developing an application to be executed by the program execution unit, using the software development kit; a function for generating management information for managing the application developed by the application development function; a log acquisition setting function for setting the acquisition of execution logs of the application; an authentication information acquisition function for acquiring authentication information for authenticating the developer of the application; and a function for transmitting the application, the management information, set information set by the log acquisition setting function, and the authentication information to an application management server.

Description

Application management device and application management server

[0001] This disclosure relates to an application management device and an application management server. This application claims priority based on Japanese Patent Application No. 2023-080721, filed May 16, 2023, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Patent Document 1 discloses a maintenance management system that executes multiple types of pre-set maintenance management functions for each partial service as maintenance processing for an application for providing a service consisting of multiple partial services, and that is characterized by comprising: multiple operation component function units that are provided for each of the partial services and each of the maintenance management functions, and that have an execution unit that starts the action of the corresponding function when it detects result information that determines that the corresponding action has been completed in all partial services for other maintenance management functions that have been pre-set as a precursor to the action of the corresponding function, and an action notification unit that issues a start message when the action of the corresponding function starts and an end message when the action of the function is completed; and an action merging determination unit that is connected to the multiple operation component function units via a message bus, and that determines whether the corresponding action has been completed in all partial services for each of the maintenance management functions based on the start message and end message issued from the action notification unit of each operation component function unit, and that, when it determines that the corresponding action has been completed in all partial services, sends the corresponding result information to the multiple operation component function units.

[0003] Japanese Patent Application Laid-Open No. 2020-135504

[0004] An application management device according to one aspect of the present disclosure includes a display device, a program execution unit, and a storage device storing a software development kit, wherein the program execution unit is programmed to implement an application development function that uses the software development kit to develop an application to be executed by the program execution unit, a function that generates management information for managing the application developed by the application development function, a log acquisition setting function that configures the acquisition of execution logs of the application, an authentication information acquisition function that acquires authentication information for authenticating the developer of the application, and a function that transmits the application, the management information, the setting information set by the log acquisition setting function, and the authentication information to an application management server.

[0005] FIG. 1 is a schematic diagram showing a schematic configuration of an application management system according to a first embodiment of the present disclosure. FIG. 2 is a schematic diagram showing a schematic configuration during execution of application management by the application management system according to the first embodiment of the present disclosure. FIG. 3 is a schematic diagram showing a functional configuration of the development terminal shown in FIG. 1. FIG. 4 is a schematic diagram showing a schematic configuration of the management information generation program shown in FIG. 3. FIG. 5 is a table showing a schematic configuration of application management information in tabular form. FIG. 6 is a schematic diagram showing an example of a screen display of the development terminal according to the first embodiment of the present disclosure. FIG. 7 is a schematic diagram showing a configuration of an execution environment according to the first embodiment of the present disclosure. FIG. 8 is a sequence diagram of application management in the application management system according to the first embodiment of the present disclosure. FIG. 9 is a schematic diagram showing an application registration process according to the first embodiment of the present disclosure. FIG. 10 is a schematic diagram showing an application registration process according to the first embodiment of the present disclosure. FIG. 11 is a schematic diagram showing an application approval process according to the first embodiment of the present disclosure. FIG. 12 is a schematic diagram showing an application distribution process according to the first embodiment of the present disclosure. Fig. 13 is a schematic diagram showing another example of the application distribution process in the first embodiment of this disclosure. Fig. 14 is a diagram showing the appearance of the development terminal in the first embodiment of this disclosure. Fig. 15 is a hardware block diagram of the development terminal shown in Fig. 14.

[0006] Next-generation connected cars are expected to realize connected services that are compatible with the CASE (Connected, Autonomous / Automated, Shared, Electric) era. Therefore, it is expected that the vehicle's electrical / electronic architecture will be centrally controlled. Furthermore, it is expected that software, including applications, will be frequently added and updated via over-the-air (OTA) from outside the vehicle.

[0007] Mobility services are evolving and becoming more diverse every day, and as a result, a wide variety of applications and service software (hereinafter referred to as "applications, etc.") will undoubtedly run on the onboard devices of connected cars.

[0008] In such a situation, it is necessary to consider the possibility that applications run by in-vehicle devices may become targets of attacks by malicious third parties, just like regular web servers and smartphone apps. In order to provide safety and security in next-generation connected cars, it is essential to manage the applications running in the vehicle.

[0009] In the circumstances described above, it is necessary to reliably manage applications and other data that run on next-generation connected cars. However, introducing dedicated applications or management infrastructure into connected cars to manage applications and other data presents a problem: high implementation costs. In addition, applications that run on in-vehicle devices are not necessarily created by a single provider. It is extremely difficult to centrally manage applications created by multiple providers.

[0010] One proposal for solving these problems is disclosed in Patent Document 1. According to Patent Document 1, this technology makes it possible to easily execute maintenance management processing for service provision applications.

[0011] The technology disclosed in Patent Document 1 makes it possible to easily perform maintenance work on applications created by multiple businesses, but the technology in Patent Document 1 does not allow for centralized management of the contents of individual applications.

[0012] [Problem to be Solved by the Present Disclosure] An object of the present disclosure is to provide an application management device and an application management server that can centrally manage applications created by multiple businesses.

[0013] Effect of the Present Disclosure As described above, according to the present disclosure, it is possible to provide an application management device and an application management server that can centrally manage applications created by multiple businesses.

[0014] [Description of the embodiments of the present disclosure] In the following description and drawings, the same components are denoted by the same reference numerals. Therefore, detailed description thereof will not be repeated. Note that at least some of the embodiments described below may be combined in any manner.

[0015] (1) According to a first aspect of the present disclosure, there is provided an application management device including a display device, a program execution unit, and a storage device storing a software development kit (SDK), wherein the program execution unit is programmed to implement an application development function for developing an application to be executed by the program execution unit using the software development kit, a function for generating management information for managing the application developed by the application development function, a log acquisition setting function for configuring acquisition of an execution log of the application, an authentication information acquisition function for acquiring authentication information for authenticating a developer of the application, and a function for transmitting the application, the management information, the setting information set by the log acquisition setting function, and the authentication information to a predetermined application management server. This configuration enables authentication of a developer of an application created using an SDK (Software Development Kit), and enables centralized management of applications in the application management server.

[0016] (2) In the above (1), the function of generating management information may include at least one of a function of creating attribute information of the application necessary for managing the application, a function of acquiring a hash value of the application, a function of acquiring library information identifying libraries used by the application, a function of creating a schedule for distributing the application to terminals, a function of generating version information of the application based on revision details of the application input by the developer, a function of allowing the developer to specify an installation destination of the application, and a function of allowing the developer to specify an installation time of the application. With this configuration, in addition to authenticating the developer of an application created using the SDK, at least one of application attributes, verification of application authenticity, application vulnerabilities, distribution schedule, version information, installation destination, installation time, etc. can be managed in the application management server, enabling centralized management of applications.

[0017] (3) In the above (1) or (2), the log acquisition setting function may include a transfer mechanism specification function that specifies a transfer mechanism for transferring messages output from the application when the application is executed to a device other than the device on which the application is running. With this configuration, in addition to authenticating the developer of an application created using the SDK, the application management server can manage the transfer destination of messages output from the application, enabling centralized management of applications.

[0018] (4) In the above (3), the messages output from the application may include a message to a standard output and a message to a standard error output, and the transfer mechanism specification function may specify the transfer mechanism for the messages to the standard output and the messages to the standard error output independently of each other. With this configuration, in addition to authenticating the developer of an application created using the SDK, the transfer destinations for normal messages and error messages output from the application can be managed separately in the application management server, enabling centralized management of applications.

[0019] (5) In the above (4), the application is intended to be executed as a Docker container, and the transfer mechanism specification function may specify a logging driver that processes the output of the application in the Docker system. This configuration not only authenticates the developer of an application created using the SDK, but also makes it easy to separately manage the transfer destinations of normal messages and error messages output from the application on the application management server. As a result, applications can be centrally managed.

[0020] (6) In any of (1) to (5) above, the authentication information acquisition function may include an authentication information acquisition function that acquires the developer's identification information from the developer. With this configuration, the application management server can obtain information necessary for authenticating the developer of an application created using the SDK from the developer himself / herself, and authenticate the developer. As a result, applications can be managed centrally.

[0021] (7) According to a second aspect of the present disclosure, an application management server includes a storage device and a program execution unit. The program execution unit is programmed to receive, from an application management device, management information for managing an application developed by the application management device, log acquisition setting information indicating settings for acquiring an execution log of the application, and authentication information for authenticating a developer of the application, and to execute: a developer authentication function for authenticating the developer of the application; an approval processing execution function for performing an approval process for obtaining approval for distribution to a distribution destination for the application that has been authenticated by the developer authentication function; and an application distribution function for distributing the application that has been approved by the approval processing execution function to the distribution destination in accordance with conditions specified by the management information. This configuration enables the application management server to authenticate the developer of the application and set up log acquisition from the application, and to acquire management information for managing the application. As a result, applications can be managed centrally in the application management server.

[0022] (8) In the above (7), the management information may include a schedule for distributing the application to terminals and the types of terminals to which the application is to be distributed, and the application distribution function may include a schedule distribution function for distributing the application to terminals that are compatible with the terminal types according to the schedule. This configuration enables the application management server to authenticate application developers and set up log acquisition from applications, and also uses the management information to manage application distribution schedules and distribution targets, and distribute applications to specified types of terminals according to the schedule. As a result, applications can be managed centrally in the application management server.

[0023] (9) In the above (8), the schedule distribution function may include a task preparation function that specifies the terminal type, the schedule, and information identifying the application, and prepares a task for downloading the application from the application management server to the terminal device. With this configuration, by preparing a task for application distribution in the application management server, the application can be distributed to the specified type of terminal according to the schedule. As a result, applications can be managed centrally in the application management server.

[0024] This disclosure can be realized not only as an application management device and an application management server equipped with such characteristic processing units, but also as an application management method having such characteristic processing steps, as a program for causing a computer to execute such steps, as a semiconductor integrated circuit that realizes part or all of the application management device, or as an application management system that includes the application management device.

[0025] [Details of the embodiment of the present disclosure] Specific examples of an application management device and an application management server according to the embodiment of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope of the claims.

[0026] 1. First Embodiment Referring to FIG. 1 , an application management system 50 according to a first embodiment of the present disclosure is operated by a business operator (hereinafter referred to as the "controlling business operator") that controls systems to be developed. The application management system 50 includes a development terminal 60 used by a developer 80 who develops the system. A software development kit (SDK (Software Development Kit)) 62 created by the control business operator for application development and distributed to each developer is installed in the development terminal 60. The development terminal 60 develops applications using the SDK 62. The SDK 62 not only includes tools for application development, but also various mechanisms for managing applications developed using the SDK 62.

[0027] The application management system 50 further includes an application management server 68 that receives an upload 66 of an application program 64 developed by a developer 80, performs authentication processing for the developer 80 and approval processing by an approver 70 of the central business operator, and then performs distribution processing 74 of the approved application 72 to an onboard device 78 installed in a vehicle 76 to which the application is to be distributed. In Figure 1, the application management server 68 is shown as a so-called cloud.

[0028] 2, when an on-board device 78 of a vehicle 76 operates an application distributed from an application management server 68, the on-board device 78 transmits management information 110 output by the application to an application operation server 112. An administrator 114 of the system operator 100 manages the operation status of each application based on the management information received by the application operation server 112. In this embodiment, the management information 110 is assumed to be a log output by each application that is running.

[0029] The development terminal 60, application management server 68, and on-board device 78 do not need to be located within the same country. For example, the development terminal 60 is often located in multiple countries. The same is true for the application management server 68. In other words, the application management server 68 is a so-called cloud, and multiple servers may be located in various countries and regions and communicate with each other to implement the functions of a single application management server 68. Furthermore, the country in which the on-board device 78 is located is not limited by the country or region in which the development terminal 60 or the application management server 68 is located.

[0030] 3, input / output devices necessary for creating an application, such as monitor 140 and keyboard 142, are connected to development terminal 60 shown in Fig. 1. Development terminal 60 includes a communication unit 162 for performing two-way communication with application management server 68, and a program execution unit 160 including a CPU (Central Processing Unit) 170. In other words, development terminal 60 is a computer equipped with communication unit 162. Monitor 140 and keyboard 142 each communicate with CPU 170 via an appropriate interface.

[0031] Development terminal 60 further includes a storage unit 164 connected to program execution unit 160. Storage unit 164 includes a volatile storage device that allows high-speed access, such as RAM (Random Access Memory), and a non-volatile storage device that has relatively slow access speeds, such as an SSD (Solid State Drive) or a hard disk. The former is primarily used as temporary storage during program execution, while the latter is used as a storage device for information that is not frequently accessed, such as the program or post-collection management information.

[0032] 1 , a management information generation program 182, and a log acquisition setting program 184. The management information generation program 182 generates management information to be added to an application when the application is uploaded to the application management server 68. The log acquisition setting program 184 performs settings related to the log that the uploaded application outputs during operation.

[0033] The storage unit 164 further stores an authentication information acquisition program 186 and an upload program 188. The authentication information acquisition program 186 acquires authentication information from the developer 80 for performing authentication processing for the developer 80 when uploading the application to the application management server 68. The upload program 188 executes processing to upload the completed application to the application management server 68.

[0034] Fig. 4 shows details of various functions related to application management possessed by management information generation program 182 shown in Fig. 3. Referring to Fig. 4, management information generation program 182 includes an attribute information creation function 230 that creates attribute information that indicates the attributes of an application, a hash value calculation function 232 that calculates a hash value for verifying the identity of the finally completed application, a version information creation function 234 that creates version information that changes as the application is modified, and a schedule creation function 236 that creates a distribution schedule for the completed application.

[0035] The management information generation program 182 further includes a library information acquisition function 238 for acquiring information about the libraries used internally by the application, an installation destination setting function 240 for setting information about the vehicle-mounted device to which the application will be distributed and installed, and, if necessary, an installation time setting function 242 for setting the time at which the application will be distributed to the installation destination.

[0036] By using these functions, the management information generation program 182 generates management information for managing applications created using the SDK 180 .

[0037] Details of the management information are shown in Fig. 5. Referring to Fig. 5, items to be managed by the management information include the name of the application, the version, the hash value, a list of Open Source Software (OSS) libraries used (OSS list), the installation destination, and the installation time.

[0038] The information managed for each managed item includes the creator of the managed item, information about how the content of the managed item was created or obtained, and the use of the managed item.

[0039] An example of management information is shown in Figure 5. In this example, the creator of the application name is the developer. The method of obtaining or creating this name is that the SDK 180 obtains the name entered by the developer. The purpose of this information is to use it as an identifier for identifying the application.

[0040] The SDK is the creator of the version information, and creates it by combining the revision details specified by the developer with information about all versions of the same application that the SDK retrieves from the cloud. The version information is used as an identifier together with the application name.

[0041] A method for creating version information will be described with reference to Fig. 6. Fig. 6 shows an application upload screen 270. As can be seen from the title 300, "Register application test1 on the server," the upload screen 270 is a screen used when an application developer uploads a completed application to the application management server 68 shown in Fig. 1.

[0042] The upload screen 270 further includes a change specification list 302 consisting of four options that the developer can select regarding changes made to the application by the developer. The change specification list 302 includes four check boxes. The first check box is selected when a new application is created. The second check box is selected when revisions are made to the application that significantly affect the appearance, operability, or behavior of the application's interface. The third check box is selected when minor functional improvements or partial additions are made to the application. The fourth check box is selected when bug fixes or minor modifications are made to the application.

[0043] The upload screen 270 further includes an ID field 304, a password field 306, a send button 308, and a cancel button 310. The ID field 304 is used to input a developer's identifier. The password field 306 is used to input a password assigned to the developer. The send button 308 is clicked to send the application to the application management server 68 after confirming the password input. The cancel button 310 is clicked to cancel the transmission and return the screen to the previous screen.

[0044] The version information is created mainly based on which option in the change specification list 302 is selected. For example, when creating a new version, the version information is set to "1.0.0". When the second option is selected, if the version information of the previous version was "X.Y.Z", the new version information increments X. When the third option is selected, Y is incremented. And when the fourth option is selected, Z is incremented.

[0045] 5, the creator of the hash value is the SDK. The SDK calculates the hash value of the application before uploading it, and the hash value is used to determine whether the application has been tampered with or impersonated.

[0046] The OSS list is created by the SDK, which obtains the names of libraries included in applications. This information is used to determine whether the libraries included in the applications have vulnerabilities.

[0047] The developer is the creator of the information about the installation destination. The developer decides on the installation destination and enters it on a predetermined input screen prepared by the SDK, and the SDK acquires this information. The information about the installation destination is selected by the developer in order to control the installation destination of the application. This installation destination is specified, for example, by the model number of the corresponding in-vehicle device, the identifier of the individual in-vehicle device, etc.

[0048] Information regarding the installation time is created by the developer. The developer inputs the installation time on a specific input screen prepared by the SDK. This information is specified by the developer to control the installation time of the application. Depending on the service, it may be desirable to change the specifications all at once at a specific timing. In such cases, the installation time of the application may be specified. Note that if the application distribution time and distribution location are input, they are added to the application management information as additional information.

[0049] The log acquisition setting function (log acquisition setting function) will be described below. Referring to FIG. 7 , in this embodiment, a container (Docker container) 360 provided by Docker (registered trademark) is used as the execution environment 350 for each application. The Docker logging mechanism is used for log output. In the logging mechanism, normal logs from applications are output to standard output 362, and error logs are output to a network 364. Note that standard output is usually written as stdout, and standard error output is written as stderr.

[0050] A logging driver 366 is individually specified for each of the standard output 362 and the network 364. By specifying the logging driver 366, the format of the log, the transfer destination, and the like can be specified. This makes it possible to analyze the log at the transfer destination and then transfer the results to the cloud. For example, the first driver 368 can convert the log output to the standard output 362 into a predetermined format and transfer it to the first transfer destination 370, and the second driver 372 can convert the log output to the network 364 into a predetermined format and transfer it to the second transfer destination 374. The log output settings are information for specifying which logging driver to use, in what format, at what timing, and to where the logs output by the application to the standard output 362 and the network 364 will be transferred. These settings are made by the log acquisition setting program 184 shown in FIG. 3. The program that performs log acquisition is provided by Docker and is separate from the log acquisition setting program 184. The function of specifying a transfer mechanism for transferring messages output from an application during execution of the application to a device other than the device on which the application is running is referred to as a "transfer mechanism specification function." Also, the system provided by Docker is referred to as a "Docker system."

[0051] 8 shows a sequence diagram of processing among the developer 80, SDK 62, application management server 68, approver 70, administrator 114, and in-vehicle device 78 in this embodiment. Referring to FIG. 8, the developer 80 first performs application development 400 using the SDK 62. Next, the developer 80 launches the upload screen 270 shown in FIG. 9 (FIG. 6) to upload the application to the application management server 68 shown in FIG. 1. The developer 80 selects one of the change specification lists 302 and enters his / her own identifier in the ID field 304 and his / her password in the password field 306.

[0052] At this time, the management information generation program 182 shown in FIG. 3 executes the application management information acquisition process 402 shown in FIG. 8 based on input from the developer 80 and the contents of the application. Specifically, the attribute information creation function 230 of the application management information acquisition process 402 shown in FIG. 4 creates application attribute information (e.g., application name, creator name, transmission time, etc.). The hash value calculation function 232 calculates a hash value based on the object code of the application. The version information creation function 234 creates new version information based on the change specification list 302 and version information of an application with the same name collected from the application management server 68. The schedule creation function 236 creates schedule information based on a schedule specified by the developer 80. The library information acquisition function 238 acquires library information from, for example, a library included in the object program. The installation destination setting function 240 sets information related to the installation destination based on input from the developer 80. The installation time setting function 242 sets the installation time based on input from the developer 80. All of this management information is information associated with the application.

[0053] Next, a log information acquisition setting process 404 is executed. Specifically, the log acquisition setting program 184 shown in Fig. 3 sets the logging driver used by the application in the Docker container based on the content of the application for both the standard output 362 and the network 364 shown in Fig. 7. In this embodiment, this information is realized as a series of commands that configure the container according to the specified settings.

[0054] 8, next, application authentication processing 406 is executed. Authentication processing 406 is executed when developer 80 starts application authentication processing 440 by clicking send button 308 on upload screen 270 shown in FIG.

[0055] Specifically, when the developer 80 clicks the send button 308 shown in FIG. 9 , the SDK 62 adds application management information, log information acquisition setting information, and authentication information consisting of the identifier and password of the developer 80 to the application. The application management information is acquired in an application management information acquisition process 402. The log information acquisition setting information is set in a log information acquisition setting process 404. The identifier of the developer 80 is entered in the ID field 304 in FIG. 9 , and the password of the developer 80 is entered in the password field 306 in FIG. 9 . The SDK 62 executes an application sending process 442 that sends this information to the application management server 68.

[0056] The application management server 68, which receives this application along with the management information and authentication information, executes developer authentication 444. That is, the application management server 68 references a developer database managed by the application management server 68 (or another authentication server) and compares the developer 80's identifier and password with the recorded information to authenticate the developer. If authentication fails, the application management server 68 notifies the SDK 62 accordingly. Referring to FIG. 9, if this authentication is successful, the application is registered in the application management table 482 together with the management information (bottom line of FIG. 9). However, distribution of the application has not yet been approved. Therefore, a value indicating that the application (test1) being processed is not yet approved and therefore not available for distribution is assigned to the flag indicating whether it is available for distribution (indicated by "Not Yet" in FIG. 10).

[0057] After this, the application management server 68 starts the application approval process 408 .

[0058] In the example shown in Figure 9, the developer 80 enters his or her own identifier and password, as shown on the upload screen 270. However, this disclosure is not limited to such an embodiment. For example, instead of having the developer 80 manually enter the identifier and password, the developer 80 may be provided with a card-type employee ID card on which information corresponding to the identifier and password is recorded in advance. Figure 10 shows such an example.

[0059] 10 , upload screen 500 of this example differs from upload screen 270 shown in FIG. 9 in that, instead of ID field 304 and password field 306 of upload screen 270, upload screen 500 displays prompt 504 prompting the user to hold their employee ID card over a card reader. In other respects, upload screen 500 is the same as upload screen 270. However, a card reader 502 must be connected to development terminal 60 so that it can read employee ID cards. After reading information corresponding to developer 80's identifier and password from the employee ID card, the processing performed by upload screen 500 is the same as the processing performed by upload screen 270.

[0060] 8 again, in application approval processing 408, the application management server 68 makes an application approval request 450 for an application that has successfully passed developer authentication 444 to an approver 70 preset in the project. Specifically, the application management server 68 sends the application approval request 450 to the approver 70 via a workflow, email, or the like. In response to this application approval request 450, the approver 70 confirms 452 the contents of the application and management information. If there are no particular problems, the approver 70 makes approval 454 for the distribution of the application. Information regarding approval 454 is sent to the application management server 68. As a result, the application becomes available for distribution.

[0061] The details of the application approval process 408 (FIG. 8) in this embodiment will be described with reference to FIG. 11. As shown in FIG. 11, before the approval of application test1, the distribution approval column 572 of the record 570 storing the information of application test1 in the application management table 482 is set to "Not Yet". In other words, the distribution of application test1 has not yet been approved.

[0062] In this embodiment, when the authentication process for an application is completed, an approval request is first sent from the application management table 482 to the first administrator 550. If the first administrator 550 approves this approval request, an approval request is further sent to the second administrator 552. If the second administrator 552 approves this approval request, an approval request is further sent to the supervisor 554. If the supervisor 554 approves this approval request, the value of the distribution approval column 572 of the record 570 becomes "Done," as shown in the application management table 482 shown in the lower part of FIG. 11 . As a result, it becomes possible to distribute the application test1 to each in-vehicle device.

[0063] In this embodiment, as described above, an application cannot be distributed without approval from three parties: two administrators and the person in charge. However, this disclosure is not limited to such an embodiment. The approval path may be changed based on the importance and behavior of the application. For example, an approval path may be set up such that stricter approval processing is performed for an application that only reads data and an application that writes data. The higher the importance of the application, the more approvers may be required, or approval may be required from approvers with higher authority.

[0064] 8 , after the application approval process 408 is completed, when the administrator 114 determines that it is time to transmit the application to the in-vehicle device 78, the administrator 114 issues an instruction 410 to the application management server 68 to distribute the application to the in-vehicle device by OTA. In response to this instruction 410, the application management server 68 executes an OTA task creation / addition process 412.

[0065] The instruction 410 and the OTA task creation / addition process 412 will be described with reference to Fig. 12. As already described, the application management server 68 includes a software management program 610 that receives an application uploaded from the development terminal 60, authenticates the developer, verifies the authenticity of the application, and executes distribution approval processing.

[0066] For example, distribution manager 580 determines to which in-vehicle device an application (e.g., application test1) will be distributed (installed) and when, and issues instructions to software management program 610. In response to this instruction, software management program 610 creates a task 622 for application distribution for each applicable application and registers it in task management table 616. In this embodiment, the task is to install or update the application via OTA.

[0067] The application management server 68 further includes a software distribution program 612 and a software storage unit 614. The software distribution program 612 reads out a task that has reached its designated distribution time from among the tasks registered in the task management table 616. The software distribution program 612 distributes and installs the application specified by the task to the distribution destination specified by the task. The software storage unit 614 stores software (applications) managed by the software management program 610 as the application management table 482.

[0068] Specifically, the software distribution program 612 performs the following processing. Returning to FIG. 8 , when the application management server 68 executes the OTA task creation / addition processing 412, it becomes ready to issue a task instruction to the onboard device 78 corresponding to that task. When the onboard device 78 starts up in this state, the onboard device 78 performs an application acquisition processing 618 as follows. That is, the onboard device 78 executes a client processing 414 that accesses the application management server 68 (or an intermediate message broker) according to the MQTT (Message Queuing Telemetry Transport) protocol and determines whether there is a message for the onboard device 78. If there is a message, the onboard device 78 reads a task 624 ( FIG. 12 ) specified by the message from the application management server 68. The task 624 is a task 416 ( FIG. 8 ) that downloads an application from a predetermined address in the software storage unit 614 of the application management server 68 and instructs the onboard device 78 to install the application. Upon receiving this instruction, the in-vehicle device 78 accesses 626 ( FIG. 12 ) the specified address in the software storage unit 614 and retrieves 418 ( FIG. 8 ) the application from that address. The in-vehicle device 78 then compares the hash value calculated for the retrieved application with the hash value in the management information to verify the validity of the application, and then installs 420 the application. This installation 420 is an addition if no older version of the application exists, or an update if an older version exists. Upon completing the application installation 420, the in-vehicle device 78 transmits an installation completion notification 422 to the application management server 68. By performing this process, a specific application can be distributed to each of the in-vehicle devices 78 specified by the administrator 114 at the time specified by the distribution administrator 580.

[0069] 8, after the installation of the application is completed at 420, the in-vehicle device 78 starts executing the application. As a result, as shown in FIG. 7, the log output by the application is acquired by a logging driver defined by the log information acquisition setting, and the information (log) that is the content of the log is periodically uploaded at 424 and 426 to the application management server 68 by the application management agent.

[0070] 13, the operation of the application management server 68 when the developer 80 shown in FIG. 1 has added additional information 630 to an application will be described. As already described, the additional information 630 includes the distribution time (distribution period) of the application and installation destination information. This information is added to the application management table 482 in the form of additional information 630 for the corresponding application (e.g., application test1) in the application management table 482. In this embodiment, the additional information 630 includes the installation destination of the corresponding application (specific information of the relevant in-vehicle device), status information indicating whether the application has been distributed, and the installation time (period).

[0071] When application management table 482 has additional information such as additional information 630, software management program 610 can automatically read the distribution time and installation destination of the application from additional information 630, and automatically prepare task 622 according to the read information and write it to task management table 616. After the task is written to task management table 616, the application is distributed in the same manner as when distribution manager 580 determines the installation destination and distribution time.

[0072] 2. Implementation by a Computer Figure 14 is an external view of a computer system that operates as, for example, the development terminal 60 shown in Figure 1. The computer that constitutes the application management server 68 has a similar configuration.

[0073] Figure 15 is a hardware block diagram of the computer system shown in Figure 14. Note that application management server 68 shown in Figure 1 can also be realized essentially by a computer system having a configuration similar to that of development terminal 60. Here, only the configuration of the computer system that operates as development terminal 60 will be described, and detailed configurations of computer systems that realize other devices will not be described.

[0074] 14, this development terminal 60 includes a computer 640 having a DVD (Digital Versatile Disc) drive 672, and a keyboard 644, a mouse 646, and a monitor 642 for interacting with a user, all of which are connected to computer 640. Of course, these are just one example of a configuration for when user interaction becomes necessary, and any general hardware and software that can be used for user interaction (for example, a touch panel, voice input, or a general pointing device) can be used.

[0075] 15 , computer 640 includes a CPU 660, a graphics processing unit (GPU) 662, and a bus 680 connected to CPU 660, GPU 662, and DVD drive 672, in addition to a DVD drive 672. Computer 640 further includes a read-only memory (ROM) 666, a RAM 668, and an SSD 670. ROM 666 is connected to bus 680 and stores a boot-up program for computer 640 and the like. RAM 668 is connected to bus 680 and stores instructions constituting a program, a system program, working data, and the like. SSD 670 is a non-volatile memory connected to bus 680. The SSD 670 is used to store programs executed by the CPU 660 and the GPU 662, as well as data used by the programs executed by the CPU 660 and the GPU 662. The computer 640 further includes a network I / F (Interface) 678 and a USB (Universal Serial Bus) port 676. The network I / F 678 provides connection to a network 656 (network 364 shown in FIG. 7 ) that enables communication with other terminals. The USB port 676 allows a USB memory 654 to be attached / detached and provides communication between the USB memory 654 and each section within the computer 640.

[0076] The computer 640 further includes an audio I / F 674. The audio I / F 674 is connected to the microphone 652, the speaker 650, and the bus 680, and has the function of reading audio signals, video signals, and text data in accordance with instructions from the CPU 660, converting them to analog, amplifying them, and driving the speaker 650. The audio signals, video signals, and text data are generated by the CPU 660 and stored in the RAM 668 or the SSD 670. The audio I / F 674 also has the function of digitizing the analog audio signal from the microphone 652 and storing it at an arbitrary address in the RAM 668 or the SSD 670 specified by the CPU 660.

[0077] In the above embodiment, programs implementing the functions of development terminal 60, application management server 68, and the like are stored in a storage medium such as SSD 670, RAM 668, DVD 648, USB memory 654, or an external device (not shown). The external device is connected to bus 680 via network I / F 678 and network 656. Typically, these data and parameters are written to SSD 670 from an external device, for example, and loaded into RAM 668 when computer 640 is executed.

[0078] 1 and the functions of each of their components is stored on a DVD 648 inserted into a DVD drive 672, and the computer programs for operating the computer system are transferred from the DVD drive 672 to the SSD 670. Alternatively, the programs may be stored on a USB memory 654, which may be inserted into a USB port 676 and the programs transferred to the SSD 670. Alternatively, the programs may be transmitted to the computer 640 via the network 656 and stored on the SSD 670.

[0079] The program is loaded into RAM 668 when executed. Of course, the source program may be input using keyboard 644, monitor 642, and mouse 646, and the compiled object program may be stored in SSD 670. In the case of a program that runs on a virtual machine as in the above embodiment, a program that functions as a virtual machine environment must be installed in advance on computer 640.

[0080] The CPU 660 reads a program from the RAM 668 according to an address indicated by an internal register called a program counter (not shown), interprets the instructions, reads data necessary to execute the instructions from the RAM 668, the SSD 670, or another device according to the address specified by the instruction, and executes the processing specified by the instruction. The CPU 660 stores the execution result data at an address specified by the program, such as in the RAM 668, the SSD 670, or a register within the CPU 660. At this time, the value of the program counter is also updated by the program. The computer program may be loaded directly into the RAM 668 from the DVD 648, the USB memory 654, or via the network 656. Note that some tasks (mainly numerical calculations) of the program executed by the CPU 660 are dispatched to the GPU 662 according to instructions included in the program or according to the analysis results of the CPU 660 when executing the instructions.

[0081] The program that causes computer 640 to implement the functions of each unit according to the above-described embodiment includes a plurality of instructions written and arranged to cause computer 640 to operate to implement those functions. Some of the basic functions required to execute these instructions may be provided by an operating system (OS) running on computer 640, a third-party program, various toolkit modules installed on computer 640, or a program execution environment. Therefore, this program does not necessarily include all of the functions required to implement the system and method of this embodiment. This program need only include instructions that execute the operations of the above-described devices and their components by statically linking appropriate functions or modules at compile time or by dynamically calling them at runtime in a controlled manner to achieve the desired results. The method for operating computer 640 in this manner is well known, and will not be repeated here.

[0082] The GPU 662 is capable of parallel processing, and can execute a large amount of calculations involved in machine learning simultaneously in parallel or in a pipelined manner. For example, parallel calculation elements discovered in a program when the program is compiled or when the program is executed are dispatched from the CPU 660 to the GPU 662 as needed, and executed. The results are returned to the CPU 660 directly or via a predetermined address in the RAM 668, and assigned to a predetermined variable in the program.

[0083] Each process (each function) in the above-described embodiments is implemented by a processing circuit (circuitry) including one or more processors. The processing circuit may be configured with an integrated circuit that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute each of the processes. The one or more processors may execute each of the processes according to the program read from the one or more memories, or according to a logic circuit designed in advance to execute each of the processes. The processor may be a CPU, GPU, DSP (Digital Signal Processor), FPGA (Field-Programmable Gate Array), ASIC (Application Specific Integrated Circuit), or any other processor suitable for computer control. The physically separated processors may cooperate with each other to execute the processes. For example, the processors installed in the physically separated computers may cooperate with each other via a network such as a local area network (LAN), a wide area network (WAN), or the Internet to execute the processes. The program may be installed in the memory from an external server device or the like via the network, or may be distributed in a state stored on a recording medium such as a compact disc read-only memory (CD-ROM), a digital versatile disc read-only memory (DVD-ROM), or a semiconductor memory, and installed in the memory from the recording medium.

[0084] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present disclosure is not defined by the detailed description of the disclosure, but by the claims of the appended claims, and is intended to include all modifications within the meaning and scope of the claims.

[0085] DESCRIPTION OF SYMBOLS 50 Application management system 60 Development terminal 62, 180 SDK 64 Application program 66, 424, 426 Upload 68 Application management server 70 Approver 72 Application 74 Distribution processing 76 Vehicle 78 Vehicle-mounted device 80 Developer 100 System operator 110 Management information 112 Application operation server 114, 550, 552 Administrator 140, 642 Monitor 142, 644 Keyboard 160 Program execution unit 162 Communication unit 164 Storage unit 170, 660 CPU 182 Management information generation program 184 Log acquisition setting program 186 Authentication information acquisition program 188 Upload program 230 Attribute information creation function 232 Hash value calculation function 234 Version information creation function 236 Schedule creation function 238 Library information acquisition function 240 Installation destination setting function 242 Installation time setting function 270, 500 Upload screen 300 Title 302 Change specification list 304 ID field 306 Password field 308 Send button 310 Cancel button 350 Execution environment 360 Container (Docker container) 362 Standard output 364, 656 Network 366 Logging driver 368 First driver 370 First transfer destination 372 Second driver 374 Second transfer destination 380 Docker container 400 Application development 402 App management information acquisition process 404 Log information acquisition setting process 406, 440 Authentication process 408 Application approval process 410 Instruction 412 OTA task creation / addition process 414 Client process 416, 622, 624 Task 418 Acquisition 420 Installation 422 Installation completion notification 442 Application delivery process 444 Developer authentication 450 Application approval request 452 Content confirmation 454 Approval 482 Application management table 502 Card reader 504 Prompt 554 Person in charge 570 Record 572 Distribution approval column 580 Distribution manager 610 Software management program 612 Software distribution program 614 Software storage unit616 Task management table 618 Application acquisition process 626 Access 630 Additional information 640 Computer 646 Mouse 648 DVD 650 Speaker 652 Microphone 654 USB memory 662 GPU 666 ROM 668 RAM 670 SSD 672 DVD drive 674 Audio I / F 676 USB port 678 Network I / F 680 Bus

Claims

1. a display device; A program execution unit; a storage device storing a software development kit; The program execution unit an application development function for developing an application to be executed by the program execution unit using the software development kit; a function of generating management information for managing the application; a log acquisition setting function for setting acquisition of an execution log of the application; an authentication information acquisition function for acquiring authentication information for authenticating the developer of the application; an application management device programmed to implement a function of transmitting the application, the management information, the setting information set by the log acquisition setting function, and the authentication information to an application management server;

2. The function of generating the management information is a function of creating attribute information of the application necessary for managing the application; A function for obtaining a hash value of the application; a function of acquiring library information that identifies libraries used by the application; a function for creating a schedule for delivering the application to a terminal; a function of generating version information of the application based on the revision details of the application input by the developer; A function that allows the developer to specify the installation destination of the application; a function that allows the developer to specify the installation time of the application; The application management device according to claim 1 , comprising at least one of:

3. 3. The application management device according to claim 1, wherein the log acquisition setting function includes a transfer mechanism designation function that designates a transfer mechanism for transferring messages output from the application when the application is executed to a device other than the device on which the application is running.

4. The messages output from the application include a message to a standard output and a message to a standard error output; 4. The application management device according to claim 3, wherein said transfer mechanism designation function designates said transfer mechanisms for messages to said standard output and for messages to said standard error output independently of each other.

5. the application is intended to run as a Docker container; The application management device according to claim 4 , wherein the transfer mechanism specification function specifies a logging driver that processes output of the application in a Docker system.

6. 3. The application management apparatus according to claim 1, wherein the authentication information acquisition function includes an authentication information acquisition function for acquiring identification information of the developer from the developer.

7. A storage device; a program execution unit; The program execution unit a developer authentication function that receives, from an application management device, management information for managing an application developed by the application management device, log acquisition setting information indicating settings for acquiring an execution log of the application, and authentication information for authenticating a developer of the application, and authenticates the developer of the application; an approval process execution function that performs approval processing to receive approval for distribution to a distribution destination for the application that has been authenticated by the developer authentication function; an application management server programmed to execute an application distribution function that distributes the application approved by the approval processing execution function to a distribution destination in accordance with conditions specified by the management information.

8. the management information includes a schedule for distributing the application to a terminal and a type of terminal to which the application is to be distributed; 8. The application management server according to claim 7, wherein the application distribution function includes a schedule distribution function for distributing the application to a terminal that matches the terminal type according to the schedule.

9. The schedule distribution function is 9. The application management server according to claim 8, further comprising a task preparation function that specifies information identifying the terminal type, the schedule, and the application, and prepares a task for causing a terminal device to download the application from the application management server.