Re-programming classic ECUs with Adaptive AUTOSAR

Introduction

Adaptive AUTOSAR offers a high degree of flexibility in the realization of more complex software architectures in the vehicle. This flexibility can be attributed to the ability to perform Over the air software updates (OTA) for maintenance purposes. With the upcoming EU7 regulations, OTA for Onboard Monitoring (OBM) could even become mandatory.

Adaptive AUTOSAR has had an in-vehicle solution for software cluster (SWC) updates since the 2019-11 release with Update and Configuration Management (UCM). However, there are many ECUs in a vehicle which continue to run Classic AUTOSAR or Non-AUTOSAR software.

With the new 2020-11 release, the UCM specification has been extended to include programming of Classic ECUs. A simple solution based on the ISO 22900-2 "Diagnostic-Protocol Data Unit API" standard, also referred to as D-PDU API, enables this functionality. The D-PDU API has been established in off-board testers since 2009.

How does the "Classic" software with the D-PDU API get into a vehicle via Adaptive AUTOSAR?

1. Flashing adapter with D-PDU API in OSI model

The starting point for the update process is an adaptive application known as an "OTA client". This vehicle- and OEM-specific application has the task of communicating with an OEM backend in the cloud or, alternatively, with a conventional workshop tester and transferring the flash data inside the vehicle. The communication channels and physics are not specified in more precise terms by the AUTOSAR architecture. However, cryptographically secured connections, via a radio network to the cloud or with a local workshop tester via Ethernet or CAN, are quite common.

The OTA client application is responsible for external communication and abstracts this communication completely. The UCM master is a separate adaptive service instance. It not only provides information about ECUs, the vehicle itself, the installed software and the status of update campaigns via an ARA::COM interface for the OTA client, but also for the “Vehicle Driver Application” and the “Vehicle State Manager”. The last two applications ensure that the driver agrees to an update and, on the other hand, that the vehicle cannot be put into operation during an update campaign.

The UCM master receives the flash data of an entire vehicle, known as vehicle packages. A Vehicle Package is typically provided by the OEM for an entire vehicle. In addition to a single Vehicle Package manifest, it contains a collection of software packages for the various (virtual) hardware platforms, ECUs and software clusters. Furthermore, it contains for each software package a unique way to assign it to 

2. Vehicle package overview (analog to figure 7.11 in UCM Spec 2020-11)

Once the Vehicle Package from diagram 2 has been correctly received by the UCM master, the vehicle update process can begin. An update includes one or more platforms, ECUs and (root) software clusters. UCM uses the data from the vehicle package to ensure that the updates are performed at the correct time. This process can also include multiple reboots of ECUs, the adaptive platform and the UCM itself.

For this purpose, various UCM clients, also known as UCM surrogates, are called in the necessary sequence.

3. Simplified sequence of the update of a software package of a Classic ECU

1) Data transfer of the software package During background programming, the software update can be paused when the ECU/server goes offline and can be resumed or cancelled later when it is up. This helps to reduce overall software update duration and data cost. The paused/cancelled software update will not have any impact on the ECU since the software update is done into inactive memory bank.

2) Editing of Software packages The UCM master decides on the basis of the Vehicle Package data when the processing of the software package may take place in the overall process. It triggers the update of the ECU by the flashing adapter with ProcessSw Package at the predefined time.

The flashing adapter then executes a normal UDS flash sequence as described in ISO 14229-1:2020 in chapters 17.2.1.1 "Pre-Programming step of phase #1" and 17.2.1.2 "Programming step of phase #1 – Download of application software and data". A flashing adapter knows and observes the sequence specific to the ECU and provides all necessary data, e.g. for a security access and the Erase Memory.

The Flashing Adapter builds on a D-PDU API "C”-interface, which is significantly reduced in scope, to transmit the UDS services. This UDS data is transmitted to the Classic ECU to be reprogrammed via a CAN or Ethernet bus. The Flashing Adapter provides only the actual binary data (PDU’s) for this purpose, independent of any protocol or implementation of the D-PDU API. It can therefore be used in different adaptive environments or different hardware platforms without modification.

After the TransferExit, this process concludes with the calculation and verification of the checksum of the newly programmed application of the Classic-ECU. The result of this flash process is finally reported back to the UCM master with CurrentStatus=READY for this step.

3) Activation

After the transfer of the data to the Classic-ECU, the UCM master again checks the dependencies of the software clusters involved and the safety requirements of the vehicle. If this is positive, the UCM master then calls the flashing adapter again with Activate. This trigger initiates the post-programming steps for finalization described in ISO 14229-1:2020 under points 17.2.1.3 and 17.2.1.4. In particular, this also restarts the connected Classic ECU by a "hard reset". The Flashing Adapter ends its activity with the feedback to the OTA client that the new software package is CurrentStatus=ACTIVATED.

After the reprogramming process the UCM master reports the successful transfer of the packet with the state TransferState=IDLE to the OTA client and the process is finished.

1. This architecture provides many advantages:

2. When providing a Vehicle Package, it makes no difference to the software packages whether it is an Adaptive or Classic ECU. An adaptive OTA client of an OEM in the vehicle can therefore update all networked ECUs of this vehicle.

3. The flashing adapter as UCM client has the AUTOSAR UCM interface upwards (layer 7) and the standardized D-PDU API interface downwards (layer 5). It therefore depends neither on the hardware nor on suppliers of an AUTOSAR stack. It is only dependent on the associated Classic ECU itself, whose flash run it performs as a diagnostic application. Suppliers of ECUs can therefore deliver a parameterized flashing adapter as an AUTOSAR application to their Classic ECUs to the OEM in order to reprogram their ECUs in the field.

4. The ISO 22900-2 (D-PDU API) has proven itself in many off-board diagnostic systems in the field since 2008. It forms the basis for connecting various vehicle communication interfaces (VCIs) to diagnostic systems. Thanks to asynchronism and queues, it offers higher performance than similar standards such as PassThru (SAE J2534) or RP 1210. All protocol parameters and their behavior are fully standardized in the D-PDU API, which is essential for the exchange of applications.

5. The relevant parts of the on-board flashing adapter are identical to an off-board diagnostic application in accordance with ISO 22900-3. This means that flash sequences can be easily developed and tested off-board before they are finally integrated into an adaptive AUTOSAR environment as a flashing adapter. This facilitates off-board test coverage of special cases, increases quality, and saves time and costs.

KPIT has already partnered with several large OEMs and implemented a Proof of Concept (PoC) solution comprising of an OTA client and a flashing adapter. Use of standardized protocol parameters proved highly advantageous in a dynamic development environment, enabling vehicle updates to run smoothly, unobtrusively, and being easy to test.

The associated AUTOSAR specification "Update and Configuration Management" has just been republished with Adaptive Release 11-2020. Due to the use of well-proven specifications, a high degree of maturity has already been achieved. Thereby, allowing for widespread & productive use of this concept in upcoming programs and projects.