How your telemetry should move: choosing the right ATLAS architecture
Data is only useful if it reaches you when you need it, in a format you can work with. Teams don’t just pick a telemetry tool. They choose a method for capturing, distributing and storing data that fits how they work.
ATLAS offers multiple options because engineering teams operate in very different environments: high-pressure live telemetry, controlled laboratories and cloud-based analytics. Summary at the end if you want to skip ahead.
The building blocks
Data stores in ATLAS are designed to offer flexibility and efficiency across different workflows. The SQL Race Database is a SQL Server-based session store, purpose-built for telemetry management. It handles sessions, metadata, markers, lap statistics, composite sessions, and supports efficient querying. ATLAS can interact with SQL Race directly via the SQL Race API, enabling seamless read and write operations.
Another key option is the portable session file format, which consolidates data and metadata into a single file. This approach is particularly suitable for transferring data within controlled environments or for archiving sessions cleanly. Both ATLAS and the SQL Race API support reading and writing SSN2 files, making the process straightforward and reliable.
ADS (ATLAS Data Server) remains the traditional backbone for live data ingestion and real-time distribution. It is engineered to support server-to-client data transfer, including daisy-chaining that enables smooth movement of data from trackside locations to the factory. ADS also integrates with Motion Applied control units and loggers, ensuring compatibility with standard motorsport telemetry hardware.
For added flexibility, ATLAS can obtain telemetry directly from RTA web services, which are adaptable to various backend systems such as SQL Server, PostgreSQL, InfluxDB, TimescaleDB, and object stores. RTA supports REST and WebSocket streaming, Redis buffering, and can be configured either as standalone services or bundled server components.
ATLAS’s Open Streaming Architecture delivers telemetry data using Protobuf encoding over a broker. This setup includes a Stream API and client samples in multiple programming languages, tailored for integration with third-party tools, cloud-based systems, and distributed consumers requiring real-time, engineering-calibrated telemetry streams.
Live motorsport telemetry
Race engineering requires predictability and speed. The traditional ATLAS Data Server exists because live telemetry in motorsport is demanding – you can’t afford to lose data packets or have slow updates, and you don’t want to rebuild your pipeline between sessions. ADS manages ingestion, distribution, server chaining, and integrates with the standard telemetry systems used in racing.
For storage, SQL Race is the natural choice. It’s a specialised database model for telemetry sessions, which means ATLAS can load, compare, and combine sessions quickly. The SQL Race API manages both SSN2 files and direct SQL Server queries.
RTA is ideal if you need to provide remote engineers, such as those based at the factory, with a straightforward, web-based live view of telemetry data, all without placing additional strain or complexity on your existing ADS setup. With its support for WebSocket streaming and Redis buffering, RTA ensures that late joiners can still receive a coherent and synchronised live playback experience. On the other hand, SECU is the preferred choice when you need to connect dashboards, machine learning pipelines or operational tools that require seamless access to telemetry alongside ATLAS. The Stream API delivers a standardised, engineering-calibrated data feed, making it immediately compatible with third-party tools and systems.
Cloud-first analytics
If your analysts work in notebooks and your models expect data streams, use the Open Streaming Architecture. The Stream API delivers telemetry as engineering-calibrated Protobuf messages over a broker, with public C# and Python examples. It’s built for cloud ingestion, ML feature extraction, real-time dashboards, fleet-wide analytics and distributed tooling.
RTA offers a practical bridge: bring in data from existing storage (SQL Server, PostgreSQL, time-series backends) without changing them and publish it into ATLAS. That makes moving to cloud setups considerably easier.
Most cloud-focused teams keep a main archive for ground truth:
• SQL Race for fast session review in ATLAS
• SSN2 for clean offline files and moving data between systems
Design loops and validation
Development engineering is about building confidence through repeated experiments, logging and comparison over time. Lower pressure than a race weekend, but the data informs long-term decisions.
SSN2 and SQL Race do the heavy lifting here. SSN2’s single-file format makes versioning and archiving straightforward. SQL Race gives fast, structured access to session details, so engineers can search, compare and analyse design changes efficiently, in ATLAS or via the API.
When real-time visibility matters, such as on hardware benches or long tests, ADS remains dependable, with a live view and a recording format ATLAS already understands.
Modern development leans on distributed tools and automation. RTA integrates data from multiple sources without major rework. The Open Streaming Architecture supports automation, regression testing and cloud analytics through a broker-based stream that any tool can access.
Summary
Architectural choice isn’t about which technology is “best”; it’s about how your telemetry needs to move.
• ADS: a stable, proven live backbone, the same one that’s kept pace with motorsport for over 35 years
• RTA: flexible ingestion and smooth migration from existing systems
• SECU: an open, modern streaming fabric for cloud and third-party tooling
• SQL Race and SSN2: Your reliable stores of truth
Know your workflow, and the right combination becomes obvious.