IEC 62243 (IEEE Std 1232) Artificial Intelligence Exchange and Service Tie to All Test Environments (AI ESTATE) IEC 62243 Edition 2 0 2012 06 INTERNATIONAL STANDARD Artificial Intelligence Exchange an[.]
Overview
Scope
The AI-ESTATE standard establishes formal specifications that facilitate system diagnosis by enabling the exchange and processing of diagnostic information, as well as the management of diagnostic processes These processes encompass various activities, including testability analysis, diagnosability assessment, diagnostic reasoning, maintenance support, and the maturation of diagnostics.
Purpose
The AI-ESTATE standard establishes clear formal models for diagnostic information, facilitating unambiguous access to the data that underpins system testing and diagnosis It outlines specific formal information models and software services tailored for various types of diagnostic reasoners.
1 Information on references can be found in Clause 2
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
The goal is to deliver clear and precise definitions of diagnostic knowledge while outlining software exchange and service interfaces that align with contemporary practices in test and diagnostic systems, such as the implementation of eXtensible Markup Language (XML) and web services.
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 represented as EXPRESS schemas, while exchange files contain instances of these schemas for specific diagnostic models It is important to distinguish between "information model" and "diagnostic model," as they use the term "model" in different contexts To clarify this distinction, this document will refer to information models as EXPRESS schemas and to the instances of a schema related to a diagnostic model as instances, such as the 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 in an EXPRESS schema is detailed in its own subclause, organized alphabetically by constants, types, enumerated types, select types, entities, and functions The structure starts with the EXPRESS specification, followed by a description of each entity's attributes under the attribute definition heading Any specified constraints are outlined under the formal propositions heading.
This standard incorporates the vocabulary and definitions from pertinent IEEE standards In cases of conflict between this standard and related standards, such as IEEE Std 1636 TM -2009, the provisions of this standard will prevail for the information produced Additionally, if there is any discrepancy between the models and the AI-ESTATE definitions outlined in Clause 3, the lexical definitions of the models will take precedence.
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.
Normative references
The referenced documents are essential for understanding and applying this document, and each is cited with an explanation of its relevance For dated references, only the specified edition is applicable, while for undated references, the most recent edition, including any amendments or corrections, is to be used.
Internet Engineering Task Force (IETF) RFC 2396 (August 1998), Uniform Resource Identifiers (URI):
2 The numbers in brackets correspond to those of the bibliography in Annex A
3 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)
4 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
ISO 10303-11:1994 Industrial Automation Systems and Integration—Product Data Representation and
Exchange—Part 11: The EXPRESS Language Reference Manual 5
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-28:2007 Industrial Automation Systems and Integraion—Product Data Representation and
Exchange—Part 28: XML Representation of EXPRESS Schemas and Data using XML Schemas.
Definitions, acronyms, and abbreviations
Definitions
For the purposes of this document, the following terms and definitions apply The IEEE Standards
For terms not defined in this clause, please refer to the Dictionary: Glossary of Terms & Definitions An ambiguity group refers to a collection of diagnoses that cannot be differentiated based on the available test outcomes A diagnostic reasoner is a system that utilizes a knowledge base to draw conclusions Additionally, a diagnostic strategy encompasses two aspects: (A) the method of combining factors such as constraints and goals to identify faults within a system, and (B) the evaluation approach used to achieve a diagnostic result.
The EXPRESS schema defines data types, structural constraints, and algorithmic rules relevant to a specific domain In contrast, an XML schema specifies the structure and content constraints of XML documents, extending beyond basic XML syntax Fault isolation involves narrowing down ambiguous diagnoses to facilitate appropriate corrective actions An information model outlines a set of objects within a domain, ensuring clear communication through schemata that detail objects, their relationships, and associated constraints An instance refers to a specific realization of a schema or schema element Lastly, interoperability is the capability of multiple systems to exchange and effectively utilize shared information.
5 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/)
6 The IEEE Standards Dictionary: Glossary of Terms & Definitions is available at http://shop.ieee.org/
The knowledge base comprises a collection of data, including its semantics and relationships, along with functions utilized by diagnostic reasoners Additionally, the native format refers to data that is generated or utilized by a 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).
Acronyms and abbreviations
AI-ESTATE Artificial Intelligence Exchange and Service Tie to All Test Environments
Description of AI-ESTATE
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 emphasizes two key elements of its mission: the necessity for data and knowledge exchange among compliant diagnostic reasoners, achieved through the use of interchangeable files, and the requirement for these reasoners to effectively interact and interoperate with other components within a testing environment.
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
Figure 1 —AI-ESTATE architectural concept
AI-ESTATE conformant systems offer services to various functional components within a test environment These systems may encompass a range of reasoners, including diagnostic systems, test sequencers, maintenance data feedback analyzers, intelligent user interfaces, and advanced 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 enable the exchange of knowledge bases between diagnostic reasoners without requiring an information management system This standard promotes the use of uniform representations of diagnostic data and knowledge within AI-ESTATE compliant diagnostic reasoners A structured framework has been developed for specifying data and knowledge in these domains, with the Common Element Model (CEM) at the top level, which outlines elements common to the AI-ESTATE domain of equipment testing and diagnosis Key constructs within this model include Diagnosis, which refers to diagnostic conclusions about the system under test, and 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
Figure 2 —Hierarchical structure of the AI-ESTATE models
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
Below the Common Element Model in Figure 2 is a set of data and knowledge models (i.e., the Bayesian
The article discusses various models, including the Network Model (BNM), Diagnostics Logistic Model (DLM), Dmatrix Inference Model (DIM), and Fault Tree Model (FTM), which adapt the constructs of the Common Element Model (CEM) to meet specific application reasoning needs The CEM is designed to allow other data and knowledge specification formats to use its constructs as foundational elements tailored to individual application requirements Additionally, the Dynamic Context Model (DCM) interacts with the CEM rather than specializing in it, defining entities that represent the context and history of the reasoning process and establishing the interface for information exchange.
AI-ESTATE's models and services operate on four levels of abstraction concerning the definition and application of information in diagnostic contexts These levels include a definition, which specifies an entity or concept within the AI-ESTATE domain, encapsulating all relevant information that defines that entity or concept.
AI-ESTATE defines the concept of a “Test” as an entity definition in the Common Element
A model represents a conceptual framework, while an instance is a static realization of that model, such as a specific test defined within a diagnostic application, including its name, description, and possible outcomes An occurrence refers to the dynamic realization of an instance over time, containing all necessary information to evaluate the instance's validity at a given moment; for instance, when a series of tests is scheduled, they are said to "occur" within a defined timeline Lastly, an execution serves as a historical record of the information gathered from occurrences over time, capturing specific details about the performance and results of tests as they are conducted.
The AI-ESTATE architecture defines information through the models outlined in Clause 6 Diagnostic models that adhere to these specifications serve as instances of the defined information models These instances represent the model entities present in the application state flow.
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
The standard delineates the software services offered by an AI-ESTATE compliant diagnostic reasoner, as shown in Figure 3 These services are defined in relation to the entities and attributes of the information models, forming the diagnostic reasoner interface Figure 2 illustrates that each element interfacing with the reasoner will offer its own set of services to other system components, although the specifics of those service definitions are not covered in this document.
12 32 I n te rf ac e (s er vi ces )
Figure 3 —AI-ESTATE interface layer
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
Service definitions encapsulate the reasoner, concealing implementation details from diagnostic system clients These services represent a common behavior shared by all diagnostic reasoners, irrespective of their underlying implementations This encapsulation mechanism enables the interchangeability of AI ESTATE conformant diagnostic reasoners within a system.
A reasoner implementation must include a status indicator in response to any service request outlined in this specification The Diagnostic Reasoner is required to deliver the services specified by this standard to clients, and it is important to note that it will utilize only a single model during each session.
Binding strategy
The binding strategy aims to assist software developers in creating a binding layer that provides an interface aligned with the AI-ESTATE services defined in this standard This layer will effectively shield the application and the diagnostic reasoner from any non-AI-related complexities.
ESTATE details such as connectivity technology, memory management, etc
The AI-ESTATE software system comprises two essential components: an application and a diagnostic reasoner The diagnostic reasoner will feature a standard-compliant interface, while the application will utilize AI-ESTATE services through calls to this interface as required.
Each AI-ESTATE service will have a corresponding function in the binding layer, written in the implementation language The function interfaces must closely match the service interfaces they represent, while keeping other details hidden from the client The binding layer will provide data type definitions as specified in this standard Although this standard does not define bindings for every implementation language, it offers guidance for services regarding data passing and returning.
Component implementations should use messages in their native format
Object-oriented implementations should use objects
Procedural implementations should use structures
Other implementations should use XML entities defined by Part 28 schemas
Application and diagnostic reasoner programs can be developed in various programming languages, provided that the translation between them is managed transparently at the binding layer or lower It is advisable to include documentation that traces the elements of the interface back to the services outlined in the standard when publishing the interface.
For example, consider the initializeDiagnosticProcess service as specified in EXPRESS:
FUNCTION initializeDiagnosticProcess( itemID : Identifier, repairItemName : NameType) : NameType;
It has the name initializeDiagnosticProcess, accepts two arguments, one of type Identifier and one of
NameType, and returns a NameType The declaration of a corresponding binding function written in C would be:
NameType initializeDiagnosticProcess (Identifier itemID, NameType repairItemName);
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
This might exist in a C header file and would provide the client code with an interface corresponding exactly to that of the EXPRESS form For example,
NameType initializeDiagnosticProcess (Identifier itemID, NameType repairItemName)
The following C data types could be defined to correspond to the AI-ESTATE types: typedef char* NameType; typedef char* Identifier;
In pure object-oriented languages like Java, interfaces must be represented as methods within objects It is recommended to utilize the information model as a foundation for constructing the class hierarchy.
AI-ESTATE usage
Interchange format
AI-ESTATE models are designed to enable seamless data interchange for testing and diagnosis This interchange format allows for the exchange of diagnostic models in a neutral format, ensuring the portability of diagnostic knowledge across various applications Two specific interchange formats are defined by AI-ESTATE.
AI-ESTATE exchange files that use the ISO 10303-21 format shall adhere to ISO 10303-21:1994
The exchange file must specify the ISO version of ISO 10303-21:1994 and the conformance class "1" (internal mapping) in its header, following the syntax outlined by ISO 10303-21:1994.
AI-ESTATE exchange files in the ISO 10303-21 format shall meet the “schema conformance” requirements specified in ISO 10303-21:1994 Schema conformance shall be with respect to one of the AI-
The estate exchange schemas outlined in section 5.3.2 serve as the governing schema for the file Furthermore, the data contained within the exchange file must comply with the semantic definitions and requirements established for the governing schema as detailed in Clause 6.
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
An AI-ESTATE exchange file must adhere to a specific AI-ESTATE schema, containing all data within a single DATA section The data must represent a "valid population" for the schema, meaning that it is not permissible to combine data from different schemas into one exchange file or to distribute exchange data across multiple files.
The header of the exchange file shall also identify the unique object identifier of the governing AI-
The ESTATE schema follows the syntax outlined in ISO 10303-21:1994, with Annex E detailing the globally unique object identifiers assigned to exchange schemas in the current version of AI-ESTATE These object identifiers provide a clear and unambiguous identification of the governing AI-ESTATE schema and its version.
AI-ESTATE exchange files that use the ISO 10303-28 format shall use the version: ISO 10303-28:2007
ISO 10303-28:2007 offers significant flexibility in data mapping for exchange files, ensuring compatibility with the ISO 10303-21 exchange format.
ISO 10303-28 format shall adhere to the following constraints:
AI-ESTATE exchange files in the ISO 10303-28 format shall meet the “iso-10303-28 document” conformance class requirements defined in ISO 10303-28:2007
Using the syntax prescribed in ISO 10303-28:2007, the exchange file shall specify exactly one
AI-ESTATE EXPRESS schema that governs all of the data in the file
Using the syntax prescribed in ISO 10303-28:2007, the exchange file shall indicate that the entity of data in the file constitutes a “valid population” for the governing AI-ESTATE schema
The file shall not contain data that is not in the population No subset of the population shall be external to the file
The exchange file shall contain exactly one “substitute unit of serialization (UOS) element” that contains all the data that are being exchanged
The data in the substitute UOS element shall adhere to the “default mapping” from EXPRESS to
The data in the ISO 10303-28 formatted exchange file shall be governed by one of the AI-ESTATE
The EXPRESS exchange schemas outlined in Clause 6 serve as the governing schema, and the data within the exchange file must comply with the semantic definitions and requirements established for this schema.
AI-ESTATE exchange files in the ISO 10303-28 format must specify the target namespace for the data using the syntax outlined in ISO 10303-28:2007 This target namespace must align with the governing AI-ESTATE schema, which is clearly identified in Annex F, listing the assigned namespaces The namespace serves to unambiguously identify the relevant AI-ESTATE schema and its version.
ISO 10303-28:2007 mandates XML validation against a "derived XML schema," which is created from the governing AI-ESTATE EXPRESS schema following specific rules outlined in the standard.
XML schemas for AI-ESTATE can be accessed online, but the specific URL is currently returning a 403 Forbidden error Users have the option to create a derived XML schema by utilizing the default mapping rules outlined in ISO 10303-28:2007 It is important to note that these derived schemas will import several XML schemas defined in the ISO 10303-28:2007 standard, which are not available for download from the IEEE site.
Published by IEC under license from IEEE © 2010 IEEE All rights reserved.
Extensibility
Users of AI-ESTATE can use native formats that include additional information beyond the standard specifications and can convert their native model formats to the standard AI-ESTATE format for compliant exchange If extensions are shared, an EXPRESS schema will define these extensions, which must build upon the existing AI-ESTATE schema without redefining established concepts Any extensions to AI-ESTATE model entities or newly defined entities will not be considered compliant with the standard.
Applications can offer additional services beyond the defined standards, but they must comply with the status codes outlined in section 7.2 However, these extra services will not be considered compliant with the standard.
All implemented extensions must be thoroughly documented, including the relevant EXPRESS schemas This documentation and the schemas should be submitted to the data recipient as well as to the appropriate authorities.
Conformance
This subclause defines the requirements for conformance with this standard for diagnostic reasoner application services as well as exchange model instances
Diagnostic reasoner applications shall be conformant to all required services in Clause 7 Applications shall also document any deviations from conformance for the benefit of interoperability
A conformant diagnostic reasoner must process conformant exchange model instances from at least one of the BNM, DIM, DLM, and FTM, in addition to the CEM It is also required to produce and consume conformant exchange model instances of the DCM as outlined in Clause 6 The reasoner should be capable of handling all necessary and optional model elements, as well as extended model instances that comply with section 5.2, although it may choose to disregard any such extensions The definition of a conformant exchange model instance is provided in section 5.3.2.
A file shall conform as an exchange model instance for this standard if it satisfies all the following conditions:
The data set encoded in the file conforms as specified in ISO 10303-11:1994 to one of the
EXPRESS information models defined within this standard, designated the governing schema for the instance: BNM,DIM, DLM, FTM, or DCM (each of which includes the CEM)
The data set in the file consists of a valid instantiation of a single governing schema (i.e., the data set will validate against the governing schema)
Any extensions represented in the file conform to 5.2
The data set in the file adheres to the semantic definitions of the governing schema
The file is encoded in one of the exchange formats specified in 5.1 per the requirements specified Clause 5
Published by IEC under license from IEEE © 2010 IEEE All rights reserved.
Models
AI_ESTATE_CEM
The AI-ESTATE Common Element Model (CEM) provides a foundational information model that outlines the structure and relationships of systems and tests at a fundamental level It establishes common data types and relationships applicable to all static reasoner models within AI-ESTATE Importantly, the CEM is not an exchange model schema; instead, it serves as a base that other static model information models can import and extend to incorporate the necessary logic for generating diagnostic conclusions Additionally, the CEM schema is integrated into the overall framework.
DCM information model See 6.6 for a description how the CEM plays a role in the DCM
NOTE—One may think of the CEM as the supertype of the static model information models 7
Principal components include system items (which are subtyped as repair items and function items), actions
The common element information model includes subtypes for tests, repairs, diagnoses, faults, and failures, allowing for the specification of cost and failure rate information This model serves as a foundational framework for developing diagnostics models that incorporate additional information.
The CEM serves as a foundational framework rather than an exchange mechanism, as its defined data types are utilized by various other EXPRESS schemas within the standard These common data types facilitate consistency across multiple schemas, highlighting their significance in the overall structure.
CEM defines DiagnosticModel, which is a supertype to all of the technology-specific diagnostic models
A constant is designated for a special diagnosis that indicates the absence of faults This constant is utilized alongside the associated name attribute of the no-fault diagnosis In this context, the outcomes carry distinct meanings compared to the outcome values themselves, where GOOD signifies the absence of issues.
7 Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this standard
The reasoner categorizes fault evidence into five classifications: "CONCLUSIVE" indicates definitive proof of no faults, "BAD" signifies evidence of at least one fault, "CANDIDATE" suggests evidence of no faults but lacks conclusiveness, "NOTKNOWN" reflects negligible or conflicting evidence regarding faults, and "USERDEFINED" remains unspecified for the diagnosis.
The ConfidenceValue type is designed to represent a numeric degree of certainty, ranging from 0 to 1, where 0 indicates complete uncertainty and 1 signifies total certainty The specific use of confidence values varies depending on the implementation.
WHERE range : (0.0 OR(AND(outcomes))
REFERENCE FROM AI_ESTATE_CEM;
Published by IEC under license from IEEE © 2010 IEEE All rights reserved
Entity DiagnosticLogicModel represents the constituents of a generic Diagnostic Logic Model
SUBTYPE OF(DiagnosticModel); inferences : SET [2:?] OF OutcomeInference;
Attribute inferences define the collection of outcome inferences that form the model of the system being tested For a model to be effective, it must include at least two inferences, which correspond to the minimum number of outcomes required for the least number of tests within the model.
Entity Inference determines a collection of outcome inferences based on the assertion of another outcome within the model These outcomes are combined using the andOrRelation attribute, which specifies whether they are ANDed or ORed It is important to note that only test outcomes or diagnosis outcomes can be inferred.
ENTITY Inference; term : SET [1:?] OF Outcome; andOrRelation : BOOLEAN;
INVERSE assertion : OutcomeInference FOR andOrTerms;
WHERE noActionOutcome : SIZEOF(QUERY(tmp 0) OR
EXISTS(SELF.trace[1].availableResources); commonSystem : SELF.modelForDiagnosis.systemUnderTest SELF.diagnosedItem.itemUnderTest;