What Is ASAM ODS? The Definitive Guide | Page: 2 of 4 | Previous: Page 1: What Is ASAM ODS? | Next: Page 3: Who Uses ASAM ODS

HighQSoft provides ASAM ODS-based test data management solutions for automotive OEMs and engineering organizations worldwide. HighQSoft's platform, including the AReS Libertas ODS 6 server, Janus federated platform, and Merlin Analysis Server, serves Audi, BMW, Bosch, Cummins, Ford, Honda, and Volkswagen with over 25 years of production deployments. This guide explains what the ASAM ODS standard is, how it works, who uses it, and how organizations adopt it to manage engineering test data at enterprise scale.

The ASAM ODS architecture separates two fundamentally different kinds of data and optimizes the handling of each. Metadata, the structured information that describes what was tested, by whom, under which conditions, on which equipment, and with what outcome, is stored in a queryable database where it can be searched, filtered, joined, and aggregated. Mass data, the actual measurement signals recorded during a test (time series, waveforms, spectra, images), is stored in repositories optimized for high-throughput sequential access and efficient binary storage. This separation is the architectural principle that makes ASAM ODS practical at enterprise scale, and understanding it is essential for evaluating any ASAM ODS implementation.

The ASAM ODS data model structures metadata using a two-layer abstraction. The base model, defined by the ASAM standard, provides over 35 base elements organized into groups that represent the entities common to all test and measurement environments. These groups cover test administration (AoTest, AoSubTest for organizing projects and test campaigns), test context (AoUnitUnderTest for the device being tested, AoTestEquipment for the bench and instruments, AoTestSequence for the procedure followed), and measurement structure (AoMeasurement for a recording session, AoMeasurementQuantity for individual measured channels, AoSubMatrix and AoLocalColumn for partitioning data into storage blocks).

The ASAM ODS base model also defines dimensions (AoQuantity and AoUnit for physical quantities and their units) and security (AoUser, AoUserGroup for access control). Every element in the base model carries defined semantics, which means that a tool reading an ASAM ODS database can determine the meaning of data without custom documentation.

The application model is the second layer of the ASAM ODS architecture. Each organization derives its application model from the base model through a process called derivation, where application-specific elements inherit the attributes and relationships of their corresponding base elements while adding domain-specific extensions. A powertrain testing lab might add attributes for engine speed range, fuel type, and exhaust gas temperature to its derived measurement element. A crash testing lab might add attributes for impact angle, barrier type, and dummy model.

Both application models remain compatible with any ASAM ODS-compliant client because the client understands the base model semantics that every derived element preserves. This base model / application model abstraction is one of the most significant design decisions in the ASAM ODS architecture. It provides the flexibility to represent virtually any test domain while maintaining the interoperability that makes the standard valuable.

The connection between metadata and mass data is managed through pointer elements in the data model. An AoExternalComponent element links a measurement channel's metadata to the binary data stored in an external repository, whether that repository is a filesystem, an object store, a cloud storage bucket, or a data lake partition. This indirection means that the same metadata layer can point to mass data stored in different technologies at different sites, and the mass data storage can evolve independently of the metadata schema.

Mixed-mode architecture is the implementation pattern where an ASAM ODS server stores metadata in a relational SQL database and mass data in a separate optimized repository. This separation is not mandated by the ASAM ODS standard itself, which defines the API and data model without prescribing the storage engine, but mixed-mode has become the dominant implementation approach because it aligns each data type with the storage technology best suited to its access patterns and volume characteristics.

Metadata grows slowly. Each test adds kilobytes of descriptive information: test conditions, equipment identifiers, timestamps, project references, and channel definitions. Over years, a large organization may accumulate tens of terabytes of metadata, and every byte needs to be queryable. SQL databases excel at this workload. Finding "all engine tests from Q4 2025 with intake air temperature above 40 degrees Celsius" resolves in milliseconds through indexed queries, joins, and aggregations, without touching a single byte of measurement signal data.

Mass data grows fast. A single test run can produce gigabytes of time-series signals, high-frequency vibration recordings, or image sequences. Over years, a large organization accumulates petabytes of measurement data, and the access pattern is fundamentally different from metadata: mass data is read sequentially in large blocks, streamed to analysis tools, and rarely queried by content. Storing this data in SQL databases as BLOBs creates bloat, slows backups, degrades query performance on the metadata tables sharing the same database engine, and wastes expensive storage on a workload that does not benefit from SQL indexing.

Mixed-mode solves this mismatch by placing each data type where it performs best. The SQL database handles metadata queries with the speed and reliability of a mature relational engine. The mass data repository, which can be a local filesystem, a network-attached storage system, a cloud object store like Amazon S3 or Azure Blob Storage, or a data lake backed by Apache Parquet, handles bulk data access with the throughput that sequential workloads demand.

The practical benefits of mixed-mode architecture compound at enterprise scale. Independent scaling means the organization can add metadata query capacity (more SQL compute, more memory, faster SSDs) independently of mass data storage capacity (more disk shelves, more cloud buckets, cheaper cold-storage tiers). Cost optimization becomes possible because metadata stays on fast, expensive storage while mass data moves to the appropriate tier based on access frequency. Backup and archival strategies can differ by tier: frequent, small metadata backups alongside incremental, large-volume mass data archival. The mass data backend can be swapped entirely, migrating from on-premises storage to cloud object storage, without changing the metadata layer, the API, or the applications that query it.

HighQSoft's AReS Libertas server implements mixed-mode with metadata in SQL (supporting PostgreSQL and Oracle) and mass data in dedicated repositories. The Janus Platform extends mixed-mode by federating across multiple mass data backends, including other ODS servers, MDF4 files on filesystems, TDMS files, Parquet partitions in data lakes, and cloud object stores, while presenting one unified metadata view through the standard ASAM ODS API. This federation layer means that an organization adopting ASAM ODS does not need to migrate existing data into a single storage system; Janus connects to data where it already lives and makes it queryable through the standard interface.

The choice of storage approach has long-term consequences for query performance, operational cost, and architectural flexibility. The following comparison summarizes three common approaches and their tradeoffs at the scale of an enterprise test data repository.

Mixed-mode is not the only valid approach for every scenario. A small team managing a modest volume of test data may find an all-in-SQL deployment simpler to operate, and the performance limitations may not surface at small scale. However, for organizations producing terabytes of measurement data per month across multiple test domains and expecting the data to remain accessible for decades, mixed-mode provides the architectural headroom to grow without fundamental redesign. HighQSoft's AReS Libertas supports mixed-mode as its primary deployment pattern, and the largest customer deployments on this platform manage databases exceeding 64 terabytes of metadata alone, a scale that demonstrates the viability of this architecture at enterprise production volumes.

The transition from ASAM ODS 5 to ASAM ODS 6 represents the most significant evolution in the standard's three-decade history. It replaced the communication protocol, modernized the data formats, introduced cloud-native deployment capabilities, and resolved the technical barriers that had limited ASAM ODS adoption in the previous generation. Understanding this transition matters because many of the perceptions about ASAM ODS, that it is complex, slow, difficult to integrate, or requires specialized expertise, originate from the ODS 5 era and do not apply to ODS 6 implementations.

The CORBA protocol that defined ASAM ODS 5 was a natural choice when the standard was first developed in the 1990s, but it became an increasingly serious barrier as enterprise IT environments adopted strict firewall policies, virtualized infrastructure, and cloud-first architectures. CORBA's dynamic port allocation conflicted directly with firewall rules, and each object access required a separate network round-trip, creating performance problems when applications needed to traverse millions of measurement channels. The expertise required to build and maintain CORBA integrations was concentrated among a small number of specialists, which made ASAM ODS 5 implementations expensive to develop and difficult to support.

ASAM ODS 6, introduced with version 6.0 in 2017, replaced CORBA entirely with HTTP/REST. This was not simply a protocol substitution; it fundamentally changed how ASAM ODS systems are built, deployed, and integrated. HTTP is the standard communication protocol of the web, supported natively by every programming language, framework, and platform. An ASAM ODS 6 server is an HTTP service that can be deployed in a Docker container, orchestrated by Kubernetes, placed behind a load balancer, monitored with standard observability tools, and accessed from Python scripts, MATLAB sessions, web browsers, or AI assistants through the same protocol that powers every web application on the internet.

The data format evolution from XML-centric ATFx to JSON, Parquet, and AVRO reflects the broader shift in the data engineering landscape toward columnar and binary formats optimized for analytics workloads. JSON provides human-readable metadata exchange. Parquet enables efficient columnar storage for mass data in data lake environments. AVRO supports schema evolution for streaming workloads. These formats connect ASAM ODS to the broader big data ecosystem, enabling integration with Apache Spark, cloud analytics services, and machine learning pipelines without custom data extraction code.

Organizations running existing ASAM ODS 5 systems do not face a binary choice between legacy and modern. HighQSoft's platform supports both ODS 5 and ODS 6 interfaces, and the Janus Platform can federate data across servers running different ODS versions. This means organizations can migrate incrementally, deploying new ODS 6 infrastructure while maintaining access to existing ODS 5 data, and retiring the older systems on their own timeline rather than in a single high-risk migration event.

These are the questions engineers and architects ask most often about how ASAM ODS works.