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.
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 its UCM client.
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.
The UCM master then starts programming a software package (SWP) by calling RequestPackage on the OTA client, as shown in diagram 3
3) Simplified sequence of the update of a software package of a Classic ECU
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.
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.
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 22.214.171.124 “Pre-Programming step of phase #1” and 126.96.36.199 “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 188.8.131.52 and 184.108.40.206. 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.
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.
Autosar and Diagnostics Subject Matter Expert, KPIT Technologies
Active member of the Adaptive Autosar Consortium
Connect with us
KPIT Technologies is a global partner to the automotive and Mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 11000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and Mobility and is present where the ecosystem is transforming.
Rajiv Gandhi Infotech Park,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
KPIT and KPIT logo are registered trademarks | © Copyright KPIT for 2018-2023
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Leave a Reply