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. With the major release 6.0 in 2017, ASAM added a modern web-service API using the Hypertext Transfer Protocol for client-server communication and Google Protocol Buffers for the serialization of data. The new API significantly eases communication via the Internet and is an important step towards enabling ODS for Big-Data systems.
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):
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:
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" forAoMeasurementQuantity, which allows clients to correctly interpret and categorize the data.AoMeasurementQuantity has further attributes, which define the syntax of its data. For example, the attributedatatype describes the storage format on bit-level for the measured values (e.g. DT_BOOLEAN, DT_BYTE or DT_FLOAT, etc.) and the attribute dimensiondescribes the number of values in the matrix column. This is the "format" or "syntax" forAoMeasurementQuantity, 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.
Element | Description |
---|---|
AoTest AoSubTest AoMeasurement | Used to organize measurements and corresponding input/output data. |
AoSubmatrix AoLocalColumn | Are the base elements where test results are stored. |
AoQuantity AoQuantityGroup | 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. |
AoMeasurementQuantity | Represents those quantities that are used in a measurement. |
AoUnit AoUnitGroup AoPhysicalDimension | 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. |
AoUnitUnderTest AoUnitUnderTestPart | Contains information about what has been tested. |
AoTestEquipment AoTestEquipmentPart | Contains information about which equipment has been used. |
AoTestSequence AoTestSequencePart | Contains information about which sequence of steps has been processed during testing. |
AoTestDevice | Contains information about which test device was used. |
AoUser AoUserGroup | Are base elements used for handling security aspects. |
AoLog | Is used for logging purposes. |
AoParameter, AoParameterSet | Can be used e.g. to avoid redundancy by storing information that is used by several elements only once. |
AoNameMap, AoAttributeMap | Holds alias names for an application element, e.g. for names in different languages. Specifies alias names for an application attribute. |
AoAny | 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).
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:
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.
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.
Table | Content |
---|---|
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.
Table | Content |
---|---|
Tables containing instance attributes | Contains attributes and relations that are added to instances and thus do not exist in the application model. |
Tables containing instance relations of bidirectional [n,m]-relation types | Contains a matrix that relates instances of elements to each other. |
Tables containing instances and their attributes | Is referenced by SVCENT and SVCATTR and contains the actual values for each attribute. |
Tables containing security information | Contains tables to restrict access to instances, elements and attributes, as well as providing access control templates. |
The Standard defines three distinct APIs for access to the Database. They abstract client access from the actual implementation of the Database on the server. 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 (Remote Procedure Call) and some of today's implementations are still base on the RPC-API. The object oriented OO-API based on the CORBA architecture (Common Object Request Broker Architecture) succeeded the RPC-API. For compatibility reasons, both legacy APIs are still included in ASAM ODS.
Since version 6.0.0, ODS includes a web-service API using the Hypertext Transfer Protocol. The new HTTP-API furthermore uses the Google Protocol Buffers Specification for the serialization of application data. The HTTP-API includes most of the functionality of the OO-API and RPC-API, and is capable of replacing it in typical communication scenarios. The new API significantly eases client-server communication via the Internet and is an important step towards enabling ODS for Big-Data systems. The recommended way to access ASAM ODS is to use the HTTP-API.
Major characteristics of the HTTP-API are:
The HTTP-API consist of 30 methods for establishing a web-service based request-response type of communication between the client application and the ODS server. The majority of methods use the POST command, as this command already exists since HTTP 1.0 and is supported by even older network infrastructures. Furthermore, the POST command allows an efficient transfer of method parameters in the proto3-format. Three methods of the API use the DELETE and GET command of HTTP.
The body of the API method can have two alternative content-types for transfering structured data in a serialized format:
Each communication session between client and server is identified via a connection identifier (conI), which is generated by the server as a response to the "POST {baseURI}/ODS" command. All subsequent commands contain the connection identifier.
HTTP-API methods have the basic structure "HTTP-Command", "Path" and "Action". The Action contain the actual functionality specified in ASAM ODS. The API defines twentyfour Standard methods for common functions such as opening and closing a connection to the server, read/write/modify instance data (i.e. meta-data and Measurement-data), modification of the application model, functions for a client to handle transactions, and other functions. Transactions consist of a sequence of actions, which are performed as if they were just one action, thus ensuring data consistency. If actions of one transaction did not fully complete, then the server can be rolled back, ensuring the original condition before the start of the transaction. The next table lists all Standard methods and provides a brief description of the Action.
HTTP-Command | Path | Action | Description |
---|---|---|---|
POST | {baseURI}/ | ods | Request a connection ID to establish a communication session between client and server. |
DELETE | {baseURI}/ | ods/{conI} | Close the session. |
POST | {baseURI}/ods/{conI}/ | context-read | Retrieve all or a subset of context variables (name-value pairs that specify settings for the server). |
POST | {baseURI}/ods/{conI}/ | context-update | Set the value of one or more context variables. |
POST | {baseURI}/ods/{conI}/ | data-read | Read instance data, e.g. attribute values, relations, and Measurement data through 'values', 'flags', and 'generation_parameters' of the local column. |
POST | {baseURI}/ods/{conI}/ | valuematrix-read | Read the mass data of a complete Measurement or of a subset of it. |
POST | {baseURI}/ods/{conI}/ | data-create | Create new instance, set attribute values and relations. |
POST | {baseURI}/ods/{conI}/ | data-update | Modify new instance, set attribute values and relations, write mass data. |
POST | {baseURI}/ods/{conI}/ | data-copy | Copy an instance. |
POST | {baseURI}/ods/{conI}/ | data-delete | Delete one or multiple instance. |
POST | {baseURI}/ods/{conI}/ | n-m-relation-read | Get a list of all instances that are related to a given instance through an n:m relation. |
POST | {baseURI}/ods/{conI}/ | n-m-relation-write | Set, add, or delete the n:m relations of an instance to other instances. |
POST | {baseURI}/ods/{conI}/ | transaction-create | This method starts a transaction. |
POST | {baseURI}/ods/{conI}/ | transaction-commit | This method is used to signal to the ODS server that all activities within the current transaction are submitted, and that the client wants the server to make all resulting changes persistent in the ODS data storage. |
POST | {baseURI}/ods/{conI}/ | transaction-abort | This method may be invoked by a client if it wants all activities within the current transaction to be rolled back. |
POST | {baseURI}/ods/{conI}/ | model-read | This method retrieves the application model that is currently stored at the ODS server. |
POST | {baseURI}/ods/{conI}/ | model-delete | This method allows to remove application elements completely or remove application attributes from an application element or application relations between two application elements. |
POST | {baseURI}/ods/{conI}/ | model-update | This method allows to create a new and modify an existing application model and its parts at the ODS server. |
POST | {baseURI}/ods/{conI}/ | model-check | This method allows to determine whether the application model as it is currently held on the ODS server for this {conI} obeys the rules of ASAM ODS. |
POST | {baseURI}/ods/{conI}/ | basemodel-read | This method allows to retrieve the ASAM ODS base model from the ODS server. |
POST | {baseURI}/ods/{conI}/ | asampath-create | This method may be used to determine the ASAM path for a specific instance of an application element. |
POST | {baseURI}/ods/{conI}/ | asampath-resolve | This method allows to retrieve an instance of an application element, if only its ASAM path is known. |
POST | {baseURI}/ods/{conI}/ | file-access | This method may be used to retrieve an URI for accessing files, blobs and bytestreams. |
POST | {baseURI}/ods/{conI}/ | file-control | This method may be used to take a file under control or remove it from control of an ODS server. |
The Standard also defines six special methods to register clients to receive event notifications from the server and for security administration. A server can sent notifications if:
The server can identify a specific client by the client-generated unique receiver identifier {recI}. The next table lists all special methods and provides a brief description of the Action.
HTTP-Command | Path | Action | Description |
---|---|---|---|
POST | {baseURI}/ods/{conI}/ | security-read | This method allows to retrieve information on the ACL-entries (access control list) to an application element, or to one or more attributes or relations of an application element or to one or more instances of an application element. |
POST | {baseURI}/ods/{conI}/ | security-update | This method allows to attach ACL-entries to an application element, or to one or more attributes or relations of an application element or to one or more instances of an application element, or to modify or remove already existing ACL-entries. |
POST | {baseURI}/ods/{conI}/ | initial-rights | This method allows to set, remove, or modify a set of session-specific ACL-templates. |
POST | {baseURI}/ | events/{recI} | This method allows a client to register with the ODS server for a set of events. |
DELETE | {baseURI}/ | events/{recI} | This method allows a client to unregister from the ODS server. |
GET | {baseURI}/ | events/{recI} | This method allows a POOL-mode client to retrieve a set of events from the ODS server. Once the client has registered as a receiver for events at an ODS server, that server collects all matching events and stores them in a receiver-specific persistent event pool. Each time the client calls this method and thereby references a receiver through the unique {recI}, the ODS server will retrieve all events currently in the event pool for that receiver, and returns them in the response body. |
ODS offers several more features, which makes client-server access efficient and safe:
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:
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:
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.
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.
The Standard includes the following deliverables:
Example_ATF_CLA.atf | Example of an ATF file in the classic, non-XML format. |
Example_ATF_XML.atfx | Example of an ATF file in the XML format. |
Example_Geometry.atfx | Example of an ATF file in the XML format, containing data from the test object geometry application model. |