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

Abstract

A software package update device based on the Autosar Adaptive platform according to the present invention includes a transport 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. , includes a package activation module that verifies whether or not the software package is active by requesting a change to the active state of the package from the state manager and receiving a response from the state manager.

Description

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

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

A car is composed of about 30,000 parts, and the ratio of electric parts is increasing due to the electrification of automobiles. ECU (Electronic Control Unit) is a part responsible for controlling electric components and consists of automotive semiconductors and software. Currently, about 50 to 130 ECUs are installed per vehicle, and the number is decreasing with the advent of high-performance ECUs.

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

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

A movement to operate a vehicle as a single platform such as a smartphone based on AP is progressing rapidly, and local OEMs as well as major global OEMs are preparing to develop new ECUs to which AP is applied.

However, the standard for AP is not yet complete, so 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 AutoSar 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 storing the software package in the transmission module. , a package processing module that uncompresses and installs the software package, and a state manager (SM) that requests a change to the active state of the package and receives a response from the SM to verify whether the software package is active. Contains the package active module.

The transport module may configure a backup partition by duplicating a partition in which 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. UCM) can respond to the service demander 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 setting files included in the software package in a target location specified in the manifest file.

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

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

According to another aspect of the present invention, a software package update method based on Adaptive Autosar includes 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. A package activation step of requesting a change to the package active state from the SM, receiving a response from the SM, and verifying whether the software package is active when there is a request for activation of the software package from the SM may be included.

The transfer step consists of duplicating the partition where the previous platform software packages are installed as it is to form a backup partition, waiting until there is a request for receiving a new software package, receiving the software package if requested, and requesting a new software package. Checking whether the size information of the software package in the software package and the size information of the actually transmitted software package match, responding with an error code if they do not match, and completing receiving the package if they match. It may include a definition step.

The package processing steps are: waiting until there is a processing request for the software package, unzipping the software package when there is a processing request for the software package, parsing the manifest file of the software package, and including it in the software package. It may include installing executable binaries, libraries, and other setting files in the target location specified in the manifest file, and defining the state of UCM as a package processing completion state.

The package activation step is the step of waiting until there is an activation request for the software package, parsing the active state list recorded in the manifest file of the software package when there is an activation request for the software package, and Requesting a list of changed or running processes, receiving a response to the request from the SM, verifying the active state of the software package based on the response, and terminating the package activation step if there is no error as a result of the verification. can include

Alternatively, the package activation step may include waiting until there is an activation request for the software package, parsing the active state list recorded in the software package's manifest file if there is an activation request for the software package, and parsing the active state list 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 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 step may include waiting until there is an activation request for the software package, parsing the active state list recorded in the software package's manifest file if there is an activation request for the software package, and parsing the active state list to the SM. A step of requesting a change to or a list of running processes, a step of receiving a response to the request from the SM, a step of verifying the active state of the software package based on the response, and a manifest file of the software package if there is no error as a result of the verification checking whether there is a platform rebooting request, rebooting the adaptive platform machine and terminating the package activating step if the platform rebooting request exists, and terminating the package activating step if the platform rebooting request does not exist.

According to the present invention, it is possible to stably install software under an AP.

1 is a diagram showing a software configuration of Adaptive Auto for dynamic software installation in an AP and a connection structure thereof according to an embodiment of the present invention.
2 is a configuration diagram showing a software installation device according to an embodiment of the present invention.
3 is a flowchart illustrating a method of 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 apparatus 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 configuration diagram illustrating a software package installed by a software installation device according to an embodiment of the present invention.
7 is a diagram showing setting elements of adaptive autosar modeling that should be included to configure a software package.
8 is a diagram showing the setting element items of Adaptive Autosar Modeling that must be included to create a package manifest.

Advantages and features of the present invention, and methods for achieving them, will become clear 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, only the present embodiments make the disclosure of the present invention complete, and those skilled in the art in the art to which the present invention belongs It is provided to fully inform the person of the scope of the invention, and the invention is defined by the description of the claims. Meanwhile, terms used in this specification are for describing embodiments and are not intended to limit the present invention. In this specification, singular forms also include plural forms unless specifically stated otherwise in a phrase. As used herein, "comprises" or "comprising" means the presence or absence of one or more other elements, steps, operations and/or elements other than the recited elements, steps, operations and/or elements; do not rule out additions.

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

Hereinafter, the most preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings in order to explain the present invention in detail to the extent that those skilled in the art can easily practice the present invention. In addition, in explaining the present invention, the same reference numerals are assigned to the same parts, and the repeated explanation thereof is omitted.

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

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

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

The SM 120 is a platform application that provides an UpdateState service, and provides an interface for changing the globally applied state to the Machine 100 according to service requests from other applications 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 communicates only with SM 120 . In FIG. 1, the OTA Client 140 is a kind 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. A new software package coming from the vehicle manufacturer's backend or vehicle diagnostics is 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. Request at (110).

Figure 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 that receives and stores a software package, a package processing module 220 that uncompresses and installs a software package, and a package to the SM when a software package activation request is received. and a package activation module 230 that requests a change to an active state, receives a response from the SM, and verifies whether the software package is active. The UCM 110 may receive and classify requests from other applications through a service provider port, and individually provide functions provided by the modules 210, 220, and 230. Also, the UCM 110 uses an UpdateState service provided by the SM 120. To use the UpdateState service of the SM 120, the UCM 110 requests the service through a service demander port (RPort or require-port). The type 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 transmitted software packages.

FIG. 3 is a flowchart for explaining a transmission step of a software package, which is performed centered on the transmission module 210 of FIG. 2 .

When a service consumer (OTA Client, 140) downloads a software package from a backend or diagnostic tester, it transmits a request for transmission to the UCM (110). UCM 110 initiates the delivery 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, there is no problem in transmission and whether there is no problem in storing the software package.

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

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

The transmission module 210 determines whether there is a TransferData request received through the service provider port of the UCM 110 (S330), and receives a software package if there is a TransferData request (S340). How many blocks the software package is divided into and transmitted 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 transmits 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 non-coincidence of download information is transmitted to the service consumer to notify that transmission is incorrect (S355). If there is no problem, the package reception is completed (S360), and the state of the UCM 110 is defined as a package reception completion state (S370).

Upon completion of receiving the software package, this file is stored in the package storage 240. Saved files are maintained until the installation process is complete.

As a modified embodiment related to the operation of the transmission module, when the transmission module 210 defines the software package as receivable, it requests transmission to the service consumer, receives a part of the package for preliminary verification purposes, and conducts a test in the virtual area. When there is an error in communication, decompression, execution, etc., the step of notifying the consumer of the package management service of an error code that it is an invalid software package without entering the backup partition configuration (S310) is the configuration of the backup partition (S310) It can be added as an immediately preceding step.

FIG. 4 is a flowchart for explaining a process of processing a software package performed with the package processing module 220 of FIG. 2 as the center.

When the software package transmission process of FIG. 3 is completed and the state of the UCM 110 is defined as a 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 compressed 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 only when the software package has a package manifest file. Each software package has a single package manifest file in common, and this package manifest file has information such as an installation location and version of an executable binary of a vehicle application to be installed, a library, and setting files for 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 setting 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).

FIG. 5 is a flowchart for explaining an activation step of a software package performed with the package activation module 230 of FIG. 2 as the center.

As shown in FIG. 5, the package activation module 230 determines that the software package processing process in the UCM 110 of FIG. It starts when defined as the state (S480). Then, 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 to the SM 120 a request for the SetState method of the UpdateState service provided by the SM 120 of FIG. 1 in the order in the parsed state list (hereinafter referred to as 'SetState request') State (state) change is requested (S540). That is, the package activation module 230 operates as a consumer of the UpdateState service. Then, the package activation module 230 waits until a response comes from the SM 120.

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

After EM 130 processes the state change, it returns the result to SM 120. 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 is whether or not the state change is normally processed (S550).

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

If an error is received, the package activation module 230 considers the state recorded in the package manifest as an unregistered state in the adaptive platform machine (Machine, 100), and stops activating the corresponding software package. In addition, an error code is transmitted to the consumer of the package management service to notify that it is an invalid software package (S552). Then, the package activating module 230 rolls back to the backup partition in which the state before receiving the software package is stored (S554). After that, all other states of the UCM 110 are initialized, and the package activation phase ends.

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

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

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

The package activation module 230 finds 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 active state of the package 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 rebooting, the package activation module 230 reboots the adaptive platform machine (S590). If platform rebooting is not requested, the package activation module 230 performs a package activation check completion operation (S582).

When the package activation check is completed without errors, the package activation module 230 transmits that 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 even one executable file included in the software package does not operate, the package activating module 230 transmits an error code to the consumer of the package management service and informs them that it is an invalid software package (S552), and stores the state prior to receiving the software package. Rolling back to the backup partition is performed (S554). Thereafter, the package activation module 230 initializes all other states of the UCM 110 and then ends the package activation step.

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

The basic format of the software package is a single compressed file made up of several files, and the vehicle manufacturer's special encryption and signature (OEM SIGNATURE) is included in this file. When the UCM 110 performs decompression of software packages, only software packages with valid signatures are decompressed. A package manifest is a file that describes information about the list of various files included in a software package, the installation target location, and the active state to be checked. When the UCM 110 installs the software package, it proceeds with the installation according to the information specified in this file. "EXECUTABLE" means a set of executable files of vehicle applications included in a software package. "LIBRARY" means a set of library files that must be installed on the platform to operate the executable files of vehicle applications included in the software package. "ETC" means a setting file, text file, etc. that executable files of vehicle applications included in a software package must separately read.

7 is a diagram representing AP modeling setting element items to be included to configure a software package proposed in the present invention. It contains information about what constitutes a software package, what executables, plain files, and manifests are.

8 is a diagram representing AP modeling configuration element items to be included to generate a package manifest proposed in the present invention. It includes software package configuration information required to create 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 Autosar Adaptive platform,
A transport module that receives and stores software packages through the service provider port; and
a package store where the delivery module stores the software package; and
A package processing module for decompressing and installing the software package; and
A package activation module requesting a state manager to change to a package active state when there is a request for activating the software package, receiving a response from the state manager, and verifying whether the software package is active.
A software package update device based on the Autosar Adaptive platform, including a. The method of claim 1, wherein the transmission module
A backup partition can be configured by cloning the partition where the previous platform software packages are installed.
A software package update device based on the Autosar Adaptive platform. The method of claim 1, wherein the transmission module
Checking 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 not matching, sending an error code to the service consumer through the service provider port ,
A software package update device based on the Autosar Adaptive platform. The method of claim 1, wherein the package processing module
After parsing the manifest file of the software package
The executable binaries, libraries, and other setting files included in the software package can be installed in the target location specified in the manifest file.
A software package update device based on the Autosar Adaptive platform. The method of claim 1, wherein the package activation module
If there is an error as a result of verifying the activation state of the software package, the activation of the software package can be stopped and a rollback can be performed to a backup partition.
A software package update device based on the Autosar Adaptive platform. The method of claim 1, wherein the package activation module
capable of rebooting the adaptive platform machine when a platform reboot request is present in the manifest file of the software package;
A software package update device based on the Autosar Adaptive platform. In the software package update method based on the Autosar Adaptive platform,
The transport step of receiving and storing the software package through the service provider port; and
A package processing step of decompressing and installing the software package; and
A package activation step of requesting a change to a package active state from a state manager when there is a request for activating the software package, receiving a response from the state manager, and verifying whether the software package is active.
A method for updating a software package based on the Autosar Adaptive platform, including a. The method of claim 7, wherein the transmitting step
The steps of constructing a backup partition by cloning the partition where the previous platform software packages are installed;
waiting for a request to receive a new software package; and
receiving the software package if the request is made; and
checking whether the size information of the software package in the request matches the size information of the software package actually transmitted, responding with an error code if they do not match, and completing receiving the package if they match;
Defining the status of the update and setting manager as a package reception complete status,
A software package update method based on the Autosar Adaptive platform. The method of claim 7, wherein the package processing step
waiting until there is a processing request for the software package; and
decompressing the software package when there is a request for processing the software package; and
parsing a manifest file of the software package;
Installing executable binaries, libraries, and other setting files included in the software package to a target location specified in the manifest file; and
Including the step of defining the state of the update and setting manager as a package processing completion state,
A software package update method based on the Autosar Adaptive platform. The method of claim 7, wherein the package activation step
waiting until there is an activation request for the software package; and
Parsing an active state list recorded in a manifest file of the software package when there is an activation request for the software package;
The step of requesting a change to the parsed state or a list of running processes from the state manager; and
receiving a response to the request from the state manager; and
verifying the active 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,
A software package update method based on the Autosar Adaptive platform.
The method of claim 7, wherein the package activation step
waiting until there is an activation request for the software package; and
Parsing an active state list recorded in a manifest file of the software package when there is an activation request for the software package;
The step of requesting a change to the parsed state or a list of running processes from the state manager; and
receiving a response to the request from the state manager; and
verifying the active state of the software package based on the response;
If there is an error as a result of the verification, stopping the software package activation, performing a rollback to a backup partition, and terminating the package activation step.
A software package update method based on the Autosar Adaptive platform.
The method of claim 7, wherein the package activation step
waiting until there is an activation request for the software package; and
Parsing an active state list recorded in a manifest file of the software package when there is an activation request for the software package;
The step of requesting a change to the parsed state or a list of running processes from the state manager; and
receiving a response to the request from the state manager; and
verifying the active 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, and if the platform reboot request exists, the adaptive platform machine is rebooted and the package activation step is terminated, and the platform reboot request exists. If not, terminating the package activation step,
A software package update method based on the Autosar Adaptive platform.

Images