KR20220078453A - Dynamic software installation system and method thereof for AUTOSAR adaptive platform - Google Patents

Abstract

The software package update device based on the Autosa adaptive platform according to the present invention includes a transmission module for receiving and storing a software package through a service provider port, a package storage for storing the software package, and a package processing module for decompressing and installing the software package , a package activation module that requests a change to the package activation state from the state manager and receives a response from the state manager to verify whether the software package is in an active state.

Description

{Dynamic software installation system and method thereof for AUTOSAR adaptive platform}

The present invention relates to a system and apparatus for installing software on the Ottosa Adaptive Platform.

A car is made up of about 30,000 parts, and the proportion of electronic parts is increasing due to the electronicization of automobiles. ECU (Electronic Control Unit) is a component in charge of controlling electronic components and consists of vehicle semiconductors and software. Currently, about 50 to 130 ECUs are installed per vehicle, and the number is decreasing due to the advent of high-performance ECUs.

For software reuse (cost reduction) in the automotive field, the AUTOSAR (AUTomotive Open System ARchitecture) standard was established in 2005 by major automobile manufacturers and developers, and in 2017, the AUTOSAR Adaptive Platform (AP) The standard was newly established to reflect market needs, and AP has been applied to mass production since 2019. AP standard is a standard for software platform (OS, middleware) of ECU based on high-performance CPU.

For the three major topics of the automobile industry, network connection, autonomous driving, and electrification, system-on-chip development, ECU integration, and market demand for advanced functions are growing day by day, and the need for a new electrical and electronic architecture has been raised, and AP standards have emerged. This reflects the direction of change in the automobile industry.

Based on AP, the movement to operate a vehicle as a single platform such as a smartphone is rapidly progressing, and not only global major OEMs but also local OEMs are preparing to develop new ECUs using AP.

However, as the standard for AP is not yet complete, development must proceed in various aspects.

The main object of the present invention is to provide an apparatus and method for updating a software package under the Autossa Adaptive Platform.

An AP-based software package update apparatus according to a preferred embodiment of the present invention includes a transmission module for receiving and storing a software package through a service provider port (PPort or provider-port), and a package storage for the transmission module to store the software package , a package processing module that decompresses and installs the software package, and a state management (SM) that requests a change to the package active state and receives a response from the SM to verify whether the software package is active Contains package activation modules.

The transfer module can configure a backup partition by cloning the partition where the previous platform software packages are installed.

Alternatively, the transmission module checks whether the size information of the software package in the reception request for the new software package and the size information of the actually transmitted software package match, and if they do not match, the error code is updated and updated by the configuration manager (Update and Configuration Management; UCM) can respond to the service consumer through the service provider port.

After parsing the manifest file of the software package, the package processing module may install executable binaries, libraries, and other configuration files included in the software package to the target location specified in the manifest file.

If there is an error as a result of verifying the activation state of the software package, the package activation module may stop the activation of the software package and perform a rollback to the backup partition.

Alternatively, the package activation module may reboot the adaptive platform machine when a platform reboot request exists in the manifest file of the software package.

In accordance with another aspect of the present invention, there is provided a method for updating a software package based on adaptive auto company, a transmission step of receiving and storing a software package through a service provider port of UCM, a package processing step of decompressing and installing the software package, and a service consumer When there is an activation request for the software package from the , a package activation step of requesting the SM to change to the package activation state and receiving a response from the SM to verify whether the software package is in the active state may include.

The transmission step consists of a backup partition by cloning the partition where the previous platform software packages are installed as it is, waiting until there is a request to receive a new software package, receiving the software package if there is a request, a request Checks whether the size information of the software package in , and the size information of the actually transmitted software package match, responds to an error code if they do not match, and completes the package reception if they do. It may include the step of defining.

The package processing phase includes waiting for a processing request for the software package, decompressing the software package when there is a processing request for the software package, parsing the software package's manifest file, including in the software package This may include installing the executable binary, library, and other configuration files to the target location specified in the manifest file, and defining the status of UCM as the package processing completion status.

The package activation phase includes waiting for an active request for the software package, parsing the list of active states recorded in the software package's manifest file when there is an active request for the software package, and entering the parsed state into the SM. Requesting a list of changed or running processes, receiving a response to the request from the SM, verifying the activation status of the software package based on the response, and terminating the package activation phase if there is no error as a result of the verification may include

Alternatively, the package activation phase includes waiting for an activation request for the software package, parsing the list of activation states recorded in the software package's manifest file when there is an activation request for the software package, the state parsed to the SM requesting a change to or a list of running processes, receiving a response to the request from the SM, verifying the activation status of the software package based on the response, and stopping the activation of the software package if there is an error as a result of the verification and performing a rollback to the backup partition and terminating the package activation phase.

Alternatively, the package activation phase includes waiting for an activation request for the software package, parsing the list of activation states recorded in the software package's manifest file when there is an activation request for the software package, the state parsed to the SM requesting a change to or a list of running processes; receiving a response to the request from the SM; verifying the active state of the software package based on the response; and if the verification results in no errors, the software package's manifest file checking whether a platform reboot request exists, rebooting the adaptive platform machine and terminating the package activation phase if the platform reboot request exists, and terminating the package activation phase if the platform reboot request does not exist.

According to the present invention, software can be stably installed under the AP.

1 is a diagram illustrating a software configuration and a connection structure of Adaptive Auto Corporation for installing dynamic software in an AP according to an embodiment of the present invention;
2 is a block diagram showing a software installation apparatus according to an embodiment of the present invention;
3 is a flowchart illustrating a method for receiving a software package to a software installation device according to an embodiment of the present invention;
4 is a flowchart illustrating a method of installing a software package transmitted to a software installation device according to an embodiment of the present invention.
5 is a flowchart illustrating a method of activating and verifying an installed software package in a software installation device according to an embodiment of the present invention.
6 is a block diagram illustrating a software package installed by a software installation apparatus according to an embodiment of the present invention;
7 is a view showing setting element items of adaptive Autosa modeling that must be included to configure a software package.
8 is a view showing setting element items of adaptive Otosa modeling to be included in order to generate a package manifest.

Advantages and features of the present invention, and a method for achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in a variety of different forms, and only these embodiments allow the disclosure of the present invention to be complete, and those of ordinary skill in the art to which the present invention pertains. It is provided to fully inform the person of the scope of the invention, and the present invention is defined by the description of the claims. Meanwhile, the terminology used herein is for the purpose of describing the embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise in the phrase. As used herein, “comprises” or “comprising” refers to the presence or absence of one or more other components, steps, operations and/or elements other than the stated elements, steps, acts and/or elements. addition is not excluded.

The present invention can be implemented by a program readable by a computer or an equivalent digital device, or a recording medium in which the program is recorded. That is, the present invention can be performed when a computer or an equivalent digital device runs a program for installing AP-based software according to the present invention.

Hereinafter, the most preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings in order to describe in detail enough that a person of ordinary skill in the art can easily carry out the present invention. In addition, in demonstrating this invention, the same part is attached|subjected by the same code|symbol, and the repetition description is abbreviate|omitted.

1 is a diagram illustrating a software configuration of an AP for dynamic software update in the AP and a connection structure thereof.

As shown in FIG. 1, the basic software configuration of the AP for dynamic software update is three types: an update and setting manager (UCM, 110), a status manager (SM, 120), and an execution manager (EM, 130). of platform applications run in the form of POSIX processes.

The UCM 110 is a platform application that provides a package management service.

The SM 120 is a platform application that provides a state update (UpdateState) service, and provides an interface for changing the state globally applied to the Machine 100 according to a service request of another application and notifying the result of the change. Machine 100 means each ECU to which one POSIX OS is ported.

The EM 130 is a platform application for execution management that receives a predetermined request from the SM 120 and starts and terminates POSIX processes for other applications. EM 130 only communicates with SM 120 . In FIG. 1 , the OTA Client 140 is a type of application that operates in the form of a POSIX process, and is an application that uses a service called package management provided by the UCM 110 . New software packages coming from the vehicle manufacturer backend or vehicle diagnostics are initially stored through the OTA Client 140 . The OTA Client 140 must use the package management service provided by the UCM 110 to install, remove, or update the downloaded software package on the Machine 100 to process the installation, removal or update of the software package. (110) to request.

2 shows the structure of the UCM 110 according to an embodiment of the present invention. The UCM 110 according to the present invention includes a transmission module 210 for receiving and storing a software package, a package processing module 220 for decompressing and installing the software package, and a package to the SM when there is a request for activation of the software package. and a package activation module 230 for requesting a change to the active state and receiving a response from the SM to verify whether the software package is in the active state. The UCM 110 may receive and classify requests from other applications through a service provider port, and may individually provide functions provided by each module 210 , 220 , 230 . In addition, the UCM 110 uses the status update (UpdateState) service provided by the SM (120). In order to use the status update (UpdateState) service of the SM 120 , the UCM 110 requests a service through a service consumer port (RPort or require-port). The form of each module included in the UCM 110 is an instance and occupies one thread.

The package storage 240 refers to a file system in which the UCM 110 stores the transmitted software package.

3 is a flowchart for explaining the transmission step of the software package in which the transmission module 210 of FIG. 2 is the center.

When a service consumer (OTA Client, 140) downloads a software package from a backend or a diagnostic tester, it transmits a request for transmission to the UCM 110 . UCM 110 initiates the transmission of the software package shown in FIG. 3 through the service provider port. The transmission module 210 verifies whether the software package can be received, and if the software package can be received, whether there is a problem in transmission or storage of the transmitted software package.

When a TransferStart request is received through the service provider port of the UCM 110, the transfer module 210 determines whether another software package currently being transferred or processed exists. In this case, the size (total capacity) of the software package to be transferred must be specified in the TransferStart request.

If there is no other software package being transmitted, the transmission module 210 defines the software package as a receiveable state, and configures a backup partition by duplicating the partition in which the previous platform software packages are installed as it is (S310). When the backup partition configuration is completed, the transmission module 210 enters a standby state to receive the software package (S320).

The transfer module 210 determines whether there is a TransferData request received through the service provider port of the UCM 110 (S330), and if there is a TransferData request, receives a software package (S340). The number of blocks to transmit the software package depends on the service consumer's choice. The data of the software package is divided according to the number of blocks determined by the service consumer and transmitted through the service provider port of the UCM 110 . When the final TransferData request is completed, the service consumer sends a TransferExit request.

At this time, the transfer module 210 compares the size value of the software package specified in the TransferStart request with the size of the software package actually received through the TransferData request (S350). If there is a difference as a result of the comparison, an error code for the inconsistency of download information is transmitted to the service consumer to inform that the transmission is wrong (S355). If there is no problem, the package reception is completed (S360), and the state of the UCM 110 is defined as the package reception completion state (S370).

When the software package reception is completed, this file is stored in the package repository 240 . The saved file is retained until the installation process is complete.

As a modified embodiment related to the operation of the transmission module, when the transmission module 210 defines a software package in a receivable state, the service consumer requests transmission and receives a part of the package for pre-verification purposes and performs a test in the virtual area. If there is an error in communication, decompression, execution, etc., the step of notifying the user of the package management service by sending an error code to the consumer of the package management service without entering the backup partition configuration (S310) is the configuration of the backup partition (S310) It can be added as a previous step.

4 is a flowchart for explaining the processing steps of the software package in which the package processing module 220 of FIG. 2 is the center.

When the software package transmission process of FIG. 3 is completed and the state of the UCM 110 is defined as the package reception completion state by the transmission module 210, the operation of the package processing module 220 starts as shown in FIG. do. The package processing module 220 waits for several allowable requests (S410). When the ProcessSwPackage request of the service consumer is received through the service provider port of the UCM 110 (S420), the package processing module 220 proceeds to install the software package in the package storage 240 (S430 to S480).

The transmitted software package is a type of compressed file, and the compression format may vary depending on the vehicle manufacturer or platform manufacturer. The first step of software installation is decompression of the software package (S430). The package processing module 220 can process the software package only when there is a package manifest file. Each software package has one package manifest file in common, and this package manifest file has information such as the installation location and version of the executable binary of the vehicle application to be installed, the library, and the configuration files for the operation of the executable binary. That is, the installation target location is explicitly set, and the package processing module 220 parses the package manifest file to process this part (S440). When parsing is completed, executable binaries, libraries, and configuration files included in the software package are installed in the target location in the order specified in the package manifest file (S450 to S470). When this process is completed, the package processing module 220 defines the state of the UCM 110 as a package processing completion state (S480).

5 is a flowchart illustrating an activation step of a software package in which the package activation module 230 of FIG. 2 is the center.

As shown in FIG. 5 , the package activation module 230 completes the software package processing process in the UCM 110 of FIG. If it is defined as the state (S480), it starts. Thereafter, the package activation module 230 waits until there is an Activate request (S510). When the service consumer requests activation of the installed software package through the Activate request (S520), the package activation module 230 receives the Activate request through the service provider port of the UCM 110 to activate and verify the installed software. It proceeds (S530 to S590).

First, the active state list in the package manifest file is parsed (S530). The package activation module 230 transmits a request for the SetState method of the UpdateState service provided by the SM 120 of FIG. 1 (hereinafter abbreviated as 'SetState request') to the SM 120 in the order in the parsed state list. A state (state) change is requested (S540). That is, the package activation module 230 operates as a consumer of the UpdateState service. Thereafter, the package activation module 230 waits until a response is received from the SM 120 .

When a SetState request is received through the service provider port of the SM 120 , the SM 120 transmits the received state change request to the EM 130 . The EM 130 changes the state received from the SM 120 . After the SM 120 requests the EM 130 to change the state, the SM 120 waits until a response is received from the EM 130 .

After the EM 130 processes the state change, the SM 120 responds with the result. The SM 120 transmits a response to the SetState request to the UCM 110 . The package activation module 230 of the UCM 110 receives a response to the SetState request. The response to the SetState request of the SM 120 relates to whether the state change is normally processed (S550).

If the state change is normally processed, a SetState request is transmitted to the SM 120 in relation to the state activation for the next order of the parsed state list to request the state change.

If an error is received, the package activation module 230 regards the state recorded in the package manifest as a state not registered in the adaptive platform machine (Machine, 100), and stops activation of the corresponding software package. Then, the error code is transmitted to the consumer of the package management service to inform that it is an incorrect software package (S552). Thereafter, the package activation module 230 performs a rollback to the backup partition in which the state before receiving the software package is stored (S554). Thereafter, all other states of the UCM 110 are initialized, and the package activation phase is terminated.

When all state changes existing in the active state list recorded in the package manifest file are completed without errors, the package activation module 230 requests the GetVerificationList method of the UpdateState service provided by the SM 120 (hereinafter referred to as 'GetVerificationList request'). abbreviation) to the SM 120 (S560). Thereafter, the package activation module 230 waits until a response is received from the SM 120 .

When a GetVerificationList request is received through the service provider port of the SM 120 , the SM 120 transmits a request to the EM 130 to obtain a list of processes currently operating in the adaptive platform machine. The SM 120 waits until a response comes from the EM 130 after the process list request to the EM 130 .

The EM 130 receives a request from the SM 120 and transmits a list of processes operating under the control of the EM 130 to the SM 120 . The SM 120 transmits a response to the GetVerificationList request to the UCM 110 . The package activation module 230 receives the response through the service provider port of the UCM 110 .

The package activation module 230 obtains a list of POSIX processes currently operating under the control of the EM 130 of the adaptive platform through a response to the GetVerificationList request. When it is confirmed that the executable file included in the software package operates, it is determined that the package activation state has been verified (S570). Thereafter, the package activation module 230 checks whether a platform reboot request exists through parsing of the package manifest ( S580 ). If there is a request for platform reboot, the package activation module 230 reboots the adaptive platform machine (S590). If the platform reboot is not requested, the package activation module 230 performs a package activation check completion operation (S582).

When the package activation check is completed without error, the package activation module 230 transmits that the installation is complete to the consumer of the package management service of the UCM 110, initializes all other states of the UCM 110, and then performs the package activation step. quit

If any of the executable files included in the software package do not operate, the package activation module 230 transmits an error code to the consumer of the package management service to inform that it is an incorrect software package (S552), and stores the state before receiving the software package. A rollback is performed to the backup partition (S554). Thereafter, the package activation module 230 initializes all other states of the UCM 110 , and then ends the package activation phase.

6 is a structural diagram for explaining a basic form of a software package that can be processed by the UCM 110 .

The basic format of a software package is a single compressed file made of several files into one file, and a signature (OEM SIGNATURE) indicating the vehicle manufacturer's special encryption and marking is included in this file. When the UCM 110 decompresses the software package, it decompresses only the software package with the correct signature. A package manifest is a file that describes a list of various files included in a software package, an installation target location, and information about a state to be checked for activation. When the UCM 110 installs the software package, the installation proceeds according to the information specified in this file. "EXECUTABLE" means a set of executable files of vehicle applications included in a software package. "LIBRARY" refers to a set of library files that must be installed on the platform in order to operate the executable files of vehicle applications included in the software package. "ETC" means a setting file, a text file, etc. that the executable files of vehicle applications included in the software package must read separately.

7 is a diagram illustrating AP modeling setting element items to be included to configure the software package presented in the present invention. It contains the information, executables, general files, and manifests that should make up the software package.

8 is a diagram illustrating AP modeling setting element items to be included in order to generate a package manifest presented in the present invention. It includes software package configuration information required to generate a package manifest, signature, package capacity, version, state information required for software package activation, and machine reboot information.

Claims (12)

In the software package update device based on the Autossa adaptive platform,
a transport module that receives and stores software packages through the service provider port; and
a package repository in which the transmission module stores the software package;
a package processing module for decompressing and installing the software package; and
When there is a request for activation of the software package, a package activation module for requesting a change to the package activation state from the state manager and receiving a response from the state manager to verify whether the software package is in an active state
Software package update device based on Autossa Adaptive Platform including The method of claim 1, wherein the transmission module is
A backup partition can be configured by cloning the partition where previous platform software packages are installed.
Software package updater based on Autosa Adaptive Platform. The method of claim 1, wherein the transmission module is
Check whether the size information of the software package in the reception request for a new software package and the size information of the actually transmitted software package match, and if they do not match, an error code can be returned to the service consumer through the service provider port there is,
Software package updater based on Autosa Adaptive Platform. According to claim 1, wherein the package processing module
After parsing the manifest file of the software package
Executable binaries, libraries, and other configuration files included in the software package can be installed in the target location specified in the manifest file,
Software package updater based on Autosa Adaptive Platform. The method of claim 1, wherein the package activation module is
If there is an error as a result of verification of the activation state of the software package, the activation of the software package can be stopped and a rollback to the backup partition can be performed,
Software package update device based on Autosa Adaptive Platform. The method of claim 1, wherein the package activation module
capable of rebooting the adaptive platform machine when there is a platform reboot request in the manifest file of the software package;
Software package updater based on Autosa Adaptive Platform. In the software package update method based on the Autosa adaptive platform,
a transport step that receives and stores the software package through the service provider port;
A package processing step of decompressing and installing the software package;
When there is an activation request for the software package, a package activation step of requesting a change to the package activation state from the state manager and receiving a response from the state manager to verify whether the software package is in an active state
A software package update method based on the Autosa Adaptive Platform, including The method of claim 7, wherein the transmitting step
The steps of configuring a backup partition by cloning the partition where the previous platform software packages are installed, and
waiting for a request to receive a new software package; and
receiving the software package upon request;
Checking whether the size information of the software package in the request matches the size information of the actually transmitted software package, responding to an error code if they do not match, and completing package reception if they do not match;
Including the step of defining the status of the update and setting manager as a package reception completion status,
How to update software packages based on the Autosa Adaptive Platform. The method of claim 7, wherein the package processing step
Waiting until there is a processing request for the software package;
decompressing the software package when there is a processing request for the software package;
parsing the manifest file of the software package;
Installing executable binaries, libraries, and other configuration files included in the software package to the target location specified in the manifest file;
Including the step of defining the status of the update and settings manager as a package processing completion status,
How to update software packages based on the Autosa Adaptive Platform. The method of claim 7, wherein the package activation step
waiting for an active request for the software package;
parsing a list of activation states recorded in a manifest file of the software package when there is an activation request for the software package;
Requesting a change to the parsed state or a list of running processes from the state manager;
receiving a response to the request from the state manager;
verifying the activation state of the software package based on the response;
Comprising the step of terminating the package activation step when there is no error as a result of the verification,
How to update software packages based on the Autosa Adaptive Platform.
The method of claim 7, wherein the package activation step
waiting for an active request for the software package;
parsing a list of activation states recorded in a manifest file of the software package when there is an activation request for the software package;
Requesting a change to the parsed state or a list of running processes from the state manager;
receiving a response to the request from the state manager;
verifying the activation state of the software package based on the response;
If there is an error as a result of the verification, stopping the activation of the software package, performing a rollback to a backup partition, and terminating the package activation step,
How to update software packages based on the Autosa Adaptive Platform.
The method of claim 7, wherein the package activation step
waiting for an active request for the software package;
parsing a list of activation states recorded in a manifest file of the software package when there is an activation request for the software package;
Requesting a change to the parsed state or a list of running processes from the state manager;
receiving a response to the request from the state manager;
verifying the activation state of the software package based on the response;
If there is no error as a result of the verification, it is checked whether a platform reboot request exists in the manifest file of the software package. If the platform reboot request exists, the adaptive platform machine is rebooted and the package activation step is finished, and the platform reboot request is present. If not, including the step of terminating the package activation step,
How to update software packages based on the Autosa Adaptive Platform.

Images