ISO/PAS 22720:2005

PUBLICLY ISO/PAS
AVAILABLE 22720
SPECIFICATION
First edition
2005-12-01
ASAM Open Data Services 5.0
ASAM Services de Données Ouvertes 5.0

Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/PAS 22720 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and
integration, Subcommittee SC 4, Industrial data, based on a description of the Version 5.0 prepared by the
Association for Standardization of Automation and Measuring Systems — Open Data Services.

ASAM ODS
VERSION 5.0
ISO-PAS
CHAPTER 1
INTRODUCTION
Association for Standardization of
Automation and Measuring Systems
Dated: 30.09.2004
© ASAM e.V.
ASAM ODS VERSION 5.0
Status of Document
Reference: ASAM ODS Version 5.0 Introduction
Date: 30.09.2004
Author: Rainer Bartz
Type: Information
Doc-ID: ASAM_ODS_50_CH01_Introduction.PDF
Status: Release
Note: ASAM ODS has invoked a Formal Technical Review (FTR) process which
intends to continuously improve the quality and timeliness of its specifications.
Whenever an error is identified or a question arises from this specification, a
corresponding note should be sent to ASAM (odsftr@asam.net) to make sure
this issue will be addressed within the next review cycle.
Disclaimer of Warranty
Although this document was created with the utmost care it cannot be guaranteed that it is
completely free of errors or inconsistencies.
ASAM e.V. makes no representations or warranties with respect to the contents or use of this
documentation, and specifically disclaims any expressed or implied warranties of
merchantability or fitness for any particular purpose. Neither ASAM nor the author(s)
therefore accept any liability for damages or other consequences that arise from the use of
this document.
ASAM e.V. reserves the right to revise this publication and to make changes to its content, at
any time, without obligation to notify any person or entity of such revisions or changes.
ASAM ODS VERSION 5.0
2 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
Contents
1  INTRODUCTION TO ASAM ODS                              1-3
1.1 GOALS AND BENEFITS OF ASAM ODS . 1-4
1.1.1 POSITIONING OF ASAM ODS WITHIN ASAM. 1-4
1.1.2 DRAWBACKS OF CURRENT SYSTEMS. 1-6
1.1.3 BENEFITS OF ASAM ODS . 1-7
1.2 TECHNICAL APPROACH. 1-8
1.2.1 THE DATA MODEL. 1-8
1.2.2 THE INTERFACES. 1-10
1.2.3 THE PHYSICAL STORAGE . 1-11
1.2.4 THE ASAM TRANSPORT FORMATS (ATF) . 1-12
1.2.5 APPLICATION MODELS . 1-12
1.3 IMPACT ON PRODUCTS . 1-14
1.4 TECHNOLOGICAL LEVEL FOR IMPLEMENTATION . 1-15
1.5 THE ODS DATA MODEL – A DEEPER INSIGHT . 1-16
1.5.1 THE BASE MODEL. 1-16
1.5.2 THE APPLICATION MODEL . 1-19
1.5.3 THE INSTANCES . 1-21
1.6 THE ODS APPLICATION PROGRAMMING INTERFACE (API) - A DEEPER INSIGHT. 1-23
1.6.1 THE OBJECT-ORIENTED API (OO-API) . 1-25
1.6.2 THE PROCEDURAL API (RPC-API) . 1-30
1.7 THE PHYSICAL DATA STORAGE - A DEEPER INSIGHT. 1-32
1.8 THE ASAM TRANSPORT FORMAT (ATF) - A DEEPER INSIGHT. 1-36
1.8.1 ATF/CLA . 1-37
1.8.2 ATF/XML . 1-38
1.9 APPLICATION MODELS - A DEEPER INSIGHT . 1-39
1.9.1 THE NVH APPLICATION MODEL. 1-39
1.9.2 THE CALIBRATION APPLICATION MODEL. 1-39
1.9.3 THE VSIM APPLICATION MODEL . 1-39
1.10 STATUS AND FUTURE STEPS . 1-40
1.10.1 STATUS . 1-40
1.10.2 FUTURE STEPS . 1-40
1.11 REVISION HISTORY. 1-41
ASAM ODS VERSION 5.0 1-1
ASAM ODS VERSION 5.0
Scope
This document is a brief description of ASAM ODS Version 5.0.
Intended Audience
This document is intended for people interested in ASAM ODS Version 5.0. It shall be used
as a brief overview of the features of ASAM ODS Version 5.0.
This document is part of a series of documents referring to ASAM ODS Version 5.0 and must
not be used as a stand-alone document. The documents referenced below build the
technical reference of ASAM ODS Version 5.0 as a whole. They may be requested from the
ASAM e.V. at www.asam.net.
ASAM ODS Specification
The following chapters build the technical reference for ASAM ODS Version 5.0:
¾ ASAM ODS Version 5.0, Chapter 1, Introduction
¾ ASAM ODS Version 5.0, Chapter 2, Architecture
¾ ASAM ODS Version 5.0, Chapter 3, Physical Storage (1.1)
¾ ASAM ODS Version 5.0, Chapter 4, Base Model (28)
¾ ASAM ODS Version 5.0, Chapter 5, ATF/CLA (1.4.1)
¾ ASAM ODS Version 5.0, Chapter 6, ATF/XML (1.0)
¾ ASAM ODS Version 5.0, Chapter 7: N/A ('Security' moved to Chapter 2)
¾ ASAM ODS Version 5.0, Chapter 8, MIME Types and External References (1.0)
¾ ASAM ODS Version 5.0, Chapter 9, RPC-API (3.2.1)
¾ ASAM ODS Version 5.0, Chapter 10, OO-API (5.0)
¾ ASAM ODS Version 5.0, Chapter 11, NVH Model (1.3)
¾ ASAM ODS Version 5.0, Chapter 12, Calibration Model (1.0)
Normative References
¾ ISO 10303-11: STEP EXPRESS
¾ Object Management Group (OMG): www.omg.org
¾ Common Object Request Broker Architecture (CORBA): www.corba.org
¾ IEEE 754: IEEE Standard for Binary Floating-Point Arithmetic, 1985
¾ ISO 8601: Date Formats
¾ Extensible Markup Language (XML): www.w3.org/xml
1-2 ASAM ODS VERSION 5.0
4 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
1 INTRODUCTION TO ASAM ODS
The rapid progress in hard- and software leads to storage of data in many different data base
systems as well as under different hardware and/or server generations – not only within the
automotive industry, but also within the supplying industry.
During development and production of vehicles, a huge mass of data is produced. Today,
data are stored within the automotive industry in a standardised format specified by the
ASAM ODS workgroup. ASAM stands for „Association for Standardisation of Automation and
Measuring Systems“, and ODS stands for „Open Data Services“.
The ASAM ODS standard has the fundamental quality of storing data with an architecture-
independent method. This leads to great advantages when exchanging data between
different sources and possible prospective customers.
This document shall provide an overview of the goals of ASAM ODS as well as the technical
approaches made to achieve these goals.
It is intended for readers with some technical background that want to get an impression on
what ASAM ODS really standardizes and how the standards work. Readers may get an
impression on what it means to implement these standards and what real benefit they may
draw from using the standards.
Furthermore this document may be a starting point for implementers, before they dive into
the detail standards documentation itself.
This chapter must NOT be seen as a specification; it is an introduction with some details to
provide an overview to the interested reader.
ASAM ODS VERSION 5.0 1-3
ASAM ODS VERSION 5.0
1.1 GOALS AND BENEFITS OF ASAM ODS
1.1.1 POSITIONING OF ASAM ODS WITHIN ASAM
The overall ASAM standards structure is shown in the figure, illustrating components which
typically can be found in an automotive testing environment, and how these components use
ASAM interfaces to communicate and interact with each other.
ASAM ODS is that part of the ASAM standards which focuses on persistent storage and
retrieval of data.
ACS CEA
Control-
ULI/ACI ODS Data
System
GDI
Application-
System
MCD
¾ ASAM standards in an example testing environment ½
ASAM ODS describes service interfaces. They can be used by any component of the testing
environment to store its data and/or retrieve data required for proper operation.
Components using these interfaces are typically
¾ data acquisition systems, collecting data from a vehicle, an engine, etc.
¾ test control systems, used for running test procedures
¾ optimization tools, looking for an optimum set of calibration parameters
¾ analysis and reporting tools, presenting data to engineers and decision makers
¾ evaluation tools, supporting research and development tasks
Data stored and retrieved are typically
¾ test procedure configurations of a test control system,
¾ descriptive data of the test equipment and of the unit under test
¾ data measured during a test of an engine on a test bench, a vehicle in the wind tunnel,
etc.
¾ data produced during a simulation run
1-4 ASAM ODS VERSION 5.0
6 © ISO 2005 – All rights reserved
CCC
INTRODUCTION TO ASAM ODS
¾ data resulting from test evaluation tools
¾ calibration data for engine or vehicle parts
The regular way to access ASAM ODS interfaces is, as the figure shows, through ASAM
CCC (this is true for ASAM GDI/ACI and ASAM CEA as well).
ASAM CCC has proposed a server access based on the OMG-specified CORBA standard
which requires object oriented system design.
CORBA does not specify what kind of services an interface provides; this is up to the specific
service provider (in this case: ASAM ODS). Instead, CORBA specifies how an interface can
be identified, found and connected to by any component that intends to use it. Thereby
CORBA cares for a transparent network transfer, if required.
CORBA is an open standard and is wide-spread in all kinds of large-scale industrial and
business processes. ASAM ODS specified an object oriented (OO-)API which can be
implemented with the CORBA approach; however the defined interfaces are not restricted to
CORBA and it may happen in the future that servers based on new technologies come up
providing the same interfaces.
Because the first ASAM ODS interface specification used RPC as communication method
and came up before ASAM CCC started its work, a lot of implementations still base on the
RPC-API. For compatibility reasons the RPC-API will still be supported by ASAM ODS in the
future, though the object oriented OO-API will be the main focus.
Since the access to a persistent data store typically requires network transfer, ASAM ODS is
not generally optimized for realtime performance. However, ASAM ODS does not prevent
realtime operation; time-related behavior depends on the design/implementation decision of
a specific ODS-server as well as on the Object Request Broker (the ORB) used.
ASAM ODS specifies interfaces; the way data is finally stored persistently is not exclusively
defined. While using some kind of object oriented or relational data base (with a common
database model) might be reasonable, that decision is up to the ODS-server implementation.
Although ASAM ODS is the data storage/retrieval oriented part within the ASAM set of
standards, it does not claim exclusive rights to specify file or database formats. Other ASAM
standards may do so as well, if necessary. E.g. it may be required to store configuration or
measurement data of a control system locally during operation. Or it may be required to use
other internationally accepted data formats to exchange data with regulatory institutions (as
e.g. is required for ASAM MCD aspects).
ASAM ODS VERSION 5.0 1-5
ASAM ODS VERSION 5.0
1.1.2 DRAWBACKS OF CURRENT SYSTEMS
Current systems in test, evaluation, and simulation environments within the automotive
industry have in most cases their own proprietary formats to store data. These formats
usually are very different from each other regarding the description of the configuration (unit
under test, test sequence, test equipment, etc.) as well as the way results are stored
(database, binary files, etc.).
View of the users:
Installations have grown during the past decades. Providers of the early days were replaced
by others, each new one bringing in a new storage philosophy and another incompatible
format. Accessing data from such a diversity of systems results in the need for a large variety
of interface adaptors and converters - most of them individually developed or extended for
each new project. The increasing complexity of the underlying systems causes expensive,
specialized, isolated, and thus increasingly uneconomical solutions.
This is contradictory to the general desire within the automotive industry to develop and use
easily manageable applications, which provide valuable information to other departments
and systems within the company and to suppliers.
Additionally, even if alternative providers offer technically advanced systems, they often
cannot be taken into account because of the amount of follow-up work required to link the
already existing systems to them.
View of the providers:
Since each customer has built up a specific variety of systems, and interaction with these
systems is usually strongly required with each new product being introduced, much of the
development work of a new product is spent to become compatible. And not only the amount
of work spent but also the knowledge required (and mostly gained through experience) is a
critical issue. Thus the capability to connect into an existing environment often depends on
the availability of specific people.
Moreover different customers require a different interaction scenario. Product releases
become customer specific, version control becomes a major job.
New companies trying to contribute new ideas and solutions hardly have a chance to place
any product; either they invest a lot into the connectivity issues or they will always play a
minor role. This inhibits innovation in the automotive industry and finally jeopardizes
competitiveness.
1-6 ASAM ODS VERSION 5.0
8 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
1.1.3 BENEFITS OF ASAM ODS
The main objectives for a standardization of data access interfaces are to reduce costs and
risks within projects, and to provide a reliable basis for implementations in the area of data
storage and data usage. Using standardized interfaces and common structures minimizes
the efforts for the system integration within the heterogeneous environments discussed
above and makes it much easier to exchange data.
To overcome the mentioned problems ASAM ODS provides:
¾ A common data model (base model) for the
unambiguous and complete storage of data. This
Application
base model can be viewed as a rough data
classification, thereby adding semantics to the
data, which finally allows different systems to
ASAM ODS
interpret same data in the same way. The data
model covers the needs of a multitude of
Data Model
application areas and is adaptable to individual
Application Interfaces
requirements of a specific system or even project
by building a so called ‘application model’ from
Physical Storage
the base model.
¾ Interfaces (Application Programmer's Interfaces, Transport Format
APIs) to access data of ASAM-compatible
systems and tools in a standardized way.
Interfaces (APIs) to create and access a self- Data Storage
explanatory description (meta-information) of the
actual application model. This allows systems to
operate on very different ASAM ODS data.
¾ A database model for the (wide-spread) relational databases. This specifies physical
storage of the data,. It also allows to exchange database files between systems with the
same DBMS. Finally (in case an appropriate ODS server application is not available) it
provides easy access through SQL commands even on different platforms, and between
different DBMSs.
¾ A standardized, easy to use, text-based exchange format (ASAM Transport Format, ATF)
in order to exchange ASAM ODS data (including its meta-information) between different
systems and different platforms. The ASAM ODS Version 5.0 now supports both, the
classic ATF (ATF/CLA) as well as the XML based ATF/XML.
¾ A set of application models that reflect typical scenarios for the use of ASAM ODS and
that easily allow a mapping between data originating from different companies.
Another benefit of such a standardization is its impact on product quality. The standards
specified will allow to measure products’ implementations. Certification procedures are
defined, another way to check the interoperability of products is to do crosstests, which were
already undergone with very good results. Both approaches shall lead to product conformity
with the standards.
Finally ASAM ODS provides the opportunity to integrate data of the whole lifecycle of
automotive products. Though the kind of relevant information in the areas research,
development, production, and after-sales are very different from each other, ODS allows to
store them (each with their specific application models) and retrieve them, thereby keeping
the meaning of the data items. And the ODS interfaces allow tools to combine information
from each of those areas, analyze dependencies, generate overall reports etc.
ASAM ODS VERSION 5.0 1-7
ASAM ODS VERSION 5.0
1.2 TECHNICAL APPROACH
ASAM ODS standardizes data access regarding five important aspects:
¾ The data model
¾ The interfaces
¾ The physical storage
¾ The transport formats
¾ Application Models
1.2.1 THE DATA MODEL
The first and most important aspect of ASAM ODS is its data model.
Typically there are different levels to exchange a data item.
¾ Two systems or software packages might not be able to exchange this data item at all.
This is the case if e.g. system A expects the data item to be represented as a 4-byte
floating point number while system B expects it to be represented by a 2-byte integer
value.
The drawback is obvious: no automatic data exchange can be set up without changing
either of the systems (that is: its software).
¾ Two systems or software packages may be able to exchange this data item as a number
because the data representation of the item is the same on both systems. This capability
often is the result of some standardization effort, specifying universal data formats. An
example is the wide-spread CSV (comma separated values) format, where data items
are represented by an ASCII string, and consecutive data items are separated from each
other by a comma. System A may produce such a CSV file and system B may be able to
read it and know about the numbers contained in it.
The drawback is still obvious: without additional knowledge about the meaning of the
data item its value is quite useless.
¾ Similarly two systems or software packages may be able to exchange this data item as a
number with a name e.g. because a common database is used. In this case system A
stores the value of the data item in some place in a table, using a row and/or column
name; this is typically done through some database interfaces. System B may now use
the same database interfaces, identify the data item by its name and/or location in the
table and thus get back its value.
The drawback is not very obvious; it seems that the data item is fully described by (i) its
value and (ii) its name. However, its value is only useful if the retrieving system B knows
about the meaning of the data item’s name. This requires additional conventions on
naming of data items. And questions like “What unit belongs to the value?”, “Is this the
most recent of a set of available values for the data item?” etc. still remain open.
¾ Some data exchange solutions overcome this drawback by specifying everything.
Examples can be found looking at some serial interface protocol specifications or at
some quite fixed database models. Though this provides a maximum of information
provision, such solutions proved to be very inflexible and are tailored to the needs of one
specific task.
1-8 ASAM ODS VERSION 5.0
10 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
ASAM ODS headed for an optimum compromise.
On the one hand the specifications shall be applicable to a variety of application areas. Data
gathered from small vehicle parts shall be accessible in the same way as those of complete
vehicles. Data taken in overseas shall be available together with on-site data (regardless of
the language, unit schemes, etc.). Data from research projects as well as from production
processes or even after-sales information shall be exchangeable. All systems involved in any
of those steps shall be able to store and retrieve data based on the ASAM ODS data model.
And, since large amounts of data already are existing all over the companies, ASAM ODS
should provide some means to integrate them into the new approach.
On the other hand the information stored shall still be valuable and contain enough meaning
to allow some automatic retrieval and data analysis. There should be a relation between a
data value (the number) and a corresponding unit in order to know about the real physical
value. There should be a relation between the data item and the vehicle or part where it was
taken, and with what equipment it has been taken, and who has taken it, and so on.
This finally led to the current data model of ASAM ODS. It distinguishes between a so called
‘base model’ and an ‘application model’.
The base model is a set of defined base elements and a set of base relations between them.
Each base element represents a type of information. E.g. ‘AoUnit’ is the base element that
represents information on a physical unit (like Newton, Kelvin,.), ‘AoMeasurementQuantity’
is the base element that represents information on a measured physical quantity (like force,
temperature,.), and so on.
Each base relation represents a link with a specific meaning between two such base
elements. E.g. AoMeasurementQuantity and AoUnit are linked together and the relation tells
which of all possible units is the current unit of that quantity.
The base model is unique for all kinds of applications that use ASAM ODS.
The application model is application specific. A test system for wind tube tests may have a
different application model than a system running engine endurance tests.
The application model specifies which elements are really in use by the application. For
example, an engine test shall measure a temperature, a pressure, and a force and will use
the SI units Kelvin, Pascal, and Newton. These six instances are quantities going to be
measured (thus belong to the base element AoMeasurementQuantity) or units (thus belong
to the base element AoUnit). Each of them is an individual application element (derived from
the corresponding base element), and there is a relation between each such quantity used
and an appropriate unit.
Though each application may have its own application model, all application elements in that
model know of which base element type they are. And any software accessing such an
application element knows more about it than just name and value: it knows the type of
information this element carries, it knows in which unit its values currently are expressed and
so on.
The data model is explained in more detail in section 1.5.
ASAM ODS VERSION 5.0 1-9
ASAM ODS VERSION 5.0
1.2.2 THE INTERFACES
The second aspect of ASAM ODS is its set of interfaces.
It is obvious that storing and retrieving information needs some kind of physical storage
medium (like a disk, a tape, etc.). Again, there are different levels to store/retrieve
information.
Usually there is an operating system which provides a basic interface to read and write single
data items to/from files on the storage medium. This is a quite low level of interface, which
requires that each single byte within that file is uniquely specified. Otherwise, though system
A could write its information to file in some way, system B would probably not be able to read
it back. Besides the huge amount of specification work required, there is still a big chance
that system implementers will misunderstand or misinterpret the specifications and produce
incompatible files, especially if there are dependencies between data items in the files.
A more convenient way is to use a DBMS (database management system) and to store the
information in a database. Today, relational databases are quite wide-spread, and access to
the contained information can be gained by using the standardized SQL (structured query
language) interface provided by the DBMS. In this case applications don’t have to care for
the exact file representation of their data; they just use the SQL-commands to store and
retrieve data items, and the DBMS takes care for that a data item stored by system A can be
retrieved by system B.
Data in relational databases are organized in tables which may be related to each other.
Thus specification work has to concentrate on specifying the tables and their relationships.
ASAM ODS has done so (see the ‘physical storage’ description below).
However a drawback of a solely database oriented standard is that all preexisting data not
contained in databases will not be accessible as ASAM ODS data unless they are
converted/imported into a database.
Another drawback is that a DBMS will never know about ASAM ODS specific aspects and
thus cannot guarantee consistency of the database contents regarding ASAM ODS criteria.
Additionally DBMSs typically require some amount of administrative work (and adequate
personnel) and involve license fees. This may become a problem for some small scale
application areas.
The most promising solution is to provide a specific interface standard that is closely coupled
with the ASAM ODS data model specification. An interface separates a client application
from a server application. The server application holds and organizes
the data; the client application stores or retrieves the data. If the
Client
interface considers the ASAM ODS specific characteristics, one can
Application
expect an optimal co-operation between clients and servers.
This is the concept ASAM ODS has adopted.
interface
The server provides interfaces to store or retrieve data.
The client may use these interfaces. The way a server internally stores
Server
the data persistently is completely up to him. The quality of the server
implementation will influence its behavior regarding performance, Application
overall data amount, simultaneous access from several clients, and
others.
Due to the complete encapsulation of the data store, the server application may decide to
use a relational or object oriented database for persistent storage. Alternatively, just a flat file
storage system may be used, if this seems more appropriate for the intended application
1-10 ASAM ODS VERSION 5.0
12 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
area; clients will not recognize any differences in functionality. Moreover this encapsulation
allows to build server applications which can access preexisting data (in whatever storage
format) and present them to any client application as if they were proper ASAM ODS data.
Version 5.0 of the ASAM ODS standard includes two different types of interfaces:
¾ a procedural interface based on the RPC technology and further on referenced as the
RPC-API.
¾ an object-oriented interface further on referenced as the OO-API. This is currently based
on the CORBA architecture but may in the future be expanded to other technologies.
The RPC-API will still be supported by ASAM ODS in the future, though it currently is frozen;
no further revisions of that API are expected to come up.
The interfaces are explained in more detail in section 1.6.
1.2.3 THE PHYSICAL STORAGE
The third aspect of ASAM ODS is the specification of a format for physical storage.
Originally several different physical storage formats were intended to be specified: one for
(relational) database oriented storage, one for storage using a set of individual files (‘flat-
file’), one for a so-called ‘mixed mode’, where mass data reside in files while descriptive data
are contained in a database.
Up to now ASAM ODS has specified how a relational database should internally be
constructed to store information in ASAM ODS compatible way. This includes defining which
tables must be set up, what information they have to keep, which columns are keys (and thus
have to be unique) and so on.
It is not really necessary to specify a physical storage format, to come to a standardized data
storage concept.
Moreover, the major benefits from the ASAM ODS standards can be achieved by just
implementing the data model and the interfaces, without regarding any specifications on
physical storage formats (products will still seamlessly interact).
However specification of such a physical storage format provides some benefits.
¾ First of all, if different server applications use the same DBMS on the same platform, and
their data have to be exchanged, the database files may directly be copied. No time
consuming export-import procedures are required to transfer the data from one server
application to the other.
¾ Additionally regular SQL-based tools (browsers, analyzers, report generators) may be
used to access the data, bypassing the server application. Such tools are available from
a variety of vendors, are often easy to handle, not very expensive, and sometimes the
existing staff is already familiar with their usage. Though there is no ASAM ODS specific
interpretation of the data available, such tools may be sufficient (especially for simple
tasks); in this case no ASAM ODS server application needs to be licensed and installed.
¾ Finally the ODS-server itself may be exchanged without loss of data or the need to export
the data out of the original server and import them into the new one again.
The physical storage is explained in more detail in section 1.7.
ASAM ODS VERSION 5.0 1-11
ASAM ODS VERSION 5.0
1.2.4 THE ASAM TRANSPORT FORMATS (ATF)
The fourth aspect of ASAM ODS is the specification of a transport format, the so called
‘ASAM Transport Format’ ATF. It is intended to be usable on all available platforms and
operating systems and shall allow data transfer between different systems without loosing
any information.
Since there is hardly a system or platform where plain ASCII text is not available as
information representation, ASAM ODS decided to specify the ATF based on ASCII text. The
specified syntax allows to carry all information of the data model.
ASAM ODS transport format files may become quite large due to their ASCII nature;
therefore the specification allows to separate the complete information into several single
ASCII files and moreover allows to place mass data into separate binary files whose internal
structures then are described within the ASCII file.
It is expected that ASAM ODS server applications will allow to import ATF files and to export
all or part of their information into ATF files. This applies also to ASAM ODS clients using the
API to import and export ATF files.
The ATF will typically be used to transfer e.g. measured data from a stand-alone in-vehicle
measurement system to the department’s ODS server, or to transfer parts of an ODS server
(or its whole content) from one platform to another, in case there is no CORBA-capable
network connection available. Because it is ASCII-text, the ATF can also be used to
manually analyze or modify specific data items.
Another benefit of the ATF is that it can easily be created by any application. There is no
need to know about CORBA or RPC nor to have experience with software interfaces or data-
bases. Thus it may be a first and easy step for any product to become ASAM ODS
compatible.
Version 5.0 of the ASAM ODS standard includes two different transport formats:
¾ the first one specified is the so-called classic ASAM transport format (ATF/CLA). It has
been used by servers and clients for years and is a stable and reliable way for ASCII
based data exchange.
¾ with XML becoming a base language for describing data storage in a huge variety of
application areas, ASAM ODS has now introduced the ATF/XML, an XML based
definition of file contents that allows exchange of data between ASAM ODS compliant
applications.
The ATF/CLA will still be supported by ASAM ODS in the future, though no further revisions
of that ATF type are expected to come up.
The ATF is explained in more detail in section 1.8.
1.2.5 APPLICATION MODELS
The ASAM ODS Version 5.0 now also includes application models to allow implementers to
easily implement application models which are very common. At the time of publishing this
documentation, the following application models are available or under development:
¾ NVH (Noise, Harshness, Vibration)
¾ Calibration Data
¾ VSIM (Vehicle Safety Information Model)
1-12 ASAM ODS VERSION 5.0
14 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
¾ Engine
¾ Emissions
Application models defined up to now are explained in more detail in section 1.9.
ASAM ODS VERSION 5.0 1-13
ASAM ODS VERSION 5.0
1.3 IMPACT ON PRODUCTS
ASAM ODS will influence already existing software-based products which perform
measurement, simulation, and control tasks, or which organize and analyze data or create
reports:
¾ Large automation, data acquisition, or analysis products will be extended to use the ODS
interfaces to connect to an ODS server. They will store their configuration information as
well as the test results using the ODS server.
¾ Data acquisition products with rather small functionality might show up with only an ATF
file as output data; implementing the ASAM ODS interfaces to connect to a server may
be too expensive for them.
¾ Simulation tools may be extended to not only perform simulation based on their internal
stimulation processes but also based on already existing data from previous test; those
may easily and uniquely accessed through the ODS interfaces.
¾ Calibration and optimization packages may combine actual measurement results of a
data acquisition system with results taken in the past and stored in an ODS server
(accessing them through the ODS interfaces). This may help reduce overall time amount
for testing and may increase reusability of data.
¾ Report generators and presentation tools now can access data from any testing
environment in a standardized way through the ODS interfaces and thus more easily. A
comparison of results between tests from different facilities will become available
independent from the equipment that produced the results.
ASAM ODS will provide opportunities for new products:
¾ ASAM ODS server applications will be developed. They may range from small Windows-
NT based solutions for a limited number of similar test cells to large enterprise oriented
systems which will be able to manage data from very different sources. Some may
decide to use a relational database and exactly the specified physical storage format,
others will base on their own proprietary format (using e.g. object oriented databases or
just a set of ‘flat files’)
¾ Data browsers and editors may provide a quick overview over the contents of the ODS
data store. Some may be capable to combine the data of several ODS servers into one
view. Others may only be capable to work with ATF files.
® ®
¾ Connectors between existing universal packages like EXCEL , MATLAB , etc. and the
ODS data store will be offered (e.g. through the use of VBA).
¾ Analysis tools and report generators may come up as CORBA or RPC (software)
components; they are quite lightweight and focus on a specific task, but can be combined
with other components within an adequate framework to build up an individual tool with
exactly the functionality needed.
1-14 ASAM ODS VERSION 5.0
16 © ISO 2005 – All rights reserved

INTRODUCTION TO ASAM ODS
1.4 TECHNOLOGICAL LEVEL FOR IMPLEMENTATION
Besides good software development skills and the knowledge of the ASAM ODS
specification some key technologies are required to understand and implement ASAM ODS:
¾ The ASAM ODS data model is specified using the STEP EXPRESS syntax. Being
familiar with this syntax is beneficial. Though there is a graphical illustration of the
relationship between ODS elements, which can be understood quite easily, those
diagrams don’t contain all information. Experience with data modeling tools, entity
relationship models etc. is helpful.
¾ The ASAM ODS interfaces use CORBA IDL or the RPC IDL as interface definition
language. To understand the interfaces’ functionality typically requires no extra
knowledge.
To use them as a client requires a CORBA ORB implementation (only needed when
using the OO-API based on CORBA; such an ORB is available from different suppliers),
an ODS server (some are already available from ASAM members) and some experience
with this specific way of working with remote objects and their local proxies.
To implement them as an ODS server is a much more demanding task. It requires
experience with CORBA server implementations, or, in case of the RPC-Interface, with
RPC server implementations.
¾ The currently specified physical storage is based on relational databases. An appropriate
DBMS is required to use it. Additionally, some experience with administration of DBMSs
and experience using SQL should be available.
¾ Implementing an import/export from/to an ATF/CLA file does not require anything
specific. Implementing it with ATF/XML requires knowledge about the XML technology.
ASAM ODS VERSION 5.0 1-15
ASAM ODS VERSION 5.0
1.5 THE ODS DATA MODEL – A DEEPER INSIGHT
This section will give more detailed information on
MOT457 MOT456
the first aspect of the ASAM ODS standard.
Instances
MOT123
However, to implement this standard will require
tq hp
measuring measuring
to study chapters 2 and 4 of the ASAM ODS
Version 5.0 documentation.
The data model of ASAM ODS distinguishes Application Model
between a ‘base model’ and an ‘application
AE_Engines
AE_PowerMaps
model’. Both are describing the structure of the
data stored. Real values are finally stored in
AoMeasurement
instances of application elements. The data model
AoUnitUnderTest
thus is a three-layer model, and an introductory
Base Model
example (without any further discussion) is shown
in the figure. These subjec
...