ODS (Open Data Services) focuses on the persistent storage and retrieval of testing data. The standard is primarily used to set up a test data management system on top of test systems that produce measured or calculated data from testing activities. Components of a complex testing infrastructure can store data or retrieve data as needed for proper operation of tests or for test data post-processing and evaluation. A typical scenario for ODS in the automotive industry is the use of a central ODS server, which handles all testing data produced by vehicle test beds. The major strength of ODS as compared to non-standardized data storage solutions is that data access is independent of the IT architecture and that the data model of the database is highly adaptable yet still well-defined for different application scenarios. Despite this flexibility, clients can query the data from the database and still correctly interpret the meaning of the data. This is achieved by various means through the standard.
ODS servers act as data fusion centers of data from different test beds and measurement devices from different vendors. Data can be accessed independently of their origin via the same methods and interfaces. This even extends to mass-data stored in external files (ASAM MDF), where the DB only holds a pointer to that external storage location. The same API methods are used for DB-internal measurement data access as well as to external data access, so that users have completely transparent access to the data. Furthermore, ODS servers are scalable, which allow to extend the data models and add more clients to the overall tool chain without having to setup a new server for every extension.
ODS was one of the first standards developed by ASAM, reaching back as far as the early 1990th. The initiators and main contributors of the standard were BMW, Daimler and Porsche. BMW deployed one of the first ODS server installations for a wind tunnel, but otherwise early versions of ODS did not reach a wide market acceptance. This changed with the release of ODS 3.0 at the end of the 90th. The first commercially available installations became available from independent suppliers. ODS begun to be used as the test data management system for test beds across the European automotive industry. The standard rapidly evolved and got several extensions in 2003 with version 5.0 such as an object-oriented API, an XML-based data ex-change format (ATFX) and application specific data models for NVH and test bed calibration. The release 5.3.0 from 2013 includes a new data model for bus data.
Main contributors to the standard are Audi AG, AVL List GmbH, BMW AG, Cologne University of Applied Science, Daimler AG, EPOS CAT GmbH, HEAD acoustics GmbH, HighQSoft GmbH, HORIBA Automotive Test Systems GmbH, LMS International NV, Müller-BBM VibroAkustik Systeme GmbH, National Instruments Corporation, Porsche AG, Robert Bosch GmbH and Volkswagen AG.
Test systems in the automotive industry are expensive with respect to commissioning and operation. Furthermore, they produce a lot of data. In the early 90th, vendors of test automation system supplied their own data evaluation tools operating on data storage solutions as part of their automation system. Those systems were proprietary and tailored-made for customer needs. As a consequence, many diverse systems existed, which were mostly incompatible to each other. Stored data were usually only accessible and understandable by those who produced the data. A wide variety of tools with data models, APIs and data exchange formats made it very hard to reuse test results. Wrapper-APIs were needed to link different tools, causing instability of the tool chain. Data converters had to transform data to different formats, which bore the potential to caused unintended modification, re-interpretation or loss of data.
Besides those issues, the most critical problem was data ambiguity. If the nomenclature, scope and semantics of data is not well defined, then users cannot trust the data or even misinterpret it. For example in the NVH application area, the measurement of loudness levels (phon) are dependent on the choice of sound pressure levels and frequencies. Loudness level measurements may follow standardized contours for equal loudness and may use filters with specific threshold parameters. Such meta data needs to be known before NVH specialists can correctly interpret loudness measurement data. Furthermore, they need accompanying data about the test such as the location and type of microphones. Creators of test data typically used the names of measurement channels to describe such accompanying data. Mnemonics, abbreviations and letter codes were used to convey meta information via the name of measurement channels. If those codes were not clearly and systematically documented, then consumers of such testing data had to speculate about the meaning of such names. Over an extended period of time, such name coding schemes have caused confusion of Babylonian dimensions. Other sources of error were the use of different data types, physical units or scaling formulas, which further led to misinterpretation of measurement values. All those potential pitfalls could cause costly re-testing at best, or even more costly recalls of released products at worst.
ODS solves the problems of data interpretation through the specification of data models with well-defined semantics. This allows to avoid redundant testing and misinterpretation of existing test data. Furthermore, within one data model, the same testing data uses the same labels, data types, units and conversion methods. There is little room for misinterpretation. Standardized APIs and data exchange file formats further avoid the above mentioned wrapper APIs and data converters, hence saving costs for their development and the time losses that they would cause due to instable tool chains and degraded data quality.
There are many further advantages of a standardized test database. Test bed operators and development experts can more easily determine, if they have a sufficient amount of data to stop further testing. Furthermore, since prototypes are increasingly scarce and test rigs are booked out for months, users of test beds can produce test data ahead and easily retrieve it once needed at a later time. Data becomes available for cross-functional teams, e.g. for NVH and engine task-force teams, who have to jointly investigate a field issue of unexpected high noise levels in production vehicles. An ODS server promotes collaboration by making the data available across department boundaries and allow their unambiguous interpretation by experts of different professions.
The ODS standard focuses on the persistent storage and retrieval of data. It broadly covers all use cases in the testing area and is primarily used in conjunction with test automation systems. ODS servers were first used in chassis dynamometers, powertrain dynamometers, NVH test labs and crash test labs.
The standard allows to create application specific data models, so that a wide area of test applications can be covered. Typical application areas of ODS servers are component test beds for brakes, shock absorbers, fuel injectors, catalytic converters and other automotive components. Quality assurance test beds use ODS servers for storing raw data and classification data. Furthermore, ODS servers capture measurement data from climate chambers, wind tunnels, stress and endurance test rigs, hydro-pulse test systems, proving ground vehicle tests and fleet tests on public roads. More recently, ODS has been used for testing components of alternative propulsion systems, e.g. testing of electrical motors, batteries and power electronics. Another strength of ODS is the capability to combine test data with data about the UUT (unit-under-test), hence it is possible to track the development progress of components over time.
Large OEMs use enterprise-wide ODS databases, e.g. one ODS server system for the complete engine development area. Data can be retrieved independently of who produced the data. In some areas, the amount of raw data is too large to be viewed and evaluated by humans. Automated client applications can browse through the data model, retrieve data, evaluate results, generate test reports and archive data without human interaction. Generic ODS clients can work with ODS servers from different vendors without major integration efforts.
ODS is further used for test data exchange in a manufacturer/supplier relationship. This typically requires the exchange of data via files. The content or part of the content of an ODS database can be exported in an XML-compliant file format. The format contains the ODS data model and testing data. The receiver of the files can import the data via XML-importers and are able to correctly understand and store the data in their own data processing tools or databases.
Data models in ODS provide a storage location and a meaning for data. The latter is very important. Testing data can only be understood and applied correctly, if the following information is known (→ corresponding base model element given below each question):
- Where is my data?
- What was tested?
- What test equipment was used?
- Which test was performed?
- What was the purpose of the test?
- Which person ran the test?
- When was the test carried out?
→ AoMeasurement - measurement_start, measurement_end
A user, who queries testing data from an ODS server, is able to get an answer on these questions. Prerequisite for this is a meaningful and well-defined application model. While the definition of such an application model is the responsibility of the user when he sets up an ODS server, the ODS standard provides several aids for this job:
- Base Model: Foundation and reference for application models.
- Predefined Application Models: Provide a starting point for the definition of customer-specific application models. Given for test object geometry, NVH testing, test stand calibration data, bus data, testing workflows.
ODS base model
The base model can be viewed as a rough data classification of testing data. The elements of the base model are well-defined with respect to syntax and semantics. The syntactical definition of elements makes sure that they can be read by all ODS clients. The semantic definition of the elements ensures that they are understood the same way by each client. This shall be demonstrated by an example:
AoMeasurementQuantity is the base element that represents the values of a measured physical quantity organized as a column in a measurement matrix. This is the "meaning" or "semantics" for AoMeasurementQuantity, which allows clients to correctly interpret and categorize the data. AoMeasurementQuantity has further attributes, which define the syntax of its data. For example, the attribute datatype describes the storage format on bit-level for the measured values (e.g. DT_BOOLEAN, DT_BYTE or DT_FLOAT, etc.) and the attribute dimension describes the number of values in the matrix column. This is the "format" or "syntax" for AoMeasurementQuantity, which allows clients to correctly read and process the data.
Furthermore, the base model describes relations between elements. For example, AoMeasurementQuantity references AoPhysicalDimension, which is the base element that represents information about the kind of quantity, e.g. force or temperature. It also references AoUnit, which is the base element that represents information about the unit, e.g. Newton or Kelvin. With such information, a client is now well informed how to interpret and process the data that it has received from an ODS server. For example, a client knows now how to correctly convert data so that the physical units match (prevent comparing Degree Celsius with Kelvin) and categorize data of the same type (prevent displaying temperature data and force data in the same diagram).
The elements of the base model are briefly described in the following table.
Used to organize measurements and corresponding input/output data.
Are the base elements where test results are stored.
Is used to keep information on a physical quantity that may be of relevance for any or all of the tests kept in the database.
Represents those quantities that are used in a measurement.
Are used to keep information on the relationship between result values (plain numbers) and the corresponding units, thereby allowing for correct arithmetic or relational operations.
Contains information about what has been tested.
Contains information about which equipment has been used.
Contains information about which sequence of steps has been processed during testing.
Contains information about which test device was used.
Are base elements used for handling security aspects.
Is used for logging purposes.
Can be used e.g. to avoid redundancy by storing information that is used by several elements only once.
Holds alias names for an application element, e.g. for names in different languages. Specifies alias names for an application attribute.
Is a base element that does not carry a specific meaning and which may be used to store information that does not fit to the other base elements’ meanings.
The base model is actually not directly used as a model for databases. It is typically too generic for this purpose. However, the base model is used as a parent for deriving specific application models. An element of an application model always has a reference to a base model element, thereby giving it the meaning of the base model element.
Application models cover specific application areas such as NVH testing or engine testing. They are derived from the base model and define, which of the base model elements are really used in a database. Each element of an application model references an element of the well-defined base model, thereby adding meaning to the data.
So, building an application model in ODS means to map application-specific elements to elements of the base model. For example, an "engine" test bed tests engines with the components "intake manifold", "piston" and "engine block". We map the "engine" to the base model element AoUnitUnderTest and the components "intake manifold", "piston" and "engine block" are mapped to AoUnitUnderTestPart. Furthermore, we want to measure the temperature for each component and store the data in the ODS database. So, we link the elements "intake manifold", "piston" and "engine block" to "Measurement" (which maps to the base model element: AoMeasurement). "Measurement" shall contain "TemperatureInstantaneous" (maps to base model element: AoMeasurementQuantity). "TemperatureInstantaneous" shall references to "Kelvin" (base model element: AoUnit), which has a reference to "Temperature" (maps to base model element: AoPhysicalDimension).
Example of a mapping of application model elements to base model elements
Client applications that query the application model can still understand the meaning of the specific application data model elements through those relations to the base model. This allows users of ODS-compliant databases to create tailored application data models for their specific testing use-cases, and client applications are still able to correctly process the data from such tailored databases due to the well-defined syntax and semantics of the referenced base model elements.
Besides those base relations, the designer of an application model may introduce new relations between application elements. He may also add attributes that are specific for his test use-case. So, the application model can have additional relations an attributes, which do not exist in the base model. They are still understandable for a client, since they exist in the context of their element, which always has a relation to the base model.
Continuing the example from above, we want to document the customer to whom the engine under test belongs to. So, we add a reference to "Engine" that points to the element "Customer" (which maps to the base model element: AoUser). This relation does not exist in the base model. We may further add to our application model element "intake manifold" the attributes "weight" and "material", and do the same for the other components "piston" and "engine block". This allows to store weight and material information to the unit-under-test.
The ODS standard contains five pre-specified application models for specific application areas:
- test object geometry
- NVH testing
- test stand calibration data
- bus data
- testing workflows
ISO 22240 specifies a sixth model with the name "Vehicle Safety Information Model" (VSIM), which standardizes the data storage of vehicle safety tests. This model is ODS-compliant, but it is owned by ISO and as such is not included in the ASAM ODS standard.
Using such an application model guarantees that clients store the same information with the same data formats in the same way, and thus the meaning of the stored information can be generally understood by different clients. The pre-specified application models are ready-for-use, however, it is expected that users will tailor them for their needs by adding company-specific items.
Application models just provide meta-information about the structure of the data to be stored and retrieved. They need to be instantiated as a database on an ODS server. This allows to store and retrieve actual data, i.e. client applications can then create specific instances of application model elements and begin to store values in its attributes. Furthermore, clients can even create new instance attributes and new relations between two instances in the instantiated data model that do not exist in the underlying application model.
Physical Database Model
The ODS standard specifies how a database should initially be constructed to physically store data in a compliant way. The standard focuses on relational databases as this is the most commonly used database technology in the industry.
Storing information using a relational database requires to specify which tables must be available in the database, what columns they need to have, which table entries must be unique (because they are used as keys) and much more. An ODS-compliant database clearly distinguishes between meta information about the application model on the one side and the actual values on the other side. They are stored in different tables.
The meta information about the application model is stored in three static tables.
SVCENT: Table of application model elements
Holds for each element a unique ID, a name, a reference to the base model element and the name of the table where the instances of the application elements are stored.
SVCATTR: Table of application model attributes
Contains a list of the application attributes of all application elements and all unidirectional [1,n] application relations. For attributes, the table allows to identify the attribute by name, to which application model element they belong to and (if available) to which base model element they belong to. For relations, the table contains the ID of the target element. Furthermore, the table contains the data type of the attribute values and the column name in which the attribute values are stored.
SVCREF: Table of application relations
Contains all bidirectional [n,m] application relations.
Values of application model instances are stored in instance tables.
Tables containing instances and their attributes
Is referenced by SVCENT and SVCATTR and contains the actual values for each attribute.
Tables containing instance relations of bidirectional [n,m]-relation types
Contains a matrix that relates instances of elements to each other.
Tables containing instance attributes
Contains attributes and relations that are added to instances and thus do not exist in the application model.
Tables containing measurement results
Contains the measurement data.
Tables containing security information
Contains tables to restrict access to instances, elements and attributes, as well as providing access control templates.
The standard defines two distinct APIs for access to the database. They abstract client access from the actual implementation of the database on the server. One API uses RPC-technology (Remote Procedure Call) and the second API uses OO-technology (Object Oriented) access based on the CORBA architecture (Common Object Request Broker Architecture). Furthermore, the API commands allow to retrieve actual test data and to access meta information about the application model. The meta information allows a client to interpret and understand the application model, thus allowing it to operate with different ASAM ODS data models.
The first ASAM ODS interface specifications historically used RPC and some of today's implementations are still base on the RPC-API. For compatibility reasons the RPC-API is still supported by ASAM ODS, though the object oriented OO-API will be the main focus of further development in the future. If given the choice, the RPC-API shall not be used any longer.
OO API methods
The recommended way to access ASAM ODS interfaces is to use the OMG-specified CORBA standard and the ASAM-specified OO-API. CORBA 2.3 or higher is required. CORBA does not specify what kind of services an interface provides. Instead, CORBA specifies how an interface can be identified, found and connected to by any component that intends to use it. ASAM ODS specifies an OO-API, which is implemented with the CORBA approach.
The OO-API provides read-access to the base model, and read-write access to the application model and their instances. Clients can query the factory interface of an ODS server and initiate a session. Next step is to request a reference to the base or application model structure. It is also possible to request the structure by value, depending on network performance and load. The client is then able to browse through the data model by querying elements and following relations through the model. In application models, clients can also add or remove application elements, application attributes and relations to other elements, thus changing the data model. More importantly, the clients may obtain a reference to an instance or instance iterator (in case the application element has multiple instances) of an application element. Instances hold the actual values stored in the database.
The values of measurements have a specific, more sophisticated interface, called "Measurement" and "SubMatrix". They allow additional actions to be performed on the instances of measurement data. Measurements may be taken with different sample rates for different quantities. Such measurements with the same sample rate are stored in "SubMatrix". All quantities of a measurement are then combined in the "Measurement" element. This can save significant amounts of storage, since this avoids empty cells in matrixes for non-sampled measurement points. A client can read, write, add, modify or remove individual data, rows, sub-matrixes or the complete measurement matrix.
ODS offers several more features, which makes client-server access efficient and safe:
- Mixed-Mode Server: ODS uses the ASAM MDF binary file format to store mass data. Instead of importing such data into the database, the MDF-file is just referenced in there. Access to the data is completely abstracted through the OO-API, i.e. clients access data in MDF-files exactly the same way as they access data stored internally in the database. This makes storing large amounts of data transparent to clients and very efficient for the server.
- Queries: Client requests may be narrowed through a set of relational ('>', '<', '=', etc.) and logical ('AND', 'OR', 'NOT', etc.) operators, which eases access to huge amounts of data.
- Access Control: Client access can be restricted via access rights for each application element.
File Description Formats
Structure of the ATF/XML file
The standard defines the ATF format (ASAM Transport Format), which is a text-based description format for file-based data exchange between tools. ATF allows to transport the complete application model as well as the instances with their attributes, relations and values.
The specification allows to split the information into a set of individual files that are linked together via an include mechanism. Furthermore, the file format allows to transport mass data in a binary format, e.g. via ASAM MDF. Such data would otherwise appear in AoLocalColumn. Instead of storing mass data as text in ATF, which is not very efficient, the standard allows to describe the structure of the data in ATF and then contain references to MDF files. Consequently, ATF and binary files such as MDF/MD4 can be used to transport huge amounts of data quite efficiently between different ODS applications.
The ATF description format comes in two variants. The classic ATF/CLA format is a non-XML-based description format that is still kept in the standard for legacy reasons, but is not expected to be updated in future revisions of the standard. The same information can also be transported via the newer ATF/XML description format, which shall be preferably used in new tools and will be further developed in future revisions of the ODS standards.
ATF/CLA uses plain ASCII text and is still supported by most of the available ODS tools on the market. It has a simple five-tier structure:
- Version: provides information on the ATF/CLA version.
- Files (optional): provides a list of physical files that together build the complete ATF/CLA file.
- Applelem: is a description of an application model element and may be repeated for each element that is going to be transported by this ATF/CLA file.
- Instelem (optional): is a description of an instance of an application model element and may be repeated for each instance that is transported by this ATF/CLA file.
- Endfile: marks the end of the ATF-file.
ATF/XML uses the UTF8 character set. XML allows for a more detailed automatic verification of the content of file than what is possible with ATF/CLA. Furthermore, there are plenty of XML tools on the market for viewing, editing and processing of XML files. Also ATF/XML is organized in five top-level elements:
- Documentation: Contains general information about the origin of the file(s) and some description texts.
- BaseModelVersion: Provides the ODS release number of the base model used for the application model in this file(s).
- Files: List of external files containing binary data.
- ApplicationModel: Contains a description of the application specific data model, consisting of elements and their relationships to one another.
- InstanceData: Contains the actual values of the application model. May also contain references to external binary files that contain the values.
Benefits & Advantages
The main benefit of the ODS standard is to get rid of the variety that databases, APIs and description format can potentially have, and combine best industry practices of such variations to one standard. One of the major benefits of ODS is that measurement data is safely understood by all users. This is achieved by a semantically well-defined data model. Measurement data is amended with meta-data about their origin, sensors, sensor positions, measurement methods, environment conditions and other descriptive data of the circumstances of the data acquisition. This data can be linked with details about the UUT, e.g. version and configuration. Even though the user of the data might not have been present during the time of testing, which may occurred half a year ago, and the UUT does not exist any longer, the test data is still understandable and can be used. Tests do not have to be repeated and projects can move on without delays.
The access to the data is completely abstracted from its origin, e.g. it is independent of the person, who designed and carried out the tests, independent of the equipment that was used to produce the measurement values, independent of the ODS server vendor and independent of the IT and communication infrastructure between the server and the clients. ODS establishes a true, enterprise-enabled infrastructure of data storage and retrieval.
Another important aspect is the capability of long-term archiving of data in accordance with legal requirements. ASAM ODS ensures long-term stability through standardized technologies. This is typically accepted as a proof by OEMs, certification agencies or legal institutions.
Furthermore, long-term archiving can become prohibitively expensive. For example, modern engine test beds are capable of producing several terabytes of data per day. However, not all the data is used later one. ODS allows to track, whether data actually has been accessed and who accessed it. This allows to only move data to a long-term archive that was actually used by relevant people or development tools.
Open source project openMDM
Today, ODS is typically part of a comprehensive system for enterprise-wide storage and retrieval of test-related data. The standard is widely used by German OEMs, including BMW, Daimler and Porsche, who initiated the standard. Audi started in 1999 the "Measurement Data Management" project based upon ASAM ODS and moved major parts of the system software to an open source project by 2008. 30 companies participate in this project as of 2012.
Since OS 3.0, several ODS server suppliers have evolved and provide COTS products. Engineering service providers and system integrators exist to set up comprehensive database solutions, who work either independently or have strategic alliances with one of the ODS server vendors. Some service providers have specialized in specific application areas, such as NVH. The standard and available tools can be considered as mature and stable.
The adoption of ODS continually increases across Europe and North America. Since 2011, ASAM supports a regional project group in the US, who is developing a standard for Web-access to ODS servers. This effort will further leverage the position of ODS in North America.
List of Deliverables
The standard includes the following deliverables:
- Standard documents
- ONC RPC interface definition file
- IDL interface definition file
- XML schema files
- EXPRESS schema file
- ATF and ATFX example files
Example of an ATF file in the classic, non-XML format.
Example of an ATF file in the XML format.
Example of an ATF file in the XML format, containing data from the test object geometry application model.
- Workflow for automotive test data analysis based on Petri nets and stored by ASAM ODS; Rainer Bartz; IEEE/ICIT; 2009; ISBN: 9781424435074
- Contribution to a workflow-based information management in automotive testing and data analysis; Rainer Bartz; IEEE/ICIT; 2010; ISBN: 9781424456963