High Level Overview

The ecu in any car is designed to control how the engine operates. Car manufacturers want their engines to produce power, while still being fuel efficient, reliable, quiet, etc. The way they accomplish this is by defining "maps" which contain modifiable parameters that the ecu will use to make decisions on how the engine should be working. In the case of the Simos18, there are both measured values and modeled values in these maps.

Primary Strategy

The accelerator pedal tells the ecu how much torque the driver wants the engine to produce. That driver input is referenced against a table that defines the maximum torque available at any given RPM. That target torque value is referenced against other maps which define how much airflow, followed fuel and timing, the ecu should target to achieve the driver request torque value.

Simos Information

Physical info

If you open up the 18.1 ecu casing and look at the number written on the processor, this is what you’ll find:

SAK-TC1791S-384 F200EP
3MB total flash
200 MHz Processor

Physically it contains 3MB of flash in total, spread over two flash units inside the chip (PMU0 – 2MB and PMU1 - 1MB) Other variants of the chip can have different configurations, for example the 18.10 ECU uses a SAK-TC1791S-512 F240EP chip with 4MB (PMU0 – 2MB and PMU1 – 2MB). All of this is in the free Infineon datasheets. So when the tools read out the contents, sometimes they read past the end of the physical chip! In which case anything after the physical end is just lots of zeroes. The 18.1 only has 3MB physically there, if you get a read bigger than 3MB then is all going to be zeroes and you can ignore it anyway.

The flash blocks

There are six blocks: PMU0 (2MB)

1. SBOOT – supplier boot (0x0000 0000 -> 0x0001 BFFF)
2. CBOOT – customer boot (0x0001 C000 - > 0x0003 FFFF)
3. ASW1 – Application SW part #1 (0x0004 0000 -> 0x0013 FFFF)
4. ASW2 – Application SW part #2 (0x0014 0000 -> 0x001F FFFF)
5. PMU1 (1MB)
6. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF)
7. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF)

Each blocks purpose

SBOOT

SBOOT is not a field replaceable unit, so can’t be flashed over with OBD and you can ignore it for all intents and purposes since you can’t really modify it. The other five can be replaced via OBD and are subject to modifying.

CBOOT

CBOOT does all the flashing. Basically when you want to reflash via OBD, the ECU reboots into CBOOT and runs all the re-flashing procedures etc out of CBOOT. Once complete, it reboots again into ASW. ASW, the application software, is what controls the combustion process in your petrol engine. CBOOT has nothing to do with ASW. You can’t flash from ASW, you have to go into CBOOT for that. Both CBOOT and ASW have their own UDS comm stack, so when CBOOT is active it uses its own comm stack for CAN messages and similarly when ASW is active its using its own separate comm stack as well

Calibration changes

It's important to understand that while making changes to the ECU, there's literally hundreds of different tables that may be referenced at any given time or situation. The process of identifying what tables should be used to achieve a given result includes reverse engineering the process that the ECU uses to make certain decisions. One example of this fact is that while anybody familiar with tuning this ECU knows (by know) about the Max clutch torque tables, they probably don't realize that there's more than than one (15?). These tables are (likely) used in different situations/combustions modes (as outlined by ECUTek). Some tools will link all of them together as a single abstract table so that they all get updated simultaneously, since that's probably the goal of the tuner anyway. If we ever have access to open source tools (technically we do already) for modifying our calibrations, that linking is highly unlikely (and will complicate the tuning process greatly).

Definitions files

Definitions files are essentially a "map" to where the maps are located within the calibration data. They give software the ability to display maps in a human readable way. They're proprietary (in the case of factory definitions files), or they're built by hand using the factory definitions as a model.

Flashing the ECU

Technically, you could retune the ECU by just changing the maps that are contained in the calibration block - but each data block in the ECU must be validated before the ECU will use it. The calibration block must be checksummed by the ECU to make sure it hasn't been modified.

The first flashing procedure includes a process which overrides the restrictions that exist in the factory ASW and effectively unlocks the ECU. This allows the tuner to modify the calibration block and flash it to the ECU without triggering the ASW to reject anything. This process is proprietary. Tools like Flashtec, Alientech, bFlash etc have their own way of accomplishing this. Once the ECU is unlocked, any table located in the calibration block can be modified and the entire calibration block reflashed to the ECU as a single action. If you've ever been through the process of flashing calibration changes - they go much faster than the initial flashing process (as they're only changing 1/5th of the overall data).

Adding features

Since the ASW blocks can be flashed, it is possible to not only recalibrate tables in the calibration but also add or modify functions and features in the ASW. Unencrypted application bins include the machine code that's actually run by the ECU. The scope of what's possible is only limited to the amount of free space available (and whether or not you can decipher the instructions).

Logging

One example of an added feature is the Eurodyne High Speed Logger (HSL). There's a couple of different ways that the operation of the engine can be logged (usually for tuning/optimization purposes).

1. Reading data available on the CANbus
2. Reading memory address directly from the ECU
   1. Direct readByAddress queries
   2. Defining a dynamic identifier

CAN

The CANbus is essentially an open bus that can be sniffed. However, not every data point is available on the CANbus (since the ECU doesn't need to broadcast everything). RPM might be there (since the ECU communicates with the cluster), but the ecu won't broadcast knock statistics over the CAN network.

Reading memory by address

Tools that have the capability of connecting to the ECU can also request the values that the ECU has stored in various memory addresses. These values are stored in a non-human readable way with scaling factors that might only make sense to the ECU itself. The memory locations and their scaling factors are available in A2L/Definitions files, so assuming you have access to one of those for the ECU in question, you can find the location and it's scaling factor and you can query the ECU for it. The downside to this is that it has the potential to slow down dramatically as the number of logged parameters increases. If you have the capability of requesting 30 memory addresses per second, but you want to request the value of 10 different parameters, you'll only get 3 responses per second for each one. This has the potential to be inaccurate.

Dynamic Identifier

A dynamic identifier is (essentially) an identifier in the ECU that "maps" to multiple memory addresses. What that means is that you could, in theory, create a single dynamic identifier that maps to 5 different memory addresses. When you make a single request to the ECU for the value of that identifier, the ECU responds with the values in each of the memory addresses at once. This has the potentially to be many times faster than directly reading memory by address, though it's not available in every ECU (and when it is, it requires special [security level] access to be granted by the ECU).

Eurodyne actually installs a full dynamic identifier routine patched into the ECU for use with the high speed logger.

Map Switching

While this isn't specific to the Simos ECU (or even directly applicable), it outlines a procedure which should, in theory, achieve the same results if copied. Again, write the new feature, find free space (00's) in memory where it can be placed, and then find out what you want to do to trigger it.

https://www.tangentmotorsport.com/?p=47

ROM Consolidation

ROM Consolidation is something that tuners do, though Cobb seems to the be only one that advertises it. In short, this technique is used by tuners to broadly support a common family of ECUs by modifying them all with the same box code/application software. Since (mostly?) all of the Simos 18.1 ECUs use the same hardware code, the only difference from one to another is what software is installed on them. From the factory, there's a portion of the code which (like the checksums in the calibration block) verify the ASW that the ECU has installed. By bypassing this verification it allows the tuner to load the same code (and thus, the same calibration blocks) onto any ECU that shares/controls the same hardware. If they didn't do this, they would need definitions for each different calibration block since tables can be shifted slightly or exist in different places all together.