ISO 22901-3:2018
(Main)Road vehicles — Open diagnostic data exchange (ODX) — Part 3: Fault symptom exchange description (FXD)
Road vehicles — Open diagnostic data exchange (ODX) — Part 3: Fault symptom exchange description (FXD)
ISO 22901-3:2018 specifies machine-readable descriptions of all fault symptom algorithms which are implemented as diagnostic software in an electronic control unit (ECU). The main use case is the standardized data exchange from a function & software supplier to a vehicle manufacturer (VM) in order to enable a tool-based information processing. Based on the FXD content and associated calibration values, several end user documents can be generated such as the "summary sheet" needed as part of the vehicle type approval documentation package or the "repair and maintenance information" (RMI). The expected main benefits of the FXD approach are an overall efficiency improvement as well as an independency of supplier- and VM-specific format handling.
Véhicules routiers — Diagnostic généralisé, échange de données (ODX) — Partie 3: Format d'échange de système de défaut (FXD)
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 22901-3
First edition
2018-02
Road vehicles — Open diagnostic data
exchange (ODX) —
Part 3:
Fault symptom exchange description
(FXD)
Véhicules routiers — Diagnostic généralisé, échange de données
(ODX) —
Partie 3: Format d'échange de système de défaut (FXD)
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Specification release version information . 2
5.1 Specification for FXD XML-Schema release version. 2
6 FXD concept . 2
6.1 Overview . 2
6.2 Traditional workflow . 3
6.3 Raw information . 3
6.3.1 General definition and background . 3
6.3.2 Requirements . 3
6.4 FXD format and example . 4
6.5 Basic concept of FXD . 5
6.5.1 Basic requirements . 5
6.5.2 Formal description of diagnosis algorithms . 5
6.5.3 Value inheritance mechanism to support use cases . 6
6.6 FXD workflow . 7
6.7 FXD workflow example . 8
6.8 Constraints for schema updates . 9
7 FXD use cases .10
7.1 General .10
7.2 UC 1 Delivery of "raw information" by ECU software suppliers .10
7.3 UC 2 – Generation of documentation based on FXD raw information .11
7.3.1 UC 2.1 Generation of OBD summary sheet for vehicle type approval .11
7.3.2 UC 2.2 FXD-based repair and maintenance information .11
8 General properties of FXD elements .12
8.1 Attributes .12
8.1.1 DESC-EXTENT (Content) .13
8.1.2 HREF (Content) .13
8.1.3 ID (Infrastructure) . . .13
8.1.4 ID-REF (Infrastructure) .14
8.1.5 OID (Content).14
8.1.6 OPERATOR (Content) .15
8.1.7 SI (Content) .15
8.1.8 DESC-STATE (Content).15
8.1.9 TI (Infrastructure) .16
8.1.10 VERSION (Content) .16
8.1.11 xml:base (Infrastructure) .16
8.1.12 xml:lang (Infrastructure) .16
8.1.13 xsi:nil (Content) .17
8.1.14 xsi:type (Infrastructure) .17
8.2 Variant coding .17
8.3 Generic selection lists .18
8.4 External document references .18
8.5 Referencing ECU variables and calibration labels .18
8.6 General FXD elements, used for identification and description .18
9 Description of FXD elements .19
9.1 General .19
9.2 ADMIN-DATA .19
9.2.1 General.19
9.2.2 COMPANY-DATA-REF . .19
9.2.3 ECU-FAMILY .19
9.2.4 PROJECT .19
9.2.5 RESOURCES .19
9.2.6 DOC-REVISIONS . . .19
9.3 COMPANY-DATAS .20
9.3.1 General.20
9.3.2 COMPANY-DATA .20
9.4 DATA-DICTIONARY .20
9.4.1 DATA-DECLARATIONS .20
9.4.2 COMPUTATIONS .21
9.4.3 UNIT-SPEC .22
9.5 VARIABLE-DESCRIPTIONS .22
9.5.1 General.22
9.5.2 Element-Id .23
9.5.3 COMPANY-DATA-REF . .23
9.5.4 ECU-FUNCS .23
9.5.5 CONFIGURATION .23
9.5.6 DATA-DECLARATION described by a VARIABLE-DESCRIPTION .23
9.5.7 SIMPLE-VARIABLE .23
9.5.8 BIT-FIELD-VARIABLE .23
9.5.9 STATE-GRAPH .24
9.6 FAULT-SYMPTOMS .24
9.6.1 General.24
9.6.2 Element-Id .24
9.6.3 COMPANY-DATA-REF . .25
9.6.4 ECU-FUNCS .25
9.6.5 CONFIGURATION .25
9.6.6 FAULT-IDENTIFICATION .25
9.6.7 MON-COMPONENT or system .26
9.6.8 FAULT-CLASSIFICATION .26
9.6.9 RATIO-GROUPS for in-use monitor performance ratio (IUMPR) .27
9.6.10 READINESS-GROUP .28
9.6.11 FAULT-DETECTIONS .28
9.6.12 CENTRAL-CALIBRATION-INFOS .38
9.6.13 INHIBITIONS information.39
9.6.14 SUBSTITUTION-FUNCTION .41
9.6.15 PROTECTIVE-FUNCTION .41
9.6.16 SIMULATION-METHOD .41
9.6.17 ##other-Information (for symptoms) .42
9.7 FAULT-SYMPTOM-3RD-PARTYS .43
9.8 SERVICE-06-IDS .43
9.9 FIDS .44
9.9.1 General.44
9.9.2 Element-Id .45
9.9.3 FID-TYPE .45
9.9.4 ECU-FUNC .45
9.9.5 FAULT-SYMPTOM-REFS .45
9.9.6 AUXILIARY-OBJECT-REFS .45
9.9.7 EXPLANATION .45
9.10 AUXILIARY-OBJECTS .46
9.11 MASKS .46
9.12 TEXT-MAPPINGS.46
9.13 Any Other-Information (for container) .46
Annex A (normative) Digital Annex of FXD XML-Schema.47
iv © ISO 2018 – All rights reserved
Annex B (normative) Digital Annex of FXD Selection Dictionary .76
Annex C (normative) Digital Annex of FXD Rule Set .151
Annex D (informative) Inhibition of fault symptoms .194
Bibliography .198
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
Annex A, B and C of this document are normative and Annex D is for information only.
A list of all the parts in the ISO 22901 series can be found on the ISO website.
vi © ISO 2018 – All rights reserved
Introduction
0.1 Overview
This document has been established in order to define a new format called FXD (Fault symptom
eXchange Description) which has been developed for provision of machine-readable descriptions
of mainly fault symptom algorithms which are implemented as diagnostic software in an Electronic
Control Unit (ECU).
The main business case is the data exchange from a function and software supplier to a vehicle
manufacturer in a standardized format (FXD XML-Schema) in order to enable a tool based processing.
The software supplier will provide software related raw data, which have to be extended and refined by
the vehicle manufacturer for different use cases. Based on the FXD content and associated calibration
values, several end user documents can be generated such as the summary table for OBD documentation.
The expected main benefits of the FXD approach are an overall improved efficiency as well as an
independency of system supplier and vehicle manufacturer-specific format handling.
FXD is an extension of ODX in order to support the documentation and fault symptom data exchange
use cases for type approval and repair and maintenance information (RMI).
A normative annex will include the FXD XML-Schema which represents the data model for the digital
exchange of the FXD data.
0.2 Motivation
The complexity of OBD monitoring systems is continuously evolving. Technological progress and
regulatory updates drive the complexity of both engine systems themselves and the related OBD
monitoring systems. For instance, the number of monitors and thereby also Diagnostic Trouble Codes
(DTC) has considerably increased over time as shown here for a 6-cylinder gasoline application from
calendar year 2000 up to 2012.
In addition to the pure number of monitors, also the OBD monitors themselves have become more and
more sophisticated.
Figure 1 shows the evolving complexity of OBD systems.
Key
1 6-cyl gasoline engine
Figure 1 — Evolving complexity of OBD systems
0.3 Project complexity
Today's project complexity (e.g. variants) at the vehicle manufacturers is also an important aspect
for diagnostic documentation. For all OBD-relevant monitoring strategies, the corresponding OBD
documentation is generated. When these monitors are integrated by often different project teams, they
may need to be specifically adapted and calibrated in order to operate properly in the different projects.
To ensure accurate OBD documentation across all projects, considerable efforts for synchronization
and manual adjustment are necessary. Obviously, this specific approach will provide only a limited
reuse potential.
Figure 2 shows the project complexity and accurate OBD documentation.
Figure 2 — Project complexity and accurate OBD documentation
In addition more complicated business models (multiple job shares across companies) challenge the
OBD documentation process.
In the past, typically one ECU supplier also supplied most of the corresponding software. Nowadays
and even more in future with the Autosar approach, the trend towards software packages from vehicle
manufacturer and 3rd parties will increase.
As a consequence, multiple suppliers provide the information for the generation of OBD documentation
with different format, structure and content. For understanding, it is often necessary to dig into the
details of the complete software documentation itself. This is why the efforts for the integration and
generation of OBD relevant information increases due to manual analysis and adjustment. Obviously
this scenario will allow only a limited reuse.
Figure 3 shows the challenging job share and consistent OBD documentation.
viii © ISO 2018 – All rights reserved
Figure 3 — Job sharing challenge and consistent OBD documentation
Scheduling constraints for generating OBD documentation during the development phase also represent
a motivating factor for the introduction of the FXD approach. As the OBD development has become
more and more extensive, the documentation is established as early as possible, but on the other hand
late changes will cause iterations. Without efficient management of the corresponding OBD-relevant
information, it is nearly impossible to answer to the challenging engineering targets and tight project
schedules of today.
INTERNATIONAL STANDARD ISO 22901-3:2018(E)
Road vehicles — Open diagnostic data exchange (ODX) —
Part 3:
Fault symptom exchange description (FXD)
1 Scope
This document specifies machine-readable descriptions of all fault symptom algorithms which are
implemented as diagnostic software in an electronic control unit (ECU). The main use case is the
standardized data exchange from a function & software supplier to a vehicle manufacturer (VM)
in order to enable a tool-based information processing. Based on the FXD content and associated
calibration values, several end user documents can be generated such as the "summary sheet" needed as
part of the vehicle type approval documentation package or the “repair and maintenance information”
(RMI). The expected main benefits of the FXD approach are an overall efficiency improvement as well
as an independency of supplier- and VM-specific format handling.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification
SAE J1930-DA, Digital Annex of E/E Systems Diagnostic Terms, Definitions, Abbreviations, and Acronyms
SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes
SAE J2012-DA, Digital Annex of E/E Diagnostic Trouble Code Definitions and Failure Type Byte Definitions
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
4 Abbreviated terms
For the purposes of this document, the abbreviated terms given in SAE J1930-DA, SAE J1979-DA and
SAE J2012-DA and the following apply.
a2l ASA P2 description file
AUTOSAR AUTomotive Open System ARchitecture
DCY driving cycle
DTC diagnostic trouble code
ECU electronic control unit
enum enumeration
FCM fault code memory
FID function identifier
FXD Fault symptom eXchange Description
HDO ASAM harmonized data objects
MCL monitoring checklist
MIL malfunction indicator light
OBD on-board diagnostics
OEM original equipment manufacturer
OID object identifier
OSC oxygen storage capacity
RMI repair and maintenance information
SENT single edge nibble transmission
SI système international d'unités
SW software
URI uniform resource identifier
VM vehicle manufacturer
W3C world wide web consortium
XML extended mark-up language
5 Specification release version information
5.1 Specification for FXD XML-Schema release version
The schema specification release version of this document is: 2.0.0.
6 FXD concept
6.1 Overview
The automotive industry specified the requirements for provision of OBD-relevant information and
developed a corresponding concept and format.
The main objectives were:
— Develop a machine-readable automotive format,
— for single source of fault symptom description for different documentation use cases (e.g. type
approval, repair and maintenance information) across project variants;
2 © ISO 2018 – All rights reserved
— for possible data processing utilizing state-of-the-art tooling;
— the use of XML as a base technology for the format definition (FXD XML-Schema);
— the reuse of structural patterns based on ISO 22901-1;
— the naming of structure elements which shall be close to the end user's needs.
6.2 Traditional workflow
Traditionally, the FXD-relevant information is exchanged between vehicle manufacturers and ECU
software suppliers based on proprietary templates and formats.
Even the main FXD use cases "type approval" and "repair and maintenance information" are driven by
different stakeholders and lead to incompatible exchange formats and processes for one and the same
vehicle manufacturer.
The software suppliers have to process the full variety of templates and formats with limited reuse and
a lot of manual interaction.
Finally, the integration and document generation at the vehicle manufacturer's site cannot be automated
due to the non-availability of stable and standardized data formats.
6.3 Raw information
6.3.1 General definition and background
An abstract and structured description of all conditions/criteria/parameters that influence the
monitoring process or strategy. It shall be possible to detect and heal a real fault via test conducted by
using the "raw information" description.
The "raw information" description is a neutral description which is not biased towards any vehicle-
manufacturer-specific end-user documentation.
"Raw information" descriptions will naturally need a subsequent, manual adaptation to reflect the
respective requirements of the vehicle manufacturer, the project and end user documentation. This
manual adaptation is within the responsibility of the vehicle manufacturer, see 6.4.
6.3.2 Requirements
6.3.2.1 General
“Raw information” descriptions shall be designed in a way to enable an automated value analysis when
the relevant calibration labels are entered.
“Raw information” descriptions should refer to the corresponding software implementation. Therefore,
a certain abstraction of software implementation is necessary. Furthermore, formal editing features
have to be used to improve the readability (e.g. logical grouping of conditions / use of headlines where
appropriate). For specific rules, see FXD rules.
The sequence of the fault detection algorithm shall be described by using a formal language. This formal
language shall allow automatic processing of the information like the substitution of physical units,
replacement of variable names (e.g. for different language areas), replacement of calibration labels and
system constants by values, simplification and partial evaluation of expressions. The formal language
shall allow the visualisation of the information for various audiences. It shall optionally be possible to
describe algorithms textually if a formal description is not feasible or not desired.
6.3.2.2 Requirements for generating of raw information descriptions
Detailed requirements are defined in the rules for generation of FXD descriptions as detailed in Annex C.
6.3.2.3 Requirements for readers of "raw information" description
The information provided by the “raw information” description shall enable technically skilled staff
with a general knowledge of vehicles, but no specific knowledge of diagnostics/OBD, to understand the
physical process of the monitor.
Requirements:
— general engine and vehicle knowledge;
— general knowledge of diagnostics and OBD; and
— knowledge of this document (FXD).
The supplier will not assume any responsibility in case this “raw information” is forwarded to further
audiences (e.g. certification authority, aftersales/service). An FXD file as provided by the supplier will
not contain values of referenced calibration labels.
In case information may consist of prescribed values only, respective generic selection lists, will be
provided and maintained by ISO.
6.4 FXD format and example
The main challenges for the FXD XML-Schema lie in meeting the documentation requirements of the
"OBD summary sheet".
In order to enable an automatic publishing process from the FXD format to an "OBD summary sheet", all
relevant information needs to be captured in the FXD format.
The fault symptom is the main structure criterion for the "OBD summary sheet". All fault-symptom-
related information is organized underneath the corresponding node inside the FXD-Schema, which is
called "FAULT-SYMPTOM".
Within the "OBD summary sheet" the most complex information deals with nested algorithmic
expressions for "MALFUNCTION-CRITERIA" and "ENABLE-CONDITIONS". No control structures as
known from programming languages are necessary.
Sample expression:
< greater than…(operator)> < threshold_1(operand)>
< less than…(operator)> < threshold_2(operand)>
The operands and operators have to be marked separately within the XML structure, as both have to be
prepared for specific rendering, e.g. publishing to different table columns.
As the FXD data delivered by the software supplier will contain raw data based on the software
implementation, a refinement concept is necessary to support different use cases. Therefore, the
principle of inheritance is introduced to FXD, i.e. the symptom related raw data can be refined for a
specific use case just by adding refined information characteristics to the FXD data. Later on, the tool
chain will process the use-case-specific characteristics.
The raw data will contain software names for parameters and calibration data labels for e.g. thresholds.
For generating OBD documentation, the software names have to be replaced by an end-user wording
and the calibration data labels have to be replaced by the corresponding values. Both replacement
mechanisms need to be supported by the FXD format.
4 © ISO 2018 – All rights reserved
In addition to the requirements described above, the following content requests were taken into
account to specify the FXD-Schema.
— interlocking matrix;
— management of FXD data at the vehicle manufacturer's site (e.g. ID management, link to function
and software specifications, …); and
— repair and maintenance information (e.g. language attribute).
Figure 4 shows the OBD summary sheet as one main motivation for the FXD format definition.
Figure 4 — OBD summary sheet as one main motivation for the FXD format definition
6.5 Basic concept of FXD
6.5.1 Basic requirements
The modelling of algorithmic expressions is a core part of the FXD-Schema and will be explained more
in detail.
After analysing the content of the OBD summary sheets for algorithmic expressions, the following
requests were captured:
— enable a formal description of nested algorithmic expressions, which are based on the software
implementation;
— enable formal expressions (one operand may be a text string), which cannot be mapped 1:1 to the
software implementation, but are necessary to reduce complexity;
— enable free text for e.g. repair and maintenance information; and
— enable direct re-use of raw information.
6.5.2 Formal description of diagnosis algorithms
For the description of fault-symptom-related conditions, the element COMPUTATION, is introduced.
It can be:
— either a formal expression (ABSTRACT-SYNTAX); or
— an informal description (EXPLANATION).
The ABSTRACT-SYNTAX represents an expression tree, whose nodes may be:
— an operator (or function) OP with its arguments (operands) as child nodes (which might be again an
expression tree);
— a variable COMPU-VAR, which consists of a reference DATA-DECLARATION-REF to an ECU variable,
calibration parameter or system constant;
— a constant COMPU-CONST, which can be one of the following:
— numerical value V;
— string constant VT; or
— boolean value VB.
The meaning of the operator OP is specified by its OPERATOR attribute. The set of valid operators is
not specified in the FXD XML-Schema itself, but as digital Annex A of this document to provide the
possibility to extend it without a schema change or change of the main document.
The EXPLANATION consists of an informal description DESC, providing multiple paragraphs and
some standard XHTML features, and an optional set of references DATA-DECLARATION-REFS to
ECU variable(s), calibration parameter(s) and system constant(s), which allows the declaration of
dependencies on the ECU-data.
Figure 5 shows the COMPUTATION and ABSTRACT-SYNTAX as FXD core elements.
Figure 5 — COMPUTATION and ABSTRACT-SYNTAX as FXD core elements
6.5.3 Value inheritance mechanism to support use cases
Use cases in cluster 3 (see Figure 8) support the possibility to add use-case-specific representations of
fault symptoms to an FXD file. A main use case in focus is the "adaptation" of malfunction criteria (FAULT-
DETECTION-CRITERIA) and secondary parameters (ENABLE-CONDITIONS) by the vehicle manufacturer
to comply with legislative requirements for creating type-approval-related documents. Other use cases
may be representations of fault symptoms in different languages or for specific user groups.
6 © ISO 2018 – All rights reserved
A value inheritance mechanism is used as follows:
For each use case, an additional instance of a fault symptom can be created ("child fault symptom"),
having the same name (SHORT-NAME) as the fault symptom which is derived from ("parent fault
symptom").
Each child fault symptom refers to exactly one parent fault symptom. It is allowed to refer either to a
fault symptom base specified by the supplier or to another existing child fault symptom.
In a child fault symptom, all sub-elements are optional to allow modification of arbitrary parts of the
information of a fault symptom only.
All information, which is not specified in the child fault symptom, will be obtained from its parent
hierarchy.
A child fault symptom shall not define a fault detection with a name (SHORT-NAME) that is not defined
by its parent. A child fault symptom may only redefine inherited fault detections.
Implementation of value inheritance
The value inheritance mechanism applies to the elements FAULT-SYMPTOM and VARIABLE-
DESCRIPTION. These elements have an SI attribute which specifies the use case. The initial FAULT-
SYMPTOM or VARIABLE-DESCRIPTION from which other item descriptions are derived is called “base
fault symptom” or “base variable description. The use case of these base items is “raw-information”
(RAWINFO).
In order to establish value inheritance, a FAULT-SYMPTOM or VARIABLE-DESCRIPTION shall render
a PARENT-REF element. The PARENT-REF refers to the parent item from which the FAULT-SYMPTOM
or VARIABLE-DESCRIPTION wants to inherit. The parent item and the child item shall have the same
SHORT-NAME.
The implementation of FXD value inheritance in XML-Schema makes use of the rather uncommon
technique of derivation by restriction. XML-Schema allows the definition of a type by restricting the
occurrences and contents of elements from the type from which it is derived.
A base symptom or variable description shall provide a minimum of information, specified by the
non-optional elements. Fault symptoms or variable descriptions which make use of the FXD value
inheritance only render elements which they redefine. In the simplest case, a derived fault symptom
does not redefine anything but inherits all properties from its parent or ancestors. In this case the
FAULT-SYMPTOM element would only have three child elements: SHORT-NAME, COMPANY-DATA-REF
and PARENT-REF. Thus, the XML-Schema shall allow all other elements of a derived item to be optional.
The solution is to use XML-Schema mechanism “derivation by restriction” to define a base fault symptom
type (FAULT-SYMPTOM-BASE) and a base variable description type (VARIABLE-DESCRIPTION-BASE).
In the resulting FXD-XML-document, a base element is tagged with the attribute xsi:type="FAULT-
SYMPTOM-BASE" or xsi:type=”VARIABLE-DESCRIPTION-BASE”.
6.6 FXD workflow
By introducing a machine-readable and standardised exchange format for the description of fault
symptoms it is possible to improve the overall workflow.
The variety of formats and templates will be replaced by this document on the ECU software supplier's
side. This will enable a homogeneous tool chain and a reuse of FXD data. The ECU software supplier will
deliver "raw data", i.
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...