TRACE Example

The ODSE system

The ODSE example system has been created to provide a benchmark which contains key ingredients that are often found in software-intensive embedded data-processing systems. The ODSE system can be decomposed, following the Y-chart paradigm, into an application, a platform, and a mapping of the application to the platform. Below we describe each of these parts.

The ODSE system processes a stream of data objects, which have a low, medium or high complexity. The frequency of occurrence in the stream is as follows: 20% is of low complexity, 50% is of medium complexity, and 30% is of high complexity. There is always data available for processing by the ODSE system. The application consists of seven tasks, A - G, which process the data objects in the following order: A -> B -> C -> D -> E -> G. Note that task F only executes for data objects of high complexity, and happens between B and G: B -> F -> G. This means that task F for some data object can execute in parallel with tasks C, D and E for the same data object. The application disallows auto-concurrency of tasks, but it allows pipelining. This means that when task A has finished the processing of data object i, it is enabled to start with data object i+1. This implies that on any moment multiple data objects can be in the system.

The platform consists of two memory modules, M₁ and M₂, a CPU, a GPU, and an FPGA with four functions.

The mapping of tasks to platform resources is as follows: tasks A and G run on the CPU, task B runs on the GPU, task C runs on FPGA1, task D runs on FPGA2, task E runs on FPGA3 and task F runs on FPGA4. Internal processing of tasks and data communication between tasks is done using two memory resources: M1 and M2. The computational load and memory requirements of the tasks depend on the complexity of the object that is being processed.

Example traces of the ODSE system

We have a discrete-event simulation model of the ODSE system that creates execution traces readable by the TRACE tool. The traces contain claims and the application dependencies as explained above. Each claim has an "id" attribute with an integer value that is the identifier of the data that is being processed by the activity that resulted in the claim. Furthermore, each claim also has an attribute for the activity name (A - G). We have created a number of traces that are available here. These traces are used further on to explain the various analysis and visualization techniques.