The Real-Time Operating System (RTOS) schedules tasks to a resolution of 1 millisecond. Portions of the model which run at the same rate, are gathered together into tasks which are each assigned a unique priority and are fully pre-emptive. The priority of each task is assigned according to model rate (quickest rate is assigned the highest priority) with the angular rate (if enabled in the RTW options) assigned the highest priority. Tasks are also set up to handle CCP communications; polling for received CAN messages and software queuing for CAN transmit messages.

The blockset library provides access to information about the tasks at run time:

Some operations are performed in parallel on different devices to the processor that runs tasks. On some target ECU, information is available about how heavily loaded these devices are:

If enabled, OpenECU interprets the fastest rate task defined in the Simulink model as a task that is triggered at specific engine angles if the check-box 'Angular Rate Functionality' is checked. This check-box can be found in the menu option Simulation Parameters -> Real Time Workshop -> OpenECU code generation options. The following screen is an example:

The angular task is run at the engine angles defined in the engine configuration block, i.e. the TDC angle + Angular Task Calc Angle. The angular task is intended for calculating values such as the fuelling per cylinder. Note that if the engine is not rotating, the angular task will not execute. In simulation, the angular task will behave as the fastest rate task and all other task time-steps must be a multiple of the angular task time-step. A figure of 0.001s is suggested for the angular task time-step.

Each task shares the same stack space, an area of RAM dedicated to storing temporary information about the task and the functionality the task is performing. The amount of stack space is finite and must be specified when the model is built. The blockset library provides information about how much stack has be used since ECU power on or last reset:

Each ECU implements a watchdog, a mechanism to reset the ECU if the ECU software appears to be misbehaving. A simple watchdog scheme is implemented by the platform software but the application model can take control of the watchdog and implement a more complex scheme.

Each ECU implements an internal memory test during startup to check for hard memory faults. Hard memory faults are memory faults that have become permanent such as a shorted address line, or a memory cell that cannot change state. RAM is tested by performing a destructive walking one's test on the address and data lines and a memory recall test on the memory cells. ROM is tested by calculating a checksum of the contents. If a hard memory fault is detected, then the ECU will reset itself to force safety related outputs to a default state.

Some ECUs also implement a continuous internal memory test during runtime to check for soft memory faults. Soft memory faults are transient memory faults, such as might occur when a memory cell changes state due to stray electron releases. The error correction module hardware is capable of detecting and correcting errors that are limited to a single bit wrong in a 64-bit double word. If more than one bit is wrong in a 64-bit double word, then the hardware can detect the error, but it cannot be corrected. If an uncorrectable soft memory fault is detected, then the ECU will reset itself to force safety related outputs to a default state.

The blockset library provides Simulink blocks to report the status of the continuous internal memory soft error test as well as the address of the last detected correctable error.