WO2024236881A1 - Application management device and application management server - Google Patents

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

The present 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 on May 16, 2023, the disclosure of which is incorporated herein in its entirety.

Patent Document 1 discloses a maintenance management system that executes multiple types of preset maintenance management functions for each partial service as maintenance processing for an application for providing a service composed of multiple partial services, and that is provided for each of the partial services and each of the maintenance management functions, and that has a plurality of operation component functional units 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 preset 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 corresponding function ends, and an action merging determination unit that is connected to the plurality of operation component functional units via a message bus and 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 by the action notification unit of each operation component functional unit, and that transmits the corresponding result information to the plurality of operation component functional units when it determines that the corresponding action has been completed in all partial services.

JP 2020-135504 A

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, and 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 an application developed by the application development function, a log acquisition setting function for setting up the acquisition of an execution log 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, the setting information set by the log acquisition setting function, and the authentication information to an application management server.

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 the functional configuration of the development terminal shown in FIG. FIG. 4 is a schematic diagram showing a schematic configuration of the management information generating program shown in FIG. FIG. 5 is a table showing a schematic configuration of the application management information. FIG. 6 is a schematic diagram showing an example of a screen display of the development terminal according to the first embodiment of this disclosure. FIG. 7 is a schematic diagram showing the 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 the process of application registration in the first embodiment of the present disclosure. FIG. 10 is a schematic diagram showing the process of application registration in the first embodiment of the present disclosure. FIG. 11 is a schematic diagram showing an approval process of an application in the first embodiment of the present disclosure. FIG. 12 is a schematic diagram showing an application distribution process in 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 the present 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.

Next-generation connected cars will be required to realize connected services that are suited to the CASE (Connected, Autonomous/Automated, Shared, Electric) era. For this reason, it is expected that the vehicle's electrical/electronic architecture will be centrally controlled in next-generation connected cars. In addition, it is expected that software, including applications, will be frequently added and updated in next-generation connected cars via OTA (Over-the-Air) from outside the vehicle.

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

In such a situation, it is necessary to consider the possibility that applications run by in-vehicle devices could 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, managing applications running in the vehicle is one of the essential aspects.

In the circumstances described above, it is necessary to ensure that applications that run on next-generation connected cars are managed properly. However, introducing dedicated applications or a management platform into connected cars to manage applications raises the issue of high implementation costs. In addition, there is the issue that applications that run on in-vehicle devices are not necessarily created by a single operator. It is extremely difficult to centrally manage applications created by multiple operators.

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 processes for service provision applications.

The technology disclosed in Patent Document 1 makes it easy to perform maintenance work on applications created by multiple businesses. However, the technology in Patent Document 1 does not allow for centralized management of the contents of individual applications.

[Problem to be solved by this 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 a plurality of businesses.

[Effects of the present disclosure]
As described above, according to this disclosure, it is possible to provide an application management device and an application management server that are capable of centrally managing applications created by a plurality of businesses.

[Description of the embodiments of the present disclosure]
In the following description and drawings, the same parts 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.

(1) An application management device according to a first aspect of this disclosure includes a display device, a program execution unit, and a storage device storing a software development kit, and 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 an application developed by the application development function, a log acquisition setting function for setting the 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 specified application management server. With this configuration, the developer of an application created by an SDK (Software Development Kit) can be authenticated, and the application can be centrally managed by the application management server.

(2) In (1) above, the function of generating management information may include at least one of the following: a function of creating attribute information of the application required 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 the revision contents of the application input by the developer; a function of allowing the developer to specify the installation destination of the application; and a function of allowing the developer to specify the installation time of the application. With this configuration, in addition to authenticating the developer of an application created by the SDK, at least one of the application attributes, verification of the authenticity of the application, application vulnerabilities, distribution schedule, version information, installation destination, installation time, etc. can be managed in the application management server, enabling centralized management of applications.

(3) In the above (1) or (2), the log acquisition setting function may include 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. With this configuration, in addition to authenticating the developer of an application created by the SDK, the transfer destination of messages output from the application can be managed by the application management server, enabling centralized management of applications.

(4) In (3) above, the messages output from the application may include messages to standard output and messages to standard error output, and the transfer mechanism designation function may designate the transfer mechanisms for the messages to standard output and the messages to standard error output independently of each other. With this configuration, in addition to authenticating the developer of an application created by 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.

(5) In (4) above, the application is intended to be executed as a Docker container, and the transfer mechanism designation function may designate a logging driver that processes the output of the application in the Docker system. With this configuration, in addition to authenticating the developer of an application created by the SDK, the transfer destinations of normal messages output by the application and the transfer destinations of error messages can be easily managed separately on the application management server. As a result, applications can be managed centrally.

(6) In any of (1) to (5) above, the authentication information acquisition function may include an authentication information acquisition function that acquires identification information of the developer from the developer. With this configuration, the application management server can obtain information required for authenticating the developer of an application created by the SDK from the developer himself, and execute authentication of the developer. As a result, centralized management of applications becomes possible.

(7) An application management server according to a second aspect of this disclosure includes a storage device and a program execution unit, and the program execution unit is programmed to receive from the application management device management information for managing an application developed by the application management device, log acquisition setting information indicating settings for acquiring execution logs of the application, and authentication information for authenticating the developer of the application, and to execute a developer authentication function for authenticating the developer of the application, an approval process execution function for performing approval processing for receiving approval for distribution to a distribution destination for the application for which authentication by the developer authentication function has been completed, and an application distribution function for distributing the application approved by the approval process execution function to a distribution destination in accordance with conditions specified by the management information. With this configuration, the application management server is able to authenticate the developer of the application and set log acquisition from the application, and management information for managing the application can be acquired. As a result, applications can be managed centrally in the application management server.

(8) In (7) above, 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 match the terminal types according to the schedule. This configuration not only enables the application management server to authenticate application developers and set log acquisition from applications, but also allows the application distribution schedule and distribution targets to be managed using the management information, and the application to be distributed to specified types of terminals according to the schedule. As a result, applications can be managed centrally in the application management server.

(9) In (8) above, the schedule distribution function may include a task preparation function that specifies the terminal type, the schedule, and information that identifies the application, and prepares a task for causing a terminal device to download the application from the application management server. With this configuration, the application management server can prepare a task for distributing the application, thereby distributing the application to a specified type of terminal according to a schedule. As a result, it becomes possible to centrally manage applications in the application management server.

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, or as a program for causing a computer to execute such steps. It can also be realized 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.

[Details of the embodiment of the present disclosure]
Specific examples of an application management device and an application management server according to an 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.

1. First embodiment With reference to FIG. 1, an application management system 50 according to a first embodiment of this disclosure is operated by an enterprise that manages systems to be developed (hereinafter, referred to as a "management enterprise"). 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 that is created by the management enterprise for application development and distributed to each developer is installed in the development terminal 60. The development terminal 60 develops an application using the SDK 62. The SDK 62 is provided with not only tools for application development, but also various mechanisms for managing applications developed using the SDK 62.

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 on-board device 78 installed in a vehicle 76 to which the application is to be distributed. In FIG. 1, the application management server 68 is shown as a so-called cloud.

Referring to FIG. 2, when an onboard device 78 of a vehicle 76 operates an application distributed from an application management server 68, the onboard 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. Note that in this embodiment, the logs output by each application being executed are used as the management information 110.

Note that the development terminal 60, application management server 68, and in-vehicle 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 exist 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 in-vehicle device 78 is located is not limited by the country or region in which the development terminal 60 is located or the country or region in which the application management server 68 is located.

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

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

The storage unit 164 stores an SDK 180, which is the same as the SDK 62 shown in FIG. 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 logs that the uploaded application outputs during operation.

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 an application to the application management server 68. The upload program 188 executes processing to upload a completed application to the application management server 68.

FIG. 4 shows details of various functions related to application management possessed by the management information generation program 182 shown in FIG. 3. Referring to FIG. 4, the management information generation program 182 includes an attribute information creation function 230 that creates attribute information representing the attributes of an application, a hash value calculation function 232 that calculates a hash value for verifying the identity of the final 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.

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

The management information generation program 182 uses these functions to generate management information for managing applications created using the SDK 180.

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

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.

FIG. 5 shows an example of management information. In this example, the creator of the application name is the developer. The method of obtaining or creating the name is that the SDK 180 obtains the name entered by the developer. The purpose of the information is to use it as an identifier for identifying the application.

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.

The 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," upload screen 270 is the screen used when an application developer uploads a completed application to application management server 68 shown in FIG. 1.

The upload screen 270 further includes a change specification list 302 that consists of four options that the developer can select for 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 improvements to the application or partial additions are made. The fourth check box is selected when bug fixes or minor modifications are made to the application.

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 abort the transmission and return the screen to the previous screen.

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.

Referring again to FIG. 5, the creator of the hash value is the SDK. The hash value is obtained by the SDK calculating the hash value of the application before it is uploaded. The hash value is used to determine whether the application has been tampered with or impersonated.

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

The creator of the information regarding the installation destination is the developer. The developer decides on the installation destination and enters it on a specific input screen prepared by the SDK, and the SDK acquires this information. The information regarding 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 unit or the identifier of an individual in-vehicle unit.

Information related to the installation time is created by the developer. The developer enters the installation time on a specific input screen prepared by the SDK. This information is specified by the developer in order to control the application installation time. Depending on the service, it may be necessary to change the specifications all at once at a specific timing. In such cases, the application installation time may be specified. Note that if the application distribution time and distribution location are entered, they are added as additional information to the application management information.

The log acquisition setting function (log acquisition setting function) will be described below. With reference 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 the application are output to standard output 362, and error logs are output to network 364. Note that standard output is usually written as stdout, and standard error output is written as stderr.

For each of the standard output 362 and the network 364, a logging driver 366 is specified individually. By specifying the logging driver 366, the format of the log, the transfer destination, etc. can be specified. It is possible to analyze the log at the transfer destination and transfer the result 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 setting is information for setting which logging driver is used, what format is used, when, and where the log output to the standard output 362 and the network 364 is transferred by the application. These settings are made by the log acquisition setting program 184 shown in FIG. 3. The program itself for acquiring the log 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 when the application is executed to a device other than the device on which the application is running is called the transfer mechanism specification function. Also, the system provided by Docker is called the Docker system.

FIG. 8 shows a sequence diagram of processing between 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, first the developer 80 uses the SDK 62 to perform application development 400. Next, the developer 80 launches the upload screen 270 shown in FIG. 9 (FIG. 6) in order 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.

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 the input by 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 attribute information of the application (e.g., the name of the application, the name of the creator, the 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 the version information of the application of the same name collected from the application management server 68. The schedule creation function 236 creates schedule information based on the 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 the input by the developer 80. The installation time setting function 242 sets the installation time based on the input by the developer 80. All of this management information becomes information accompanying the application.

Then, the 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 contents 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.

Referring to FIG. 8, next, authentication processing 406 of the application is executed. Authentication processing 406 is executed when the developer 80 clicks the send button 308 on the upload screen 270 shown in FIG. 9 to start authentication processing 440 of the application.

Specifically, when the developer 80 clicks the send button 308 shown in FIG. 9, the SDK 62 adds to the application the application management information, log information acquisition setting information, and authentication information consisting of the developer 80's identifier and password. 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 developer 80's identifier is entered in the ID field 304 in FIG. 9, and the developer 80's password 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.

The application management server 68, which has received this application together with the management information and authentication information, executes developer authentication 444. That is, the application management server 68 refers to a developer database managed by the application management server 68 (or another authentication server), compares the identifier and password of the developer 80 with the recorded information, and authenticates the developer. If the 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, the application has not yet been approved for distribution. Therefore, a value indicating that the application being processed (test1) is not yet available for distribution is assigned to the flag indicating whether the application being processed (test1) is available for distribution (indicated by "Not yet" in FIG. 10).

After this, the application approval process 408 is started in the application management server 68.

In the example shown in FIG. 9, developer 80 inputs his/her own identifier and password, as in upload screen 270. However, this disclosure is not limited to such an embodiment. For example, instead of having developer 80 input the identifier and password manually, developer 80 may be provided with a card-type employee ID card on which information equivalent to the identifier and password is recorded in advance. Such an example is shown in FIG. 10.

Referring to FIG. 10, upload screen 500 in 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 urging 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 the employee ID card. After information corresponding to developer 80's identifier and password has been read from the employee ID card, the processing by upload screen 500 is the same as the processing by upload screen 270.

Referring again to FIG. 8, in the application approval process 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 or email. 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 gives 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.

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 "Not yet." In other words, the distribution of application test1 has not yet been approved.

In this embodiment, when the application authentication process 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 responsible person 554. If the responsible person 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 Figure 11. As a result, it becomes possible to distribute the application test1 to each in-vehicle device.

In this embodiment, as described above, an application cannot be distributed without approval from three parties: two administrators and the final 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 more important the application, the more approvers may be allowed, or approval may be obtained from an approver with higher authority.

Referring again to FIG. 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 deliver 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.

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.

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

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 the designated distribution time from among the tasks registered in the task management table 616. The software distribution program 612 distributes the application specified by the task to the distribution destination specified by the task, and causes it to be installed. The software storage unit 614 stores software (applications) that are managed by the software management program 610 as the application management table 482.

Specifically, the software distribution program 612 performs the following process. Returning to FIG. 8, the application management server 68 executes the OTA task creation/addition process 412, which means that the application management server 68 is ready to instruct the in-vehicle device 78 corresponding to that task. When the in-vehicle device 78 starts up in this state, the in-vehicle device 78 performs the application acquisition process 618 as follows. That is, the in-vehicle device 78 executes the client process 414 to access 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 in-vehicle device 78. If there is a message, the in-vehicle device 78 reads out the task 624 (FIG. 12) specified by that message from the application management server 68. The task 624 is a task 416 (FIG. 8) that instructs the vehicle-mounted device 78 to download an application from a specified address in the software storage unit 614 of the application management server 68 and install it therein. When the vehicle-mounted device 78 receives this instruction, it accesses 626 (FIG. 12) the specified address in the software storage unit 614 and acquires 418 (FIG. 8) the application from the address. The vehicle-mounted device 78 further compares the hash value calculated for the acquired application with the hash value of the management information to confirm the validity of the application, and then installs 420 the application. The installation 420 here is an addition if there is no existing old version of the application, and an update if an old version exists. When the installation 420 of the application is completed, the vehicle-mounted device 78 transmits an installation completion notice 422 to the application management server 68. By performing such processing, a specified application can be distributed to each vehicle-mounted device 78 specified by the administrator 114 at the time specified by the distribution administrator 580.

Referring to FIG. 8, after the installation 420 of the application is completed, 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 424, 426 to the application management server 68 by the application management agent.

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

When application management table 482 has additional information such as additional information 630, the software management program 610 can automatically read the delivery time and installation destination of the application from the additional information 630, and automatically prepare a 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 delivered in the same manner as when the delivery manager 580 determines the installation destination and delivery time.

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

FIG. 15 is a hardware block diagram of the computer system shown in FIG. 14. Note that the application management server 68 shown in FIG. 1 can also be realized by a computer system essentially having a similar configuration to the development terminal 60. Here, we will only describe the configuration of the computer system that operates as the development terminal 60, and will not go into details of the configuration of the computer system that realizes the other devices.

Referring to FIG. 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 the 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 (e.g., a touch panel, voice input, or a general pointing device) can be used.

Referring to FIG. 15, computer 640 includes, in addition to DVD drive 672, a CPU 660, a GPU (Graphics Processing Unit) 662, and a bus 680 connected to CPU 660, GPU 662, and DVD drive 672. Computer 640 further includes ROM (Read-Only Memory) 666, RAM 668, and SSD 670. ROM 666 is connected to bus 680 and stores the boot-up program of computer 640, etc. RAM 668 is connected to bus 680 and stores instructions constituting a program, system programs, working data, etc. SSD 670 is a non-volatile memory connected to bus 680. The SSD 670 is for storing 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 a 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 part in the computer 640.

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

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

Computer programs for operating this computer system to implement the functions of the development terminal 60 and application management server 68 shown in FIG. 1 and each of their components are stored on a DVD 648 inserted into a DVD drive 672, and transferred from the DVD drive 672 to the SSD 670. Alternatively, these programs are stored in a USB memory 654, and the USB memory 654 is inserted into a USB port 676, and the programs are transferred to the SSD 670. Alternatively, the programs may be sent to the computer 640 via the network 656 and stored in the SSD 670.

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.

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 required to execute the instructions from the RAM 668, the SSD 670, or other devices according to the address specified by the instruction, and executes the process specified by the instruction. The CPU 660 stores the execution result data in the RAM 668, the SSD 670, a register in the CPU 660, or the like, at an address specified by the program. 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. Of the programs executed by the CPU 660, some tasks (mainly numerical calculations) are dispatched to the GPU 662 according to instructions contained in the program or according to the analysis results of the CPU 660 when executing the instructions.

The program for implementing the functions of each part according to the above-mentioned embodiment by computer 640 includes a plurality of instructions written and arranged to operate computer 640 to implement those functions. Some of the basic functions required to execute the instructions may be provided by the operating system (OS (Operating System)) running on computer 640, a third party program, various toolkit modules installed on computer 640, or the 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 only needs to include instructions that perform the operations of each of the above-mentioned devices and their components by statically linking the appropriate functions or modules at compile time or dynamically calling them at run time in a controlled manner to obtain the desired results. The method of operating computer 640 for this purpose is well known, so it will not be repeated here.

The GPU 662 is capable of parallel processing, and can execute a large amount of calculations associated with 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 parallel calculation elements discovered when the program is executed, are dispatched from the CPU 660 to the GPU 662 at any time and executed, and the results are returned to the CPU 660 directly or via a specified address in the RAM 668, and assigned to a specified variable in the program.

Each process (each function) in the above-mentioned embodiment is implemented by a processing circuit (circuitry) including one or more processors. The above-mentioned processing circuit may be configured by an integrated circuit combining one or more memories, various analog circuits, and various digital circuits in addition to the above-mentioned one or more processors. The above-mentioned one or more memories store programs (instructions) that cause the above-mentioned one or more processors to execute each of the above-mentioned processes. The above-mentioned one or more processors may execute each of the above-mentioned processes according to the above-mentioned programs read from the above-mentioned one or more memories, or may execute each of the above-mentioned processes according to a logic circuit designed in advance to execute each of the above-mentioned processes. The above-mentioned 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 above processes. For example, the processors mounted on each of the physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the above 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 in a recording medium such as a CD-ROM (Compact Disc Read-Only Memory), a DVD-ROM (Digital Versatile Disc Read-Only Memory), or a semiconductor memory, and installed in the memory from the recording medium.

The embodiments disclosed herein should be considered in all respects as illustrative and not restrictive. The scope of the present disclosure is indicated not by the detailed description of the disclosure, but by each claim in the claims, and is intended to include all modifications within the meaning and scope of the claims.

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 process 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 designation 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 unit 616 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 (9)

A display device;
A program execution unit;
a storage device storing a software development kit;
The program execution unit is
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 a 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; The function of generating the management information is
A function for creating attribute information of the application necessary for managing the application;
A function for obtaining a hash value of the application;
A function for 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 contents of the application input by the developer;
A function that allows the developer to specify the installation destination of the application;
a function for allowing the developer to specify the installation time of the application;
The application management device according to claim 1 , comprising at least one of: The application management device according to claim 1 or 2, 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. 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 apparatus 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. 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. The application management device according to any one of claims 1 to 5, wherein the authentication information acquisition function includes an authentication information acquisition function that acquires identification information of the developer from the developer. A storage device;
a program execution unit;
The program execution unit is
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 an approval process for receiving 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 for distributing the application approved by the approval process execution function to a distribution destination in accordance with conditions specified by the management information. the management information includes a schedule for distributing the application to a terminal and a terminal type 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 compatible with the terminal type according to the schedule. The schedule distribution function includes:
9. The application management server according to claim 8, further comprising a task preparation function for preparing a task for causing a terminal device to download said application from said application management server by specifying information for identifying said terminal type, said schedule, and said application.

Images