Adaptive Autosar offers a high degree of flexibility in the realization of more complex software architectures in the vehicle.
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?
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 its UCM client.
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.
The UCM master then starts programming a software package (SWP) by calling RequestPackage on the OTA client, as shown in Figure 3.
The UCM master performs the following three phases for all UCM clients. In doing so, it must consider all the dependencies between the various software packages and ECUs.
1) Data transfer of the software package
The process starts with the transfer of the actual flash data from the OTA client via the UCM master to the UCM clients. This data is transferred to the various UCM clients in a sequence analogous to UDS: TransferStart, several TransferData followed by a final TransferExit. This sequence may also be done in parallel for different UCM clients for speed optimization. The Flashing Adapter will therefore first buffer the data. Once the driver’s consent has been obtained and other preconditions – such as a vehicle standstill – have been ensured, the actual reprogramming of the Classic ECU can now take place using the assigned flashing adapter.
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 188.8.131.52 “Pre-Programming step of phase #1” and 184.108.40.206 “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.
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 220.127.116.11 and 18.104.22.168. 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.
This architecture provides many advantages:
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.
About the Author
Dipl. Inf. Bernhard Wagner, MBA, is an Autosar and Diagnostics Subject Matter Expert at KPIT Technologies. He is an active member of the Adaptive Autosar Consortium.