Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tracecompass-dev] Experiments vs Composite TraceTypes

Hi,

 

We use Trace Compass to deal with issues encountered within medical devices. Trace Compass is a platform for us. We’ve implemented a plugin that adds support for our trace types and analyses. So, we have a bunch of trace types and analyses for them. Some of our devices leave more than one trace behind. Each file/trace can be opened with Trace Compass using our plugin. All went pretty good until we faced a necessity to work with more than one file at a time.

 

We have three multifile use cases when files come from a single device:

  1. All the files are of the same trace type. They just represent a different period of time each. It occurs when devices rotate log-files, e.g. by size limits.
  2. The files are of different trace types. Their time borders are not necessarily strictly bound. Still, they contain events from the same device and we want to work with them as with one trace.
  3. A combination of first two.

 

All three cases could be resolved by using experiments if we used the events view only, but If we open a set of files as a generic experiment we have some issues with charts.

 

If we open one trace with a state in it we’ll see a Gantt chart with that state’s changes.

State: (---on---)(---off---)

 

If we use multifile case #1 with two files and open a Gantt chart with the state we’ll see something like this:

State:           (---off---)

State: (---on---)

 

The number of lines is determined by the number of traces with such data in the experiment. Of course, we want to see these states on one line. XYCharts are worse. Using existing TmfTreeCompositeDataProvider makes it possible to see data only when one trace of a given trace type exists in the experiment. So, it works only for multifile case #2.

 

I think we have two ways of resolving the issue:

  1. Create our own experiment types and add new analyses to them.
  2. Create a new entity “Composite Trace Type” which can be configured to read different events sources (already known trace types) but will remain a “trace”.

 

Of course, we want to reuse our existing code as much as possible, since, trace types and analyses are working already.

 

What are pros and cons of given two solutions? What am I missing? Are there other ways to cope with our issues? Please, share.

 

Thanks!

 

--

Best regards,

Ivan Grinenko

Software Engineer

Auriga

 

Back to the top