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

The Simos ECU flash files contain a number of 'blocks', which are written to the memory on the ecu in different areas:

1. SBOOT (READ ONLY!)
2. CBOOT
3. Application Software 1
4. Application Software 2
5. Application Software 3
6. Calibration Block

The Application Software (ASW) is essentially the operating system for the ecu, this includes the code that's responsible for running the engine and making decisions. The Calibration block includes the tables that the ASW references. Calibration blocks and ASW are unique to each box code/calibration id

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.