Skip to content

Sessions#

Sessions are a logical way to organise telemetry — like a file system.

Each session is labelled with user-defined metadata, including:

  • unique identity — GUID, database key, or query string
  • human-readable name and properties
  • timestamp and start/end time of the data
  • relationships to other sessions

ATLAS leverages this metadata to make sessions easy to browse, filter and sort.

ATLAS Session Browser

This system provides excellent scalability and can be tightly integrated with the existing data environment.

Modelling and Simulation#

ATLAS provides traceability and version control features to support Virtual Product Development through models and simulations.

Example

Models are used extensively in Formula One development. For example, an aerodynamics model predicts the air-flow over the car as it races around a track, depending on hundreds of variables — such as the ride height, wing angle and cooling setup.

On-track, air-pressure sensors and pitot tubes measure real downforce, and engineers use ATLAS to compare this telemetry with predicated parameters to find the correlation with the model. Both the telemetry and models may go through multiple versions to cleanup the data — for example, removing pressure traces from sensors that are contaminated with debris.

Simulated telemetry sessions are often used to add new parameters based on a physics model, signal processing pipeline, or machine learning algorithm. RTA can describe the relationship between the parent telemetry and child models — and ATLAS will leverage this to keep the data together.

Alternate Versions#

You can also offer users multiple versions of data.

For example, data collected during a test session might need some trimming and cleanup. ATLAS lets you switch out the original data for the clean version — yet keep the original available for easy reference.

Applying this concept to your environment#

Sessions typically represent a source of data — such as a set of equipment — and cover a bounded time period:

  • If you are using ATLAS to monitor hardware and embedded systems, this may naturally encompass a test session.

  • If you are integrating with a continuously-stored time series, you'll need to find a logical split.
    For example, if you were collecting vehicle telemetry, you might define a session for each vehicle and journey.

You can build this catalogue in real-time, or as a batch process.

Here are a few example scenarios:

If you have an existing collection of telemetry files:

  • Map each file to a session, using the file name and metadata

  • If several files belong together, you can treat them as one session — or use a parent-child relationship

If you are using a time-series database like InfluxDB or TimescaleDB:

  • Use the database tagging and query facilities

  • Split the sessions are points of interest, or by schedule

If you are acquiring data from a real-time UDP stream:

  • You can open a session even before data starts flowing

  • Metadata can be updated as you go — or later, to reflect test results

If you are processing each telemetry session through models:

  • You can associate the sessions in ATLAS so the data is loaded together

  • Use the type, quality, group and version metadata to organise the model output