Customized requirement evaluations using the INCHRON metric framework

What’s a metric framework?

When analyzing a trace, we look at as many aspects of this trace as we can imagine – or as our tools allow us to. The more sophisticated a tool is, the more options are available for querying. However, being bound to a restricted set of options is not INCHRON’s view on timing and trace analysis. We know that specialized applications require specialized questions to be asked. And these questions can now be created in the form of customized metric templates using the INCHRON metric framework.

The metric framework provides several modular basic blocks that can be combined using a descriptive metric template language. Basically, we chain these basic blocks together to give shape to the value we need to observe. These metric templates are then simply imported into chronSUITE, ready to be used.

Metric templates are a modular way to define specific calculations (or measurements) that are applied to the entire trace in order to obtain information about it. The end-to-end latency histogram or mean slack time are prime examples of such templates. They are made up from individual metrics that, in turn, correspond to the processing steps of the overall calculation. These processing steps can stem from the following categories:

  • Measurement of timing data – net execution times, end-to-end latencies,
  • Statistical calculation – mean, median, histogram, etc.,
  • Post processing – filter, smoother, comparator, etc.

Since the individual metrics are chained together, we often refer to metric templates as metric chains.

As an introductory example, we show the creation of a response time measurement metric. The generic ProcessExecution metric produces a set of measurements for every process execution. In order to filter the response times, this metric has to be chained with a fitting selector. To achieve this with chronSUITE, the developer creates an empty metric template and adds a ProcessExecution metric as well as a ProcessExecutionSelector metric. These metrics are chained together via the source property of the selector. Now, when calculating this metric template for a trace’s process, a measurement is created for each process execution that is subsequently available as JSON data via the REST API. The actual inner workings of the metric framework are explained later in this series.

So, in a nutshell, using such templates allows measurements or requirements to be generated, parametrized, and applied to a trace to obtain evaluations. This process can even be automated using a REST API and INCHRON’s report.py script. In essence, metric templates enable you to create machine readable questions to the trace (your requirements) that are answered by chronVIEW (the evaluations).

The next parts of the metric framework series of posts will focus on the following aspects:

  • The report.py and the REST API
  • Building metrics using ecore (and the documentation)
  • Do-it-yourself metrics

So, stay posted for further information.

Any questions?

Feel free to contact us.

By submitting this contact form you give us your consent to store and process the data you have entered. Your personal data will be used only to answer your request. You can withdraw your consent at any time being effective for the future, by email to the contact given in the imprint. Please see our privacy policy (click here) for details.

USE CASES

Design

Analysis

Optimization

Test