Migration facility for AUTOSAR Adaptive applications

Abstract

The invention relates to a migration device, a method and a computer program product for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application. The migration device (1) according to the invention for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application comprises a parser (2) that evaluates ARXML Classic software components, operating system scheduler and ARXML RTE selected for migration in order to identify runnables, timing events and init functions as well as ports, wherein the migration device (1) has a classification unit (3) that classifies identified signals as internal, external, newly external, incoming, outgoing or unused.

Description

[0001] The invention relates to a migration device, a method and a computer program product for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application.

[0002] With the transition to centralized vehicle architectures and high-performance computing platforms, the need to reuse existing Classic functionalities instead of completely reimplementing them for Adaptive systems is increasing. This applies particularly to proven software components, whose reimplementation would be complex and prone to errors. Previous approaches to migrating from Classic to Adaptive systems involve manual conversion. A significant disadvantage of this approach is the high cost involved.

[0003] The inventive migration device for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application comprises a parser that evaluates ARXML Classic software components, operating system scheduler and ARXML RTE selected for migration in order to identify runnables, timing events and init functions as well as ports, wherein the migration device has a classification unit that classifies identified signals as internal, external, newly external, incoming, outgoing or unused.

[0004] The migration framework takes into account that AUTOSAR Classic is designed for distributed ECUs with monolithic, near-real-time software, while AUTOSAR Adaptive supports flexible, service-oriented architectures on high-performance computing (HPC). With centralization on HPC platforms, the need to reuse existing Classic functionality increases, rather than reimplementing it natively on Adaptive. Virtual test environments such as simulation become significantly more important.

[0005] The migration facility according to the invention enables the reuse of classic logic, reduced re-implementation effort and simplified integration through encapsulation as a single process.

[0006] Within the scope of the present invention, various technical concepts from the field of automotive software architecture are used, which are explained below: AUTOSAR XML artifacts (ARXML) serve to provide a structured description of software-based components (SWCs), their interfaces (ports), executable functional units (runnables), and the associated network layer, the so-called Runtime Environment (RTE). Within the AUTOSAR Classic platform, the latter represents the central communication instance through which interactions between the individual software components are orchestrated.

[0007] A runnable is a time-defined functional unit within a software workstation (SWC) that can be scheduled and activated by the real-time software engineer (RTE). These granular execution units enable flexible and efficient control of the software behavior in the vehicle.

[0008] Adaptive systems utilize the Adaptive Interface. This is a service-oriented interface. It enables the dynamic provision and use of services within the AUTOSAR Adaptive Platform, thus supporting modern, service-based software architectures in the automotive environment.

[0009] In a preferred embodiment, the migration device comprises a code generator, wherein the code generator creates an AUTOSAR Adaptive application with at least one process and artifacts required by AUTOSAR Adaptive. This enables the automatic generation of all artifacts required for Adaptive, such as the manifest and ARXML. The code generator preferably creates a wrapper that incorporates and calls the Classic software components, ensures internal communication between the software components, and delimits the application as a single process or, if necessary, as multiple processes. It is particularly preferred that all additional artifacts required by Adaptive are also generated.

[0010] In another preferred embodiment, the code generator produces artifacts such that the original source code of the Classic software components, including required library functions available in source code, can be integrated into the AUTOSAR Adaptive application without modification. This enables the integration and compilation of the Classic code without changes. Preferably, the generated code meets quality standards such as MISRA C and / or the AUTOSAR C++ Guideline.

[0011] In another preferred embodiment, the migration facility includes a Runnable Scheduler, wherein the Runnable Scheduler maps the timing and trigger relationships extracted from the ARXML for processing the runnables. This enables the determination of the call sequence from the ARXMLs of the software components. Runnables of a task are executed in a fixed sequence in a separate process, with the timely and regular invocation of the process being handled by Adaptive and communicated in the manifest.

[0012] In another preferred embodiment, the migration facility includes an RTE emulation for performing communication between the migrated Classic software components. This enables the replication of classic AUTOSAR runtime environment communication, allowing Classic software components to run in a new environment such as an Adaptive application.

[0013] In another preferred embodiment, the migration device includes an interface translator, wherein the interface translator maps Classic ports to Adaptive interfaces at the application boundary. This enables the translation of Classic ports such as sender / receiver or client / server to Adaptive ports (services), whereby services are provided or used. The translation functionality utilizes technical means such as buffers as needed and provides error detection such as end-to-end checks and timeouts to the migrated Classic software components. This also applies to safety-relevant interfaces such as control points of program flow control mechanisms.

[0014] In another preferred embodiment, the migration device includes an interaction unit for type completion for external adaptive ports. This enables the addition of missing data types when they cannot be derived from the available information.

[0015] If the mapping of Classic Ports to Adaptive Ports requires additional information, the migration device preferably includes an interface through which the user can add such information.

[0016] In a further preferred embodiment, the migration device includes a report generator, which outputs the analysis results with regard to the migration to be performed. This enables the creation of a report on the analysis performed, in particular on runnables, identified periodic tasks, classified signals, and data types for external adaptive ports. The report can preferably be made available online or as HTML / Markdown.

[0017] In another preferred embodiment, the migration device includes a command-line control for automated execution of the migration.

[0018] The inventive method for converting a subset of AUTOSAR Classic application software into an AUTOSAR Adaptive application comprises the steps of: evaluating Classic Component ARXML, Operating System ARXML, and RTE ARXML using a parser to identify software components, runnables, ports, and signals; classifying identified signals using a classification unit, wherein a signal is classified as internal, external, newly external, incoming, outgoing, or unused; and generating an AUTOSAR Adaptive application using a code generator.

[0019] The computer program product according to the invention comprises program code which, when executed on a computing device, performs the method for converting a subset of AUTOSAR Classic application software into an AUTOSAR Adaptive application, wherein the program code may be stored on a non-volatile, machine-readable storage medium.

[0020] The invention is applicable in the automotive sector, in particular in the migration of control unit functions from AUTOSAR Classic to AUTOSAR Adaptive systems, in the centralization of functions on high-performance computers and in the use of virtual test environments.

[0021] A preferred embodiment is explained in more detail with reference to the following figures. These show Fig. 1 a structural diagram of an embodiment of a migration device according to the invention, and Fig. 2. the signal flows within an application software,

[0022] The Fig. 1 and Fig. Figure 2 illustrates, by way of example, the architecture of a migration facility 1 as well as the signal flows between the SWCs and the interfaces to the Adaptive system.

[0023] Migration facility 1 includes a parser 2 that evaluates the ARXML of the Classic software components, the Operating System Scheduler, and the RTE ARXML selected for migration to identify runnables, timing events, init functions, and ports. Migration facility 1 has a classification unit 3 that classifies identified signals as internal, external, newly external, incoming, outgoing, or unused.

[0024] The source system here is an AUTOSAR Classic real-time system, for example based on a Vector Microsar Stack 4.4.x and Aurix controllers. The target system here is a Linux-based AUTOSAR Adaptive system, for example on an ARM-based controller architecture, and is fully adaptive, meaning all commonly required AUTOSAR Adaptive modules are present.

[0025] Migration facility 1 further includes a code generator 4, which generates an AUTOSAR Adaptive application with at least one process and the artifacts required by AUTOSAR Adaptive, in particular the manifest, ARXML, and all other artifacts. Code generator 4 creates a wrapper that incorporates and calls the Classic software components (SWCs - Runnables), ensures communication between the SWCs (Runnables), and establishes communication between the SWCs and the Adaptive environment. The application is presented externally as an Adaptive application and is launched accordingly.

[0026] The application contains at least one process, but can also include multiple processes if needed, for example, during the migration of runnables across different tasks. All artifacts required by Adaptive in addition to the execution manager (such as the manifest) are generated separately.

[0027] Code Generator 4 creates artifacts in such a way that the original source code of the Classic software components, including any required library functions provided in source code, can be integrated into the AUTOSAR Adaptive application without modification. Artifacts can include code and headers. The code generator produces code that meets common quality standards and coding guidelines such as MISRA C and / or AUTOSAR C++ guidelines. The code of the SWCs (Runnables) is included and compiled for the Adaptive application without modification.

[0028] The adaptive application is based on C code from the SWCs (Runnables) and C++ code generated by Code Generator 4. Memmaps, if required by the Classic SWCs (Runnables), are also generated by Code Generator 4.

[0029] Migration setup 1 also includes a Runnable Scheduler 5, which maps the timing and trigger relationships extracted from the ARXML for processing the runnables. The call sequence can be determined from the ARXML of the SWCs (runnables). Runnables of a task are executed in a fixed sequence within a separate process. The timely and regular invocation of the process is handled by Adaptive and is communicated in the manifest. The generated code ensures communication between the processes.

[0030] Furthermore, the migration setup 1 includes an RTE emulation 6 for communication between the migrated Classic software components. The RTE emulation is a software layer that replicates the behavior of the classic AUTOSAR runtime environment (RTE) to the required extent, e.g., for communication between the Classic software components, when Classic software components (SWCs) are run in a new environment, such as an adaptive application. Communication between the SWCs (runnables) is achieved by emulating RTE communication, using code and macros for this purpose.

[0031] Another feature of the migration facility 1 is an interface translator 7, which maps classic ports at the application boundary to adaptive interfaces. This also applies to security-relevant interfaces such as control points of program flow control mechanisms. A translation to adaptive ports (services) is performed for each classic port (e.g., sender / receiver, client / server). Services are both provided (service provider) and used (service request). The translation functionality also utilizes buffers where necessary and includes error detection such as end-to-end checks and timeouts.

[0032] Migration facility 1 also features an interaction unit 8 for type completion for external adaptive ports, particularly when missing data types cannot be derived from available information. If the mapping of classic ports to adaptive ports requires additional information that cannot be automatically determined from the available artifacts, the user is involved via a user interface (graphical or command-line) so that the missing information can be added.

[0033] Furthermore, Migration Setup 1 includes a Report Generator 9, which outputs the analysis results regarding the migration to be performed, specifically runnables, identified periodic tasks, classified signals, and data types for external adaptive ports. A report on the completed analysis is generated. This report can be available online only (via the command line) or additionally as HTML or Markdown.

[0034] Migration facility 1 can have a command-line control for automated migration execution.

[0035] Alternatively, if there are multiple runnables in a single SWC, only a subset can be migrated, with the user selecting the runnables to be migrated. A selection mask can be provided in the user interface for this purpose.

[0036] Another variant concerns the design of the target system: While in the exemplary implementation a Linux-based AUTOSAR Adaptive System on an ARM-based controller architecture is used, alternatively another POSIX-compatible platform can be used, provided that all modules required for AUTOSAR Adaptive are available.

[0037] An exemplary embodiment of the method for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application comprises the following steps: (i) First, Classic Component ARXML, Operating System ARXML, and RTE ARXML are evaluated using parser 2. This identifies software components, runnables, ports, and signals. The selection of the SWCs to be migrated is made by providing the desired SWCs, i.e., code, headers, and ARXML, as input artifacts. (ii) The identified signals are classified using a classification unit 3. A signal is classified as internal, external, newly external, incoming, outgoing or unused. (iii) Subsequently, an AUTOSAR adaptive application is generated using a code generator 4.

[0038] Fig. Figure 2 shows the signal flows within an application migrated from an AUTOSAR Classic application to an AUTOSAR Adaptive application. Classic software components, which are migrated unchanged, are represented by dashed boxes. The communication between the Classic software components, previously handled by the RTE, is shown with solid arrows. This communication must be handled by the RTE emulation after migration.

[0039] Signals required by Classic software components and provided by the Adaptive environment are represented by dashed arrows. The solid squares on these dashed arrows represent code generated by Interface Translator 7 to ensure compatibility between Adaptive and Classic ports.

[0040] Signals provided by Classic software components that need to be transmitted to the Adaptive environment are represented by dash-dot arrows. The unfilled squares on these arrows represent code generated by Interface Translator 7 to ensure compatibility between Adaptive and Classic ports.

[0041] The scheduling of the Classic software components is ensured by the Runnable Scheduler 5, which calls the runnables within the Classic software components.

[0042] One embodiment of the computer program product comprises program code which, when executed on a computing device, performs the procedure described above. The program code may be stored on a non-volatile, machine-readable storage medium. The computer program product may be provided as an executable file (*.exe).

Claims

[1] Migration device (1) for converting AUTOSAR Classic application software into an AUTOSAR Adaptive application, comprising a parser (2) that evaluates ARXML Classic software components, operating system scheduler and ARXML RTE selected for migration to identify runnables, timing events and init functions and ports, wherein the migration device (1) includes a classification unit (3) that classifies identified signals as internal, external, newly external, incoming, outgoing or unused. [2] Migration device according to claim 1, comprising a code generator (4), wherein the code generator (4) generates an AUTOSAR Adaptive application with at least one process and artifacts required by AUTOSAR Adaptive. [3] Migration device according to claim 2, wherein the code generator (4) generates artifacts such that the original source code of the Classic Software components, including required library functions available in source code, can be integrated into the AUTOSAR Adaptive application without modification. [4] Migration facility according to one of the preceding claims, comprising a Runnable Scheduler (5), wherein the Runnable Scheduler (5) maps the timing and trigger relationships extracted from the ARXML for processing the Runnables. [5] Migration facility according to any of the preceding claims, comprising an RTE emulation (6) for performing communication between the migrated Classic Software components. [6] Migration device according to one of the preceding claims, comprising an interface translator (7), wherein the interface translator (7) maps Classic ports at the application boundary to Adaptive interfaces. [7] Migration device according to one of the preceding claims, comprising an interaction unit (8) for type completion for external adaptive ports. [8] Migration device according to any of the preceding claims, comprising a report generator (9) wherein the report generator (9) outputs the analysis result with regard to the migration to be carried out. [9] Method for converting a subset of AUTOSAR Classic application software into an AUTOSAR Adaptive application, comprising the steps of: (i) evaluating Classic Component ARXML, Operating System ARXML and RTE ARXML using a parser (2) to identify software components, runnables, ports and signals; (ii) classifying identified signals using a classification unit (3), classifying a signal as internal, external, newly external, incoming, outgoing or unused; and (iii) generating an AUTOSAR Adaptive application using a code generator (4). [10] Computer program product comprising program code which, when executed on a computing device, performs the method according to claim 9, wherein the program code may be stored on a non-volatile, machine-readable storage medium.

Images