Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

14 Chapter 2
exchange properly characterized black-box components. The required characterization
is described in corresponding agreements. This is detailed in the
following sections.
4. SOFTWARE INTEGRATION
In this section‚ we address the roles and functional issues proposed in Figure
2-1 for a safe software integration flow‚ in particular RTOS configuration‚
communication conventions and memory budgeting. The functional software
structure introduced in this section also helps to better understand performance
issues which are discussed in Section 5.
4.1. RTOS configuration
In an engine ECU‚ most tasks are either executed periodically‚ or run
synchronously with engine RPM. RTOS configuration (Figure 2-1) includes
setting the number of available priorities‚ timer periods for periodic tasks
etc. Configuration of basic RTOS properties is performed by the ECU provider.
In OSEK‚ which is an RTOS standard widely used in the automotive
industry [8]‚ the configuration can be performed in the ‘OSEK implementation
language’ (OIL [12]). Tools then build C or object files that capture the
RTOS configuration and insert calls to the individual functions in appropriate
places. With the proper tool chain‚ integration can also be performed by the
automotive OEM for rapid prototyping and IP protection.
In our experiments we used ERCOSEK [2]‚ an extension of OSEK. In
ERCOSEK code is structured into tasks which are further substructured into
processes. Each task is assigned a priority and scheduled by the RTOS.
Processes inside each task are executed sequentially. Tasks can either be
activated periodically with fixed periods using a timetable mechanism‚ or
dynamically using an alarm mechanism.
We configured ERCOSEK using the tool ESCAPE [3]. ESCAPE reads a
configuration file that is based on OIL and translates it into ANSI-C code.
The individual software components and RTOS functions called from this code
can be pre-compiled‚ black-box components.
In the automotive domain‚ user functions are often specified with a blockdiagram-based
tool‚ typically Simulink or Ascet/SD. C-code is then obtained
from the block diagram using the tool’s code generator or an external one. In
our case‚ user functions were specified in Ascet/SD and C-code was generated
using the built-in code generator.
4.2. Communication conventions and memory budgeting
Black-box components with standard software interfaces are needed to satisfy
IP protection. At the same time‚ validation‚ as well as modularity and flexi-