Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE)

IEC 62243:2012(E) defines formal specifications for supporting system diagnosis. These specifications support the exchange and processing of diagnostic information and the control of diagnostic processes. Diagnostic processes include, but are not limited to, testability analysis, diagnosability assessment, diagnostic reasoning, maintenance support, and diagnostic maturation.

General Information

Status
Published
Publication Date
20-Jun-2012
Drafting Committee
Current Stage
PPUB - Publication issued
Start Date
21-Jun-2012
Completion Date
31-Mar-2012
Ref Project

Relations

Standard
IEC 62243:2012 - Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE)
English language
160 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


IEC 62243
Edition 2.0 2012-06

IEEE Std 1232
INTERNATIONAL
STANDARD
Artificial Intelligence Exchange and Service Tie to All Test Environments
(AI-ESTATE)
All rights reserved. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of
Electrical and Electronics Engineers, Inc.

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 the IEC Central
Office.
Any questions about IEEE copyright should be addressed to the IEEE. Enquiries about obtaining additional rights to
this publication and other information requests should be addressed to the IEC or your local IEC member National
Committee.
IEC Central Office Institute of Electrical and Electronics Engineers, Inc.
3, rue de Varembé 3 Park Avenue
CH-1211 Geneva 20 New York, NY 10016-5997
Switzerland United States of America
Tel.: +41 22 919 02 11 stds.info@ieee.org
Fax: +41 22 919 03 00 www.ieee.org
info@iec.ch
www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

IEC 62243
Edition 2.0 2012-06
IEEE Std 1232™
INTERNATIONAL
STANDARD
Artificial Intelligence Exchange and Service Tie to All Test Environments

(AI-ESTATE)
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XG
ICS 25.040; 35.060 ISBN 978-2-83220-102-2

– ii – IEEE Std 1232-2010
Contents
1. Overview . 1
1.1 Scope . 2
1.2 Purpose . 2
1.3 Conventions used in this document . 3
1.4 IEEE download site . 3
2. Normative references . 3
3. Definitions, acronyms, and abbreviations. 4
3.1 Definitions . 4
3.2 Acronyms and abbreviations . 5
4. Description of AI-ESTATE . 5
4.1 AI-ESTATE architecture . 5
4.2 Binding strategy . 8
5. AI-ESTATE usage . 9
5.1 Interchange format . 9
5.2 Extensibility . 11
5.3 Conformance . 11
6. Models . 12
6.1 AI_ESTATE_CEM. 12
6.2 AI_ESTATE_BNM . 55
6.3 AI_ESTATE_DIM . 64
6.4 AI_ESTATE_DLM . 68
6.5 AI_ESTATE_FTM . 72
6.6 AI_ESTATE_DCM . 77
7. Reasoner manipulation services . 92
7.1 Service order dependence . 92
7.2 Status codes . 95
7.3 Data types for the reasoner manipulation services . 95
7.4 Required services . 110
7.5 Optional services . 132
Annex A (informative) Bibliography . 136
Annex B (informative) Overview of EXPRESS . 138
Annex C (informative) Overview of ISO 10303-28:2007 . 145
Annex D (informative) Overview of ISO 10303-21:1994 . 152
Annex E (normative) Information object registration . 157
Annex F (normative) Universal resource names for derived XML schemas . 158
Annex G (informative) IEEE List of Participants. 159
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – iii –
Artificial Intelligence Exchange and Service
Tie to All Test Environments (AI-ESTATE)

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization
comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to
promote international co-operation on all questions concerning standardization in the electrical and
electronic fields. To this end and in addition to other activities, IEC publishes International Standards,
Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides
(hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any
IEC National Committee interested in the subject dealt with may participate in this preparatory work.
International, governmental and non-governmental organizations liaising with the IEC also participate in
this preparation.
IEEE Standards documents are developed within IEEE Societies and Standards Coordinating Committees
of the IEEE Standards Association (IEEE-SA) Standards Board. IEEE develops its standards through a
consensus development process, which brings together volunteers representing varied viewpoints and
interests to achieve the final product. Volunteers are not necessarily members of IEEE and serve without
compensation. While IEEE administers the process and establishes rules to promote fairness in the
consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of
any of the information contained in its standards. Use of IEEE Standards documents is wholly voluntary.
IEEE documents are made available for use subject to important notices and legal disclaimers (see
http://standards.ieee.org/IPR/disclaimers.html for more information).
IEC collaborates closely with IEEE in accordance with conditions determined by agreement between the
two organizations.
2) The formal decisions of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees. The formal decisions of IEEE on technical matters, once consensus
within IEEE Societies and Standards Coordinating Committees has been reached, is determined by a
balanced ballot of materially interested parties who indicate interest in reviewing the proposed standard.
Final approval of the IEEE standards document is given by the IEEE Standards Association (IEEE-SA)
Standards Board.
3) IEC/IEEE Publications have the form of recommendations for international use and are accepted by IEC
National Committees/IEEE Societies in that sense. While all reasonable efforts are made to ensure that
the technical content of IEC/IEEE Publications is accurate, IEC or IEEE cannot be held responsible for the
way in which they are used or for any misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
(including IEC/IEEE Publications) transparently to the maximum extent possible in their national and
regional publications. Any divergence between any IEC/IEEE Publication and the corresponding national
or regional publication shall be clearly indicated in the latter.
5) IEC and IEEE do not provide any attestation of conformity. Independent certification bodies provide
conformity assessment services and, in some areas, access to IEC marks of conformity. IEC and IEEE are
not responsible for any services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or IEEE or their directors, employees, servants or agents including
individual experts and members of technical committees and IEC National Committees, or volunteers of
IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA)
Standards Board, for any personal injury, property damage or other damage of any nature whatsoever,
whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication,
use of, or reliance upon, this IEC/IEEE Publication or any other IEC or IEEE Publications.
8) Attention is drawn to the normative references cited in this publication. Use of the referenced publications
is indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that implementation of this IEC/IEEE Publication may require use of
material covered by patent rights. By publication of this standard, no position is taken with respect to the
existence or validity of any patent rights in connection therewith. IEC or IEEE shall not be held
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patent Claims or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– iv – IEEE Std 1232-2010
International Standard IEC 62243/ IEEE Std 1232-2010 has been processed through IEC
technical committee 93: Design automation, under the IEC/IEEE Dual Logo Agreement.
This second edition cancels and replaces the first edition, published in 2005, and
constitutes a technical revision.
The text of this standard is based on the following documents:
IEEE Std FDIS Report on voting
IEEE Std 1232-2010 93/320/FDIS 93/327/RVD

Full information on the voting for the approval of this standard can be found in the report
on voting indicated in the above table.
The IEC Technical Committee and IEEE Technical Committee have decided that the
contents of this publication will remain unchanged until the stability date indicated on the
IEC web site under "http://webstore.iec.ch" in the data related to the specific publication.
At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – v –
TM
IEEE Std 1232 -2010
(Revision of
IEEE Std 1232-2002)
IEEE Standard for Artificial Intelligence
Exchange and Service Tie to All Test
Environments (AI-ESTATE)
Sponsor
IEEE Standards Coordinating Committee 20 on
Test and Diagnosis for Electronic Systems
Approved 8 December 2010
IEEE-SA Standards Board
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– vi – IEEE Std 1232-2010
Abstract: Data interchange and standard software services for test and diagnostic environments
are defined by Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-
ESTATE). The purpose of AI-ESTATE is to standardize interfaces for functional elements of an
intelligent diagnostic reasoner and representations of diagnostic knowledge and data for use by
such diagnostic reasoners. Formal information models are defined to form the basis for a format
to facilitate exchange of persistent diagnostic information between two reasoners and also to
provide a formal typing system for diagnostic services. The services to control a diagnostic
reasoned are defined by this standard.

Keywords: AI-ESTATE, Bayesian Network, diagnosis, diagnostic inference, diagnostic model,
diagnostic services, D-matrix, fault tree, IEEE 1232, knowledge exchange, system test


IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
Engineers, Incorporated.
W3C is a registered trademark of the W3C® (registered in numerous countries) World Wide Web Consortium. Marks of W3C are registered
and held by its host institutions MIT, ERCIM, and Keio.

Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – vii –
IEEE Introduction
This introduction is not part of IEEE Std 1232-2010, IEEE Standard for Artificial Intelligence Exchange and Service
Tie to All Test Environments (AI-ESTATE).
The AI-ESTATE standard provides a formal framework for exchanging diagnostic knowledge and
communicating with diagnostic reasoners. The intent is to provide a standard framework for identifying
required information for diagnosis and defining the diagnostic information in a machine-processable way.
In addition, software interfaces are defined whereby applications can be developed to communicate with
diagnostic reasoners in a consistent and reliable way.
Notice to users
Laws and regulations
Users of these documents should consult all applicable laws and regulations. Compliance with the
provisions of this standard does not imply compliance to any applicable regulatory requirements.
Implementers of the standard are responsible for observing or referring to the applicable regulatory
requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
This document is copyrighted by the IEEE. It is made available for a wide variety of both public and
private uses. These include both use, by reference, in laws and regulations, and use in private self-
regulation, standardization, and the promotion of engineering practices and methods. By making this
document available for use and adoption by public authorities and private users, the IEEE does not waive
any rights in copyright to this document.
Updating of IEEE documents
Users of IEEE standards should be aware that these documents may be superseded at any time by the
issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect. In order to determine whether
a given document is the current edition and whether it has been amended through the issuance of
amendments, corrigenda, or errata, visit the IEEE Standards Association web site at
http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.
For more information about the IEEE Standards Association or the IEEE standards development process,
visit the IEEE-SA web site at http://standards.ieee.org.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– viii – IEEE Std 1232-2010
Errata
Errata, if any, for this and all other standards can be accessed at the following URL:
http://standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL
for errata periodically.
Interpretations
Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/
index.html.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence
or validity of any patent rights in connection therewith. The IEEE is not responsible for identifying
Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity
or scope of Patents Claims or determining whether any licensing terms or conditions provided in
connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable
or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any
patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further
information may be obtained from the IEEE Standards Association.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – 1 –
Artificial Intelligence Exchange and
Service Tie to All Test Environments
(AI-ESTATE)
IMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, or
environmental protection. Implementers of the standard are responsible for determining appropriate
safety, security, environmental, and health practices or regulatory requirements.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading “Important Notice” or “Important Notices and Disclaimers
Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
The Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE) standard was
developed by the Diagnostic and Maintenance Control Subcommittee of the IEEE Standards Coordinating
Committee 20 (SCC20) on Test and Diagnosis for Electronic Systems to serve as a standard for defining
interfaces among diagnostic reasoners and users, test information knowledge bases, and more conventional
databases. In addition to interface standards, the AI-ESTATE standard includes a set of formal data
specifications to facilitate the exchange of system under test related diagnostic information.
One approach to defining the interfaces for a component of a larger system is to model, formally, the
information being passed across the system’s interfaces. Such a model is known as an “information model.”
The purpose of an information model is to identify clearly the objects in a domain of discourse (e.g.,
diagnostics) to enable precise communication about that domain. Such a model comprises objects or
entities, relationships between those objects, and constraints on the objects and their relationships. When
taken together, elements provide a complete, unambiguous, formal representation of the domain of
discourse. In other words, they provide a formal language for communicating about the domain.
Using information models, information exchange can be facilitated in two ways. The first is through a set
of exchange files. Specifically, information can be stored by one application in a file and read by a second
application. The file format is derived directly from the information model and defines the syntax of the
message contained within it. The semantics of the message (i.e., the legal content of the file) is defined by
the semantics of the model. The second means of information exchange is through a set of services defined
for a system component as accessed via the communications backbone. The interface definition for the
component is derived from the information model and defines the syntax of the message. Once again, the
legal content of the message is defined by the semantics of the model.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– 2 – IEEE Std 1232-2010
The semantics of information models are provided in two ways. First, the model itself defines a machine-
readable semantic structure and associated constraints that ensure consistent exchange and processing of
the concepts and relationships of the model elements. Second, human-readable definitions specify the
correct interpretation of the model elements.
This standard describes a set of formal data and knowledge specifications consisting of the logical
representation of devices, their constituents, the failure modes of those constituents, and tests of those
constituents. The data and knowledge specification provides a standard representation of the common data
elements required for system test and diagnosis. This will facilitate portability of test related knowledge
bases for intelligent system test and diagnosis.
The goals of this standard are summarized as follows:
 Incorporate domain specific terminology
 Facilitate portability of diagnostic knowledge
 Enable the consistent exchange and integration of diagnostic capabilities
AI-ESTATE defines key data and knowledge specification formats. No host computer dependence is
contained in the AI-ESTATE standard. Systems that use only these specification formats will be portable.
This does not preclude use of AI-ESTATE interfaces with nonconformant specification formats; however,
such systems may not be portable. A diagnostic model can be moved from one AI-ESTATE
implementation to another by translating it into one of two interchange formats described in the
specification. Another AI-ESTATE implementation can then utilize this information as a complete package
by translating the data and knowledge from the interchange format to its own internal form. The translation
step is not a requirement; an AI-ESTATE implementation may use the interchange format or its own
internal form.
Software specifications defined in this standard provide a consistent means of communicating with
diagnostic reasoners through a well-defined set of services. This supports interoperability of diagnostic
reasoner with other elements of a test environment with no effect on the other elements of the system.
This standard also provides an extension mechanism to allow the inclusion of new diagnostic technology
outside the scope of the Al-ESTATE specification.
An overview of EXPRESS can be found in Annex B. Overviews of the ISO 10303-28:2007 and
ISO 10303-21:1994 exchange formats can be found in Annex C and Annex D, respectively.
1.1 Scope
The AI-ESTATE standard defines formal specifications for supporting system diagnosis. These
specifications support the exchange and processing of diagnostic information and the control of diagnostic
processes. Diagnostic processes include, but are not limited to, testability analysis, diagnosability
assessment, diagnostic reasoning, maintenance support, and diagnostic maturation.
1.2 Purpose
The AI-ESTATE standard provides formal models of diagnostic information to ensure unambiguous access
to an understanding of the information supporting system testing and diagnosis. The standard defines
formal information models and software services specific to several different types of diagnostic reasoners.

Information on references can be found in Clause 2.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – 3 –
The purpose is to provide semantically sound definitions of diagnostic knowledge and to specify software
exchange and service interfaces that are consistent with the state of the practice in modern test and
diagnostic systems (e.g., the use of eXtensible Markup Language [XML] and web services).
1.3 Conventions used in this document
This standard specifies information models, exchange formats, and services using the EXPRESS language
and uses the following conventions in their presentation.
Information models are provided in the form of EXPRESS schemas. Exchange files provide the instances
of those schemas for a particular diagnostic model. Note that “information model” and “diagnostic model”
use the word “model” in subtly different ways. In an attempt to resolve this confusion, in this document,
information models will be referred to as EXPRESS schemas and instances of a schema corresponding to a
diagnostic model will be referred to as instances (e.g., Dynamic Context Part 21 instance).
All specifications in the EXPRESS and XML languages are given in the Courier New type font. The
EXPRESS schemas include comment delimiters “(*” and “*)”.
Each entity of each EXPRESS schema is presented in a separate subclause. Within a schema, subclauses
are listed in alphabetical order by constants, types, enumerated types, select types, entities, and then
functions. The subclause structure begins with the actual EXPRESS specification; then, each attribute of
the entity is described below the attribute definition heading. If any constraints have been specified, these
are described below the formal propositions heading.
This standard uses the vocabulary and definitions of relevant IEEE standards. In the event of conflict
TM
between this standard and a related standard such as IEEE Std 1636 -2009 [B5], the standard as it applies
to the information being produced shall take precedence. In the event of any conflict between the models
and AI-ESTATE definitions (Clause 3), the models’ lexical definitions shall take precedence
1.4 IEEE download site
The schemas and examples that accompany this standard are available on the Internet at
http://standards.ieee.org/downloads/1232/1232-2010.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments or corrigenda) applies.
Internet Engineering Task Force (IETF) RFC 2396 (August 1998), Uniform Resource Identifiers (URI):
3,4
Generic Syntax. [cited 2004-03-15].

The numbers in brackets correspond to those of the bibliography in Annex A.
IETF publications are available from the Internet Engineering Task Force, IETF Secretariat, c/o Association Management Solutions,
LLC (AMS), 48377 Fremont Boulevard, Suite 117, Fremont, CA 94538, USA (http://www.ietf.org).
This reference can be downloaded at http://www.ietf.org/rfc/rfc2396.txt.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– 4 – IEEE Std 1232-2010
ISO 10303-11:1994 Industrial Automation Systems and Integration—Product Data Representation and
Exchange—Part 11: The EXPRESS Language Reference Manual.
ISO 10303-21:1994 Industrial Automation Systems and Integration—Product Data Representation and

Exchange—Part 21: Clear Text Encoding of the Exchange Structure.
ISO 10303-21:1994 Technical Corrigendum 1.
ISO 10303-28:2007 Industrial Automation Systems and Integraion—Product Data Representation and

Exchange—Part 28: XML Representation of EXPRESS Schemas and Data using XML Schemas.
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary: Glossary of Terms & Definitions should be consulted for terms not defined in this clause.
ambiguity group: A set of diagnoses that cannot be distinguished with the given set of test outcomes.
diagnostic reasoner: A system that uses a knowledge base to infer conclusions.
diagnostic strategy: (A) An approach taken to combine factors including constraints, goals and other
considerations to be applied to the localization of faults in a system. (B) The approach taken to evaluate a
system in order to obtain a diagnostic result.
EXPRESS schema: A specification of data types, structural constraints, and algorithmic rules
corresponding to some domain of interest.
eXtensible Markup Language (XML) schema: A specification of a type of XML document typically
expressed in terms of constraints of structure and content of documents of that type, above and beyond the
basic syntactical constraints imposed by XML itself.
fault isolation: The process of reducing the set of diagnoses in ambiguity to a degree sufficient to
undertake an appropriate corrective action.
information model: A specification of a set of objects in a domain of discourse to enable precise and
unambiguous communication about that domain. Such a model consists of one or more schemata, each of
which comprise objects or entities, relationships between those objects, and constraints on the objects and
their relationships.
instance: An occurrence of a realized schema or schema element.
interoperability: The ability of two or more systems or elements to exchange information and to use the
information that has been exchanged.

ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20,
Switzerland/Suisse (http://www.iso.ch/). ISO publications are also available in the United States from the Sales Department, American
National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/).
The IEEE Standards Dictionary: Glossary of Terms & Definitions is available at http://shop.ieee.org/.
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – 5 –
knowledge base: A set of data, data semantics and relationships, and functions used by diagnostic
reasoners.
native format: Data that exist in a format either produced or consumed by some non–AI-ESTATE
diagnostic reasoner.
UOS document: A document that conforms to a single governing EXPRESS schema and follows Part 28’s
default mapping from EXPRESS to eXtensible Markup Language (XML).
3.2 Acronyms and abbreviations
AI-ESTATE Artificial Intelligence Exchange and Service Tie to All Test Environments
BNM Bayesian Network Model
CDF cumulative distrubution function
CEM Common Element Model
DAG directed acyclic graph
DCM Dynamic Context Model
DIM Dmatrix Inference Model
DLM Diagnostic Logic Model
FTM Fault Tree Model
PDF probability distribution function
SCC20 Standards Coordinating Committee 20
UOS unit of serialization
UUT unit under test ®
W3C World Wide Web Consortium
XML eXtensible Markup Language
4. Description of AI-ESTATE
4.1 AI-ESTATE architecture
This standard provides the following:
 An overview of the AI-ESTATE architecture
 A formal definition of diagnostic models for systems under test
 Formal definitions of interchange formats for exchange of diagnostic models
 A formal definition of software services for diagnostic reasoners
AI-ESTATE focuses on two distinct aspects of the stated purpose. The first aspect concerns the need to
exchange data and knowledge between conformant diagnostic reasoners. The approach taken to address this
need is by providing interchangeable files. The second aspect concerns the need for an AI-ESTATE
conformant diagnostic reasoner to interact and interoperate with other elements in a test environment (see
Figure 1).
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

– 6 – IEEE Std 1232-2010
System Information
Support Management
Application System
Communication
Services
Diagnostic Test
Reasoner Environment
Figure 1 —AI-ESTATE architectural concept
Services are provided by AI-ESTATE conformant systems to the other functional elements of a test
environment. Reasoners may include (but are not necessarily limited to) diagnostic systems, test
sequencers, maintenance data feedback analyzers, intelligent user interfaces, and intelligent test programs.
AI-ESTATE specifically focuses on diagnostic reasoners. Thus, services may be provided by a diagnostic
reasoner to the system support application, an information management system, and the test environment.
The reasoner will use services provided by these other systems as required. Note that services provided by
these other systems are not specified by the AI-ESTATE standard.
Data interchange formats are specified to provide a means for exchanging knowledge bases between
diagnostic reasoners without the need to apply an information management system. This standard facilitates
the use of standard representations of diagnostic data and knowledge within the context of an AI-ESTATE
conformant diagnostic reasoner. In specifying data and knowledge for these domains, a structure has been
constructed, as shown in Figure 2. At the top level is the Common Element Model (CEM) that specifies
elements common to the AI-ESTATE domain of equipment test and diagnosis in its entirety. Examples of
common element constructs are Diagnosis (diagnostic conclusions about the system under test), RepairItem
(the physical entity being repaired), Resource, and Test. These constructs are characterized by attributes
such as costs and failure rates, which are also specified in the Common Element Model.
Common
Element
Model
Dynamic
Context
Model
Bayesian Dmatrix
Fault Tree Diagnostic
Network Inference
Model Logic Model
Model Model
Figure 2 —Hierarchical structure of the AI-ESTATE models
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

IEEE Std 1232-2010 – 7 –
Below the Common Element Model in Figure 2 is a set of data and knowledge models (i.e., the Bayesian
Network Model [BNM], the Diagnostics Logistic Model [DLM], the Dmatrix Inference Model [DIM], and
the Fault Tree Model [FTM]) that specialize the constructs in the Common Element Model and tailor the
constructs to the application’s particular reasoning requirements. The Common Element Model has been
specified such that other data and knowledge specification formats can also utilize its constructs as base
elements that are tailored to the particular application’s needs. As indicated by the dotted line in Figure 2,
the Dynamic Context Model (DCM) does not specialize but rather interacts with the CEM. The DCM
defines entities that represent the context and history of the reasoning process and defines the interface by
which that information can be exchanged.
The models and services for AI-ESTATE utilize four levels of abstraction related to the definition and use
of information in a diagnostic application. These four levels are described as follows:
a) A definition is the specification of some entity or concept within the AI-ESTATE domain. A
definition encapsulates all of the information that constitutes an entity or concept. For example,
AI-ESTATE defines the concept of a “Test” as an entity definition in the Common Element
Model.
b) An instance is the static realization of an entity or concept definition. For example, a specific
test used by a diagnostic application may be created in a diagnostic model and includes values
defining the test (e.g., name, description, and the set of available outcomes).
c) An occurrence is the dynamic realization of an instance against a timeline. The occurrence
maintains, within its scope, all of the information necessary to evaluate the instance at the time it
is valid. For example, when a sequence of tests has been specified to be performed, it is said that
the tests in that sequence “occur” in the scope of the corresponding timeline.
d) An execution is a historical trace of the information that has been collected by occurrences over
a period of time. An execution is recorded when the test is actually performed. At that time,
specific information related to the performance and results of the test can be captured.
Within the AI-ESTATE architecture, the information models specified in Clause 6 provide the definition of
the information. Diagnostic models that conform to the specifications in Clause 6 are the instances of these
information models. The instances of the model entities occurring in the application state flow specified in
7.1 correspond to the occurrence of the entities in a diagnostic process. Finally, the record of the occurrence
of these entities collected from services performed in the diagnostic process corresponds to the execution
(or execution trace) of the session. The structure for exporting this execution trace is defined by the DCM
in Clause 6.
As illustrated in Figure 3, this standard also defines the software services to be provided by an AI-ESTATE
conformant diagnostic reasoner. All of the services are defined relative to the entities and attributes of the
information models and comprise the diagnostic reasoner interface. As can be seen in Figure 2, each of the
elements that interface with the reasoner will provide its own set of services to the other system
components, but those service definitions are beyond the scope of this document.
Diagnostic
Application
Reasoner
Figure 3 —AI-ESTATE interface layer
Published by IEC under license from IEEE. © 2010 IEEE. All rights reserved.

1232 Interface (services)
– 8 – IEEE Std 1232-2010
The service definitions encapsulate the reasoner so that the underlying implementation details are hidden
from the diagnostic system clients. Such services encompass an abstraction of that behavior that is common
to all diagnostic reasoners, regardless of implementation details. Therefore, it is the mechanism of
encapsulation that provides for the interchangeability of AI ESTATE conformant diagnostic reasoners
within a system.
A reasoner implementation shall provide, at the least, a status indicator (see 7.2) as a response to any
service request defined by this specification. The Diagnostic Reasoner shall provide the required services
specified by this standard to a client. The diagnostic reasoner shall only utilize a single model during a
session.
4.2 Binding strategy
The intent of the binding strategy is to guide software developers in the creation of a binding layer that will
expose an interface that matches the interface of the AI-ESTATE services as they are specified in this
standard. The binding layer will thus insulate the application and the diagnostic reasoner from any non–AI-
ESTATE details such as connectivity technology, memory management, etc.
An AI-ESTATE software system will consist of at least two components: the application and a diagnostic
reasoner. The diagnostic reasoner will present an interface conformant to this standard; the application will
use AI-ESTATE services as needed by calls to this interface.
For each AI-ESTATE service, there will be a corresponding function in the binding layer that will be
written in the implementation language. The interfaces provided by the functions shall correspond exactly
to the interfaces of the services they implement (or as closely as possible given the constraints of the
implementation language). All other details shall be hidden from the client. This implies that the binding
layer provides data type definitions as specified in this standard. It is beyond the scope of this standard to
define bindings for each implementation language. However, in the interest of interoperability, the standard
provides the following guidance for services passing and returning data:
 Component implementations should use messages in their native format.
 Object-oriented implementations should use objects.
 Procedural impl
...

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...