Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62243, developed jointly as IEEE Std 1232, defines the Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE). This standard provides a formal framework for representing diagnostic knowledge and exchanging diagnostic information between different test and maintenance systems. As modern electronic systems grow increasingly complex — from avionics and automotive electronics to industrial control systems — the need for standardized diagnostic knowledge representation has become critical. AI-ESTATE addresses this challenge by defining a common information model that enables interoperability between different diagnostic reasoners, test executives, and maintenance data collection systems throughout the system lifecycle.
The core of AI-ESTATE is its comprehensive information model, which defines the entities, relationships, and attributes required to represent diagnostic knowledge. The model is organized into several key entity classes that capture different aspects of the test and diagnosis domain. The DiagnosableSystem entity represents the system under test (SUT), including its hierarchical structure, replaceable units, and functional interfaces. The Fault entity models potential failure modes, their causes, effects, and propagation paths through the system. Test entities describe the test procedures, stimulus parameters, measurement thresholds, and expected responses that can be applied to detect and isolate faults. Symptom entities capture observable indications of faults, including operator observations, built-in test (BIT) results, and performance degradation data.
The model also defines DiagnosticReasoner entities that encapsulate the inference engine capabilities. These include the reasoning strategy (model-based reasoning, case-based reasoning, rule-based inference, or Bayesian network inference), the knowledge base format, and the reasoner capabilities. A key design principle is the separation of the diagnostic knowledge from the reasoning engine, allowing different reasoners to operate on the same knowledge base or the same reasoner to work with different knowledge bases. This decoupling is achieved through standardized service interfaces that mediate all interactions between the diagnostic reasoner and the external environment.
| Entity Class | Description | Example Attributes |
|---|---|---|
| DiagnosableSystem | System under test with hierarchical structure | SystemID, systemName, systemLevel, replaceableUnits, functionalInterfaces |
| Fault | Potential failure mode with cause-effect relationships | FaultID, faultName, faultDescription, failureRate, propagationPaths, detectionMethods |
| Test | Test procedure or diagnostic step | TestID, testType, stimulusParameters, thresholds, expectedResponse, testDuration |
| Symptom | Observable indication of a fault condition | SymptomID, symptomDescription, severityLevel, onsetMode (intermittent/persistent), observability |
| DiagnosticResult | Outcome of a diagnostic reasoning session | ResultID, diagnosisTimestamp, inferredFaults, confidenceValues, recommendedActions, repairHistory |
| Session | Context for a diagnostic interaction session | SessionID, startTime, operatorID, systemConfiguration, environmentalConditions |
AI-ESTATE defines three primary service interfaces that standardize the interaction between system components. The Reasoner Service provides operations for loading a knowledge base, initiating diagnostic reasoning, retrieving results, and querying reasoner capabilities. The Result Service enables access to diagnostic results, including concluded faults, confidence levels, recommended repair actions, and supporting evidence. The Session Service manages diagnostic sessions, including session creation, suspension, resumption, and termination, as well as audit trail generation for traceability. Each service is specified using the Interface Definition Language (IDL) paradigm, making them implementable across different computing platforms and communication protocols.
Knowledge exchange in AI-ESTATE is facilitated through standardized data interchange formats. The standard defines both the physical file format (using the STEP physical file format defined in ISO 10303-21) and an in-memory representation that service implementations must support. This dual approach allows knowledge bases to be exchanged as files between organizations while also enabling efficient runtime access through the service interfaces. The information model is extensible through the EXPRESS schema mechanism, allowing domain-specific extensions for particular industries — for example, an avionics extension might add specific fault models for flight control computers, while an automotive extension might add diagnostic trouble code (DTC) mappings aligned with SAE J2012 and ISO 15031-6.
| Service | Key Operations | Typical Use Cases |
|---|---|---|
| Reasoner Service | loadKnowledgeBase, reason, getResult, getCapabilities, resetReasoner | Start diagnostic session, run inference on test data, query reasoner characteristics |
| Result Service | getDiagnosticResult, getConfidence, getRecommendedActions, getSupportingEvidence | Retrieve fault diagnosis, compare multiple reasoner conclusions, document root cause |
| Session Service | createSession, suspendSession, resumeSession, closeSession, getAuditTrail | Manage long-running diagnosis, pause for additional data collection, maintain traceability |
From an engineering perspective, implementing AI-ESTATE requires careful consideration of several architectural decisions. First, the granularity of the diagnostic model must be balanced against computational efficiency. A highly detailed model with hundreds of thousands of fault-to-test dependencies provides excellent diagnostic resolution but may require significant processing time for real-time inference. In practice, hierarchical modeling approaches are recommended, where coarse-grained diagnosis identifies the faulty subsystem first, followed by fine-grained diagnosis within the identified subsystem. This approach reduces the reasoning complexity from O(n³) to approximately O(k·m³) where k is the number of subsystems and m is the average components per subsystem.
Second, data quality management is essential for effective diagnosis. AI-ESTATE provides mechanisms for representing confidence values and uncertainty in diagnostic conclusions, but these are only useful if the underlying data is reliable. False alarms from built-in test equipment (BITE), intermittent faults, and measurement noise must be explicitly modeled in the knowledge base to avoid misleading diagnostic results. Bayesian network extensions to AI-ESTATE models are particularly effective in these scenarios, as they naturally handle uncertainty through probabilistic inference.
Third, integration with Automatic Test Markup Language (ATML, IEEE Std 1671) enhances the utility of AI-ESTATE implementations. ATML provides standardized XML schemas for describing test programs, test results, and test station configurations, while AI-ESTATE provides the diagnostic reasoning framework. Together, they enable a complete test-and-diagnosis workflow where ATML-defined tests feed results into AI-ESTATE reasoners, which then produce diagnoses that are fed back into ATML test program management. For maintenance organizations, this integration enables closed-loop diagnostic improvement, where field repair outcomes are systematically fed back to refine the diagnostic knowledge base. Modern implementations increasingly expose AI-ESTATE services through RESTful web service interfaces, enabling cloud-hosted diagnostic reasoners that can be shared across multiple maintenance sites while maintaining centralized knowledge management and continuous learning from fleet-wide operational data.