ECU Objects

Overview

The ECU contains a number of “objects” that represent settings or measurements and have varying types (e.g. Tables or Maps).

An object in this sense just refers to any ’thing’ in the ECU that can be configured or viewed in GWv4.

Alternatively, an “ECU Object” could be viewed as a memory range in the ECU memory map, which may be a single bit, a byte, a word, or a larger array of items in memory.

Nomenclature

This table shows an approximate mapping between the terms used in GWv4 and the terms used in the XCP/A2L and Simulink® worlds.

Note that Options / Tables / Maps are allowed to be stored in non-calibration (i.e. volatile RAM) memory and the same goes for Simulink signals, which is why this mapping is only approximate.

Calibration vs Measurement Objects

Calibration objects are those that can be modified by the user and are stored permanently by the ECU in non-volatile memory. These values are usually read from the ECU once when connecting to it.

Measurement objects are generally read-only and used to display real-time feedback about the ECU’s operation. Measurements are read frequently from the ECU when visible in the user interface or if they are being used for PC logging. There are some exceptions to this for monitoring some specific ECU functions, such as whether or not there are changes to the calibration that have not been saved to non-volatile memory.

See Calibrations for more information on calibration files / non-volatile storage.

The ECU may be configured to log measurements in internal logging memory for later retrieval. This is useful for diagnosing problems that may not be visible in real-time and offers much more precise timing resolution than is possible when polling the ECU over a comms link.

Output Pins

Overview

For many functions, the physical output pins that the function is routed to is user-selectable via ‘Out’ options.

e.g. Out Oil Feed 1 or Out Oil Feed 1 PWM.

Inverting Outputs (Active Low)

Depending upon the electrical characteristics of the output pin, it may be necessary to invert the output signal.

To invert the sense of the output, use a negative value in the calibration for the output pin.

Output Pin Restrictions

Some output pins have different features and restrictions. For example, some pins may be used for PWM outputs, digital outputs, or timed.

Care should be taken to ensure that multiple functions are not assigned to the same output pin as this would cause conflicts and un-defined behaviour.

The correct type of pin should be selected for the function being controlled, for example Out Oil Feed 1 PWM must be a PWM-capable output pin.

Pin Numbering

Refer to the ECU manual for the pin numbering scheme used by the ECU. The internal ECU pin numbering scheme differs to the physical pin numbering on the ECU connector.

ECU Internal Routing

Overview

Some functions may be configured / linked within the ECU using internal data / channel routing.

For example, the EGT (Exhaust Gas Temperature) sensor may be connected to any input channel, be it a physical analog input or from a CAN message.

Other features are more fixed, such as AIT (Air Intake Temperature) which only allows selection from a list of analog inputs.

Routing Options

Route-able features will typically have a ‘Source’ option that allows the user to select the input channel. The raw value of the input channel is displayed by a corresponding ‘raw’ channel.

For example, the Oil Feed 1 feature has an Oil Feed 1 Source option that selects the input channel for varying the duty cycle. The MSB of the raw input value is displayed by the Oil Feed 1 raw channel.

Source options often have a ‘Bigend’ option that specifies the upper/lower byte of the input channel, if it is 16bit. This is usually set to OFF. In some cases (e.g. Little Endian data coming via CAN bus) the bytes of the raw input channel may require swapping.

If the Bigend option is OFF then the MSB of the raw input value is displayed by the raw channel.

Routing via a User Table or User Map

ECUs will often provide some general purpose ‘User’ tables or maps that can be used for non-linear scaling from abitrary input data.

For example, the User 1 Duty table can be used to convert a raw input value to a ’tunable’ output value.

These tables and maps can be utilized by using intermediate routing steps.

flowchart LR
    CRX["CAN1 RX1 W1"]-->U1S["User1 Source"]
    U1S-->U1RAW(["User1 raw"])
    U1RAW-->U1DT["User1 Duty Table"]
    U1DT-->U1D(["User1 Duty"])
    U1D-->OF1S["Oil Feed 1 Source"]

Routing from CAN

Specific CAN messages may be received using the CAN Rx setup (from menu action CAN Rx Setup…) or via CAN RX related options in the calibration.

When the CAN port and CAN RX IDs are configured, the ECU will decompose the CAN message into 4x 16bit channels, e.g. for Message 1 on CAN port 1, the channels are:

CAN1 RX1 W1
CAN1 RX1 W2
CAN1 RX1 W3
CAN1 RX1 W4

CAN Routing Example (EGT)

If, for example, an external temperature sensor module is used that sends a CAN message to the ECU containing a reading for EGT, then this message could be assigned to a CAN RX message ‘box’ e.g. CAN1 RX1. If the EGT temperature was given in the first 2 bytes then CAN1 RX1 W1 would hold the EGT temperature value, in unscaled form.

To link up CAN1 RX1 W1 to the EGT feature, the EGT Source would be set to CAN1 RX1 W1.

If the received EGT signal is in Little Endian (Intel) format, then the EGT Source Bigend would be set to ON to swap the bytes.

The resulting raw value is displayed by the EGT raw channel and converted to voltage 0…5V for the full-scale input value. This is generally fine for A2D sources but in the case of data received by CAN, this is unlikely to be the correct interpretation. The EGT Sensor table should arrange to convert from these pseudo-volts to valid temperature.

For this example, the temperature module reports temperatures as signed 16bit numbers with 0.1°C resolution per bit. This poses a problem since EGT raw is unsigned and there is no way to make the source be interpreted as a signed number directly.

The EGT Sensor table would need to convert the signed number to an unsigned one by having a discontinuity. Note that hexadecimal values can be directly entered into the table cells (including the axis for many tables, like EGT Sensor).

This table shows the conversion from the EGT raw channel to a temperature in °C. Notice the discontinuity at 0x8000, which is the point where the signed number changes from full-scale positive to full-scale negative:

However, the EGT Sensor only supports positive output values, from 0 to 1275°C, depending on the value of the Temp Scalar option. See User Scalars for more details on the purpose / effect of scaling factors like Temp Scalar.

If there are 8 cells in the EGT Sensor table, the following values could be used, assuming that the Temp Scalar option = 1 (or 0, in which case the scalar is ignored) and that GWv4 is configured to display temperatures in units of degrees:

CAN Routing for Simulink® based ECUs

For ECUs that use a Simulink® model, CAN signals may be decoded from a DBC file. The messages are defined ahead of time as part of the firmware build process, the channels in the DBC file become available for use in the Simulink model as Simulink signals.

User Scalars

Overview

User Scalars are a feature that allows the units of values to be changed. ‘Option User Scalars’ also reference calibration options for to apply configurable scaling factors.

Scaling options e.g. like Temp Scalar are stored by the ECU but are not directly involved in any of the ECU’s internal calculations.

Purpose

Internally the ECU works with (typically) raw integer or ‘fixed point’ integer values (variables), and less commonly with floating point values. ECUs running Simulink® models are more likely to be using floating point numbers internally.

As far as the ECU is concerned, any quantities (temperatures, pressures, speeds, oxygen concentrations etc) are just numbers and the units are generally not important. The relationship between values, however, is important and additionally that related quantities use the same internal scaling.

Since integers are discrete values, there is a limit to how precisely values can be represented. The ECU may be able to offer more precise control if important quantities are scaled to make the best possible use of the available range of variables that represent them.

Consider an ECU table that contains 8 bit values; there are only 256 possible states / steps in each cell of the table. If the maximum expected range of physical values can be mapped to fit onto this 0…255 range, then the ECU can make the most precise control decisions. The scaling options, therefore, are telling GWv4 how to convert from these internal raw values into physical units. In other words, the ECU is using a custom type of units and the scaling options are defining how those custom units correspond to a physical ‘real-world’ unit.

For example, Temp Scalar is used as a scaling factor for a number of temperature values in the GWv4 user interface. The scaling is purely for display purposes - but it can mean that higher resolution temperature values can be used internally by the ECU. The units may also be further converted from °C by GWv4 to a different unit (e.g. °F) for display purposes - see Unit configuration.

Internally, the ECU does not care what the units are, just that values represent ratios for control purposes. Changing the units displayed in GWv4 does not change the internal operation of the ECU whatsoever.

Many tables and maps are preconfigured with sensible scaling factors and may not offer the ability to change them, where the level of precision is not so critical or where the range of input values is predictable.

Configuration

If an item is scaled using an Option User Scalar, this will be apparent in the Descriptions View. There may be a ‘Scalar’ (multiplier) option and/or an ‘Offset’ (signed addition) option.

For example, the Engine Load channel is scaled using the Load Scalar and Load Offset options.

These same scaling factors are used anywhere that raw Engine Load channel values might be encountered so that GWv4 will display them all correctly and the ECU can compare them consistently.

For example, the Fuel map might use the Engine Load channel as the input to one of its axes, and the RPM channel as the other axis. The load axis breakpoints may be configured, giving a non-linear axis to give more precise control at some points in the engine’s operating range.

The ECU will compare raw Engine Load values to the (raw) breakpoints in the Fuel map, and interpolate between them to find the correct fueling value. The ECU does not care what the actual units are - it is only operating on the raw integer values that represent the engine load. The GWv4 software will use the Load Scalar and Load Offset options so that the load values can be presented on screen in meaningful units.