The majority of the autospace leverages Unified Diagnostic Services, also known as UDS, as the primary mode for installing new software into an ECU for production vehicles. Much of the industry refers to this as reflashing. Perhaps this term has carried over from decades past, when the actual microcontrollers had to be removed from the circuit and “flashed” by a tool, commonly referred to as a ”chip burner”.
For those not privy to UDS, here’s a few important tidbits that will be helpful to this post, and a couple bonus points, too. Unified Diagnostics Services:
· is an ISO standard (ISO 14229) protocol ;
· defines Application Layer(7) and Session Layer(5) services in accordance to the OSI model;
· outlines how an ECU (ISO refers to an ECU as a “server”) and a diagnostic tester (and ISO refers to the tester as the “client”) manage communications;
· refers to each communication type as a service;
· supports many networks, including Controller Area Networking, or CAN;
· was first released in 2006.
It is important to understand and remember that UDS offers guidelines to flash reprogramming ECUs, not one hard and fast process. Automotive OEMs have different flavors of the protocol; it is not a one-size-fits-all. You can think of UDS being a language like English, German or Spanish- different regions have different vernaculars, and so is true for Automotive OEMs.
UDS outlines and specifies many diagnostic parameters, but we’re going to take a look at the process of installing software as per UDS protocol.
UDS protocol defines a set of processes it deems necessary when performing ECU programming. It is broken down into two phases, and each phase contains a list of services. Some of these services are mandatory, and others are optional; each OEM has their own implementation. Let’s take a look at these two phases, and break down the services in each. The services below follow a template I have created:
SessionName(whether it is ISO or OEM defined)-OPTIONAL or MANDATORY implementation- input from yours, truly.
1. DiagnosticSessionControl(ISO)-MANDATORY- Informs the ECU that the test tool will be beginning a diagnostic interchange, and the ECU will return important data about the session, such as timing limits. You can imagine this similar to how you might say to someone, “Hello! Do you have a moment to speak?” and they may return, “Sure! I have a moment.”
2. CommunicationControl(OEM)-MANDATORY- Switches off any normal operation CAN message broadcasts. This reduces the bus load and may allow for a faster programming routine.
3. RoutineControl(OEM)-OPTIONAL-Switches off any safety interjections that may be inadvertently triggered during the programming phase, or perhaps to perform a necessary OEM specific task.
4. ControlDTCSetting(ISO)-MANDATORY- Switches off raising any Diagnostic Trouble Codes (DTCs) during the programming process.
5. ReadDataByIdentifier(OEM)-OPTIONAL-May be implemented by the OEM to check which software level is currently installed in the ECU before beginning the programming process.
6. LinkControl(ISO)-OPTIONAL- Changes the bitrate of the CAN channel. So, if the ECU’s CAN network communicates at a 125k bitrate, we could possibly increase the bitrate to 1m (so long as the ECU’s clock oscillator is up to the task, but that’s another conversation entirely). I have not seen the utilization of this service very often, which strikes me as odd, however I am sure it is not without reason. With the continuing trend decreasing costs in microcontroller memory, and increasing complexity and sum of code size altogether, I would imagine implementing the CAN FD protocol would be very likely.
1. DiagnosticSessionControl(ISO)-MANDATORY-As stated above, basically just a handshake of sorts
2. SecurityAccess(ISO)-OPTIONAL-Protects the ECU firmware from any malicious attempts of alteration. The security method is of the seed-key type: (1) the tester requests a seed, (2) the tester is required to perform an algorithmic task upon the seed to generate the key, while the ECU is also privately performing this task, (3) the tester returns the key to the ECU, and if it matches with the key the ECU has calculated, access is granted. ISO states this is mandatory for any theft, emission, or safety related devices, however it is widely implemented due to the nature of possible security breaches. Also, the size of seeds and their keys are optional; some ECUs may incorporate a 24-bit seed/key, whereas others may be as long as 64-bits. This section of UDS may change soon, though, with numerous security breaches, some even headlining the media. One possibility could be what Jihas Kahn, of Tata Elxsi Ltd., has proposed with Advanced Encryption Standard (ADESTA) for Diagnostics over CAN. Time will tell.
3. WriteDataByIdentifier(OEM)-OPTIONAL-Writes a “fingerprint” on the ECU. This is a log of the machine’s identity (again OEM specific), and current time and date, amongst other possibilities of data.
4. RequestDownload(OEM)-MANDATORY- I know what you’ve been thinking, when do we actually start pushing our binary into the ECU? Well, here’s where we finally begin. This service asks the ECU if the binary can be shuffled in at a specific start address of the ECU’s memory map and the size of the binary. There is a byte in this service reserved for the OEMs to allow for binary compression and encryption, as well. The ECU will return the maximum number of bytes it can digest at a time, or block length. That variable will be used for the service below.
5. TransferData(OEM)-MANDATORY- Transfers the binary file in by two bytes short of the maximum block length (the first two bytes are reserved for the UDS service) using CAN Transport Protocol, or ISO 15765. This service is reused until all the bytes of the binary have been pushed in.
6. RequestTransferExit(OEM)-MANDATORY- tells the ECU that we have completed uploading the binary.
7. RoutineControl(OEM)-OPTIONAL- Depending on the OEM, this service is used to check that the binary was received correctly by performing some sort of check, like a Cyclic Redundancy Check (CRC) or similar.
8. ECUReset(ISO)-MANDATORY-Reboots the ECU to execute the new firmware that was just installed
As you can see, there can be many variants, and in fact, there are. There is no one-size-fits-all. What would be the fun in that, anyway?!
I hope you enjoyed this not-so-brief explanation. If you would like more information on ECU reflashing and automotive electronic technology, be sure to check out more posts on our blog. UDS reflashing solutions? Yeah, we have that covered, too. Do-it-yourself or turn-key solutions. Come check out what we have to offer!