Calibration Overview
Calibration is an important step in ECU development. Learn the basics on how to tune parameters in an ECU
If you have played around with control algorithms parameters, analog converters, sensors or anything of the sort, you are likely to have performed a calibration at some point, even if it's in a smaller scale than an automotive vehicle. There are multiple calibration options in the case of ECU's, even though it's not completely covered by the Autosar specification. The reason is because it depends, at least partly, on the underlying hardware.
In an ECU, a calibration is considered as a constant parameter, that will be tuned during development to suit the software needs. If you translate everything people say into C code, you might be wondering: if it's a constant, it's in the Flash memory, so how do I change it during development? Do I temporarily move it to the RAM? Do I change its position in memory and reflash my ECU? And the answer to this is a resounding yes. Depending on the calibration concept followed during development, some of the aforementioned suggestions might be true. In essence, the calibration concepts are divided into 2 categories: offline and online calibration:
-
Offline calibration - The process of changing the value of your variable in your binary file and reflashing. This is usually very tedious, depending on if you have a tool to abstract from the binary files (no one enjoys looking at hex files, trust me, unless they have a death wish). Usually, debuggers facilitate this process a little, by allowing you to patch the Flash at and performing a reset. I am not considering rebuilding the entire source code for a single parameter. Don't do that. It's ugly. Lastly, this process requires only access to the Flash. And that's about the only advantage.
-
Online calibration - Every ugly vehicle has its "cooler cousin". The online calibration, in this case, is the cooler cousin. It consists of changing parameters in runtime, directly on the ECU. Of course, this alternative is usually a bit more painful to implement, but the amount of time you win by the convenience it grants you is priceless. This approach may require some extra software running on the ECU, and a working A2L file (if you don't know what an A2L file is, it might be a good time to check our article The Basics of A2L Files (opens in a new tab)), a calibration protocol that works over the communication bus of your ECU (most likely XCP, which was made specifically for this purpose. To learn more about XCP, make sure to check our article XCP Module Overview (coming soon)) and (and this is where it worsens) a MC-Tool. Unfortunately, these can get expensive, but for an automotive OEM, or a tier 1, this is a small cost. Some companies that focus on MC-Tools are ETAS and Vector. You can develop your own, sure, but it's probably not worth it, as these provide graphics, export capabilities of your changed and monitored signals, so on. They are a huge boost in development.
Now, as for the calibrations concepts, these are your options:
-
Using the parameters in the Flash memory - complicated and tedious. And does not work if you don't have access to the Flash memory, which can be the case in enclosed ECU's.
-
Using the parameters in the RAM memory - by memory, we don't mean NvRAM. It's usually small, has a limited number of writes, so, it's destined for other things. Usually, when you place a variable in the RAM and give it an initial value, that initial value is stored in the Flash. Then, you can change the value in runtime, because you have access to RAM. The problem starts when you reach the end of the day and need to continue on the next day, or have a software reset for some reason. To circumvent this, you need to have an hex file that stores your RAM changes, to start fresh the next day. Also, a good practice is to create a memory section that groups all your RAM calibrations (for more information on how memory mapping is performed in Autosar, make sure to check the article Memory Mapping in Autosar, coming soon), so that your file consists of a contiguous area. Then, you just load the hex file and start fresh the next day. Another issue is, and for this one there's not much we can do, is that RAM is way smaller and more expensive than Flash, and needed for other things, so if you require a lot of calibration, this is likely not the way to go.
-
Flash Memory Overlay - Some microcontrollers have a beautiful hardware mechanism called memory overlay, which basically allows you to overlay Flash memory areas in the RAM. To beautify this even further, it can be done in runtime (in that case it's called dynamic memory overlay). It usually works as such: you identify a Flash area you want to overlay (within the limits of what your MCU allows), and configure it so that when a variable covered by the overlay area is used, the microcontroller will automatically point the address to either the RAM (also known as working page) or Flash (reference page), according to which is your active page, the one you are using at the moment. This can be controlled by the MC-Tools and XCP seamlessly, and since it's a hardware-based mechanism, there is little to no performance penalty. And, if you have a dynamic overlay, your working page can be smaller than your reference page, which is useful, as you are not likely to access the entire Flash range of calibrations at once. Now, the caveats: it can be hard to implement, it's likely that your Autosar stack provider will not support it and you might be stuck with having to create a CDD (to learn about complex device drivers, you can read the article Types of Software Components (opens in a new tab)), and this mechanism is hated by cache, memory protection units and debuggers. This, I call, a small price for a lifetime of happiness. In the end, just export the working page changes as an hex file (your MC-Tool will know the changes by performing a checksum over the entire calibration range over XCP), reflash your ECU and voilà!
-
Autosar RAM pointer calibration concept - This process is similar to the former, but instead of using hardware resources that you may not have, it emulates Flash memory through RAM pointers, by introducing a pointer table, and the calibrations are always referenced by pointers to this table. Then, it just changes according to RAM or Flash. This method's obvious disadvantage is software overhead. The advantage depends on your implementation, but, if you are using dynamic memory overlay, you may run out of RAM space or overlay blocks faster. There are single and double pointer methods, which are very lightly brushed in the Autosar specification, and both methods are handled by the RTE. They are triggered by the first change you try to make on a specific value. In the single pointer method, a copy is made of the value to the RAM and this address is kept on a pointer table. So, from that point on, you access this value through the pointer table. In the double pointer method, memory switching is made easier, by introducing a pointer table to Flash alongside the RAM pointer table, and creating a table pointer to switch between both. In the next side-by-side figure, you have an illustration from the Autosar standard comparing both these concepts. I suggest imagining another calibration reference table alongside the only one represented for the double pointer method, as this illustrates better the easiness from which you can switch calibration pages:
Single (left) and double pointer (right) calibration concepts in Autosar
- Flash pointer calibration concept - This concept works the same way as a single pointer calibration concept, with the table pointer being located in the Flash memory instead. This saves RAM space, with the caveat that you can only change the table through programming.
Alright, now that you got a hefty dosage of calibration concepts, their types and implementations, I hope you have learned a great deal on why calibration is used in the automotive industry and the advantages and disadvantages of each concept.
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn