Visualization and analysis of concurrent system activities

The TRACE tool helps us to understand complicated behavior over time for all kinds of systems through its domain-independent capabilities for visualizing and analyzing concurrent activities which are encoded in execution traces. Figure 1 shows a typical TRACE Gantt chart view.

The activities in the system, A-G, are represented by colored blocks with a start and end time.

Figure 1: Example visualization of system activities A-G (colored blocks) over time (x-axis).
Understanding system behavior over time

There are many reasons why a system’s behavior over time can become difficult to understand or, worse, confusing – even when the system is performing as designed. An example is a situation in which many concurrent activities share resources. Unforeseen interactions may arise due to the specific timing of the activities. Moreover, if the timing of the activities changes (e.g. due to an upgrade to the computational platform), the interactions may also change, which could result in significantly different behavior. However, insight into the hows and whys of a system’s behavior over time is of paramount importance for making effective (design) choices and trade-offs in all phases of the system lifecycle, from the design of a new system to the maintenance of an old legacy system. The TRACE tool can help with this.

Execution traces to capture behavior over time

The TRACE tool works with execution traces. These capture (a single) system behavior over time. In its barest form, these are time-stamped sequences of the start and end events of activities. TRACE extends this with (i) concepts from the Y-chart paradigm and (ii) a number of user-defined attributes (e.g. the name of the activity) in order to be tailored to a specific problem domain. This execution trace concept is very generic, which makes TRACE widely applicable in many ways:

  • All levels of abstraction: the TRACE format can capture all levels of abstraction, from low-level embedded activities to system-level activities.

  • Domain-independent: the TRACE format is domain-independent but nevertheless has the means to be tailored to a specific domain via the user-defined attributes.

  • Source-independent: TRACE input can be created from any source, e.g. from the log files of legacy systems or from a discrete-event simulation model.

Figure 2: The Y-chart method

The Y-chart paradigm decomposes a system into an application which is mapped to a platform, fostering reuse. Furthermore, it defines a feedback cycle to allow systematic design space exploration (Figure 2). The Y-chart concepts of application, mapping and platform are realized in TRACE through the decomposition of an activity (e.g. an image-processing computation) into one or more claims on resources for a certain amount of time (e.g. two cores of the CPU and 20 MB of RAM for 50 ms). These are the main elements of the execution traces that capture system behavior (star-1 in Figure 2). To provide feedback on the system under analysis (star-2 in Figure 2), TRACE provides extensive visualization and analysis of execution traces

Visualization and analysis of execution traces

The TRACE tool helps to gain insights into the system dynamics of all kinds of systems through the visualization and analysis of execution traces (Figure 3). TRACE visualizes concurrent activities in a Gantt chart-like view which provides coloring, grouping and filtering options. This visualization alone is already very powerful and can bring quick insights into the system dynamics. TRACE also provides several analysis methods, which sets it apart from the many other Gantt chart visualization tools.

  • Critical path analysis can be used to detect tasks and resources which are bottlenecks for performance.

  • Distance analysis can be used to compare execution traces in regard to structure, e.g. to check a model trace against an implementation trace.

  • MTL checking provides a means to formally specify and verify the properties of execution traces using Metric Temporal Logic. It is useful for expressing and checking performance properties, i.e. “the processing latency is 50 ms at most.”

  • The streaming performance DSL is a domain-specific language that captures often-used performance properties for stream-processing systems (e.g. image or video processing) and which eases the use of the MTL checker.

  • The resource usage feature can quickly give insights into the details of the resource usage.

The TRACE tool and the underlying concepts are relatively easy to learn, TRACE input is often relatively straightforward to obtain and the application of TRACE has great potential benefits.

Figure 3: A specialization of Figure 2 for TRACE
  1. M. Hendriks, M. Geilen, A.R.B. Behrouzian, T. Basten, H. Alizadeh, and D. Goswami. “Checking metric temporal logic with TRACE,” in 16th International Conference on Application of Concurrency to System Design (ACSD 2016), Torun, Poland, 2016. doi: 10.1109/ACSD.2016.13

  2. M. Hendriks, J. Verriet, T. Basten, B. Theelen, M. Brassé, and L. Somers, “Analyzing execution traces: critical-path analysis and distance analysis,” International Journal on Software Tools for Technology Transfer, 2016. doi:10.1007/s10009-016-0436-z

Learn more

If you want to learn more, then read the "Getting started" guide:

Getting started