Note: This article is the second article of our 2-part series. Please visit the 1st part 

Why Some XRIO Files Generate Relay Characteristics — and Others Do Not

Investigating XRIO Interoperability: An Engineering Workflow for Distance Relay Characteristic Reconstruction

Protection engineers occasionally encounter situations in which an XRIO file imports successfully and no error message is reported, yet the expected distance relay characteristic does not appear as anticipated. This apparent contradiction often raises questions regarding interoperability and forms the starting point for the investigation presented in this article.

Keywords: XRIO interoperability, distance relay testing, relay characteristic reconstruction, protection relay engineering, relay testing software, engineering workflow, digital substations, protection relay settings, secondary injection testing.

Throughout this article, 'characteristic reconstruction' refers to the engineering process through which exchanged relay settings become a visible and usable relay characteristic within an engineering environment. The term 'characteristic generation' refers to the automatic reconstruction of relay characteristics by engineering software following successful XRIO import. It is not about the manual creation or editing of relay characteristics using a characteristic editor, which represents a different engineering workflow and is outside the scope of this investigation.

Abstract

Distance relay settings are increasingly exchanged electronically to improve engineering efficiency during protection system commissioning, maintenance, testing, and retrofit projects. Among the available exchange mechanisms, XRIO has become a widely recognised format for transferring relay configuration data between engineering tools. However, successful exchange of engineering data does not necessarily guarantee successful reconstruction of distance relay characteristics within different engineering environments.

This article presents a structured engineering investigation into XRIO interoperability using two independent field samples. Rather than comparing software products or evaluating vendors, the investigation examines the complete engineering workflow through which exchanged engineering data is interpreted and transformed into reconstructed distance relay characteristics.

The investigation proceeds chronologically. The first field sample demonstrates that successful file import, correct engineering hierarchy, and available engineering data alone do not fully explain characteristic reconstruction. A second field sample is then examined to investigate an additional stage of the engineering workflow involving relay-specific engineering interpretation. Independent verification is subsequently performed to assess the consistency of the reconstructed characteristics.

The observations support an important engineering conclusion: interoperability should be evaluated as a complete engineering workflow rather than by successful file exchange alone. This investigation therefore provides a repeatable methodology for engineers seeking to evaluate interoperability between relay engineering environments while avoiding assumptions based solely on import success.

Reader Orientation

This article is intended for protection engineers, commissioning engineers, relay testing specialists, software developers, and organisations involved in digital substation engineering.

It is important to clarify what this investigation is and is not.

This article is:

• A structured engineering investigation.
• A chronological examination of XRIO interoperability.
• An evaluation of engineering workflow using field-observed samples.
• This article also includes a methodology for investigating interoperability.

This article is not:

• A software comparison.
• A product review.
• A certification of interoperability.
• A purchasing guide.
• An evaluation of any manufacturer.

Throughout the investigation, observations are presented in the order in which they were established. No conclusion is introduced before the supporting engineering evidence is examined. This chronological approach is deliberate because engineering investigations derive their strength from reproducible observations rather than assumptions.

For confidentiality, all customer names, project identifiers, relay identifiers, and site-specific information have been removed. The two engineering samples discussed throughout the manuscript are therefore referred to simply as the First Field Sample and the Second Field Sample.

Introduction

The digitalisation of protection engineering has fundamentally changed how engineers create, exchange, verify, and maintain relay settings. Modern protection projects frequently involve multiple engineering software platforms, relay manufacturers, and testing environments, making the reliable exchange of engineering information increasingly important.

Among the formats used to exchange relay configuration data, XRIO has become one of the most widely recognised in the protection engineering community. Its primary objective is to enable the exchange of engineering data generated in one environment with another without requiring manual re-entry of relay settings.

Despite this objective, practical engineering experience demonstrates that successful import of an XRIO file does not automatically imply that every engineering environment will reconstruct identical distance relay characteristics. Differences may arise not because engineering data is missing, but because different engineering workflows interpret available data differently during characteristic reconstruction.

Understanding this distinction is increasingly important as utilities, manufacturers, consultants, and testing organisations continue to adopt digital engineering workflows for protection, commissioning, and maintenance.

This article does not attempt to determine whether one software environment is superior to another. Instead, it investigates a more fundamental engineering question:

How should XRIO interoperability be evaluated from an engineering perspective?

Rather than relying on assumptions or vendor claims, the investigation follows a structured sequence of engineering observations using two independent field samples

Investigation Objective

The objective of this investigation is to determine whether successful XRIO interoperability can be evaluated solely by successful file exchange, or whether additional stages of the engineering workflow contribute to the reconstruction of distance relay characteristics.

To answer this question, the investigation examines the following:

• Successful import of an XRIO file.
• Recognition of the imported engineering hierarchy.
• Observation of reconstructed distance relay characteristics.
• Verification of the active characteristic under examination.
• Examination of the engineering data available within the imported file.
• Assessment of whether the available evidence sufficiently explains the reconstructed characteristic.
• Investigation of relay-specific engineering interpretation using a second independent field sample.
• Independent verification of the resulting engineering observations.

The investigation deliberately avoids making assumptions regarding software implementation or proprietary processing algorithms. Only observations directly supported by the examined engineering workflow are discussed.

The First Investigation

The First Investigation establishes the engineering foundation for the remainder of this article. Its purpose is not to explain characteristic reconstruction immediately but to document each observable stage of the engineering workflow in the order in which it became available.

Beginning with successful import, the investigation progressively examines the imported engineering hierarchy, reconstructed characteristics, available engineering data, and evidence available within the exchanged XRIO file. Only after these observations have been exhausted does the investigation proceed to the second field sample.

Maintaining this chronology is essential because engineering conclusions become meaningful only after verifying each preceding observation.

• The First Investigation
• 3.1 Investigation Overview
• The first investigation was designed to establish a complete engineering baseline before attempting to explain the reconstruction of distance relay characteristics. Rather than beginning with assumptions regarding interoperability, the investigation followed the engineering workflow exactly as it unfolded.
• Each stage answered a single engineering question before progressing to the next:
• Was the XRIO file successfully imported?
• Was the engineering hierarchy recognised correctly?
• What characteristic was reconstructed?
• Was the correct characteristic being viewed?
• What engineering data was available within the imported file?
• Had the available engineering evidence reached its practical limit?

This sequence is important because later conclusions depend upon observations established during the earlier stages.

• 3.2 Importing the First Field Sample
• The investigation began by importing the First Field Sample XRIO file into the engineering environment under examination.
• At this stage, we deliberately limited the primary objective. No attempt was made to interpret relay characteristics, assess interoperability, or evaluate engineering accuracy. The only question being addressed was whether the engineering environment could successfully accept and process the exchanged XRIO file without structural or parsing errors.
• Successful import establishes that the engineering environment recognises the structure of the exchanged file. It does not, by itself, show that every engineering object has been interpreted the same way as in the originating engineering environment.
• This distinction became increasingly important during the subsequent stages of the investigation.

• Figure 1. Successful Import of the First Field Sample XRIO File

The first XRIO file from the initial field sample was successfully imported into the engineering environment. At this stage, the investigation establishes only that the exchanged engineering data was accepted successfully. The successful import alone does not allow us to draw any conclusions regarding interoperability or characteristic reconstruction.

• Successful import is often considered an indicator of compatibility because engineers naturally expect a successfully imported XRIO file to reproduce the intended relay characteristic. Successful import is often considered an indicator of compatibility. From an engineering perspective, however, it represents only the beginning of the interoperability workflow. The imported engineering data must still be interpreted, organised, and transformed into engineering information before any meaningful evaluation can occur.
• The investigation therefore proceeded to examine the engineering hierarchy that was created from the imported file.

• 3.3 Examining the Imported Engineering Hierarchy
• Following a successful import, attention shifted to the engineering objects reconstructed from the exchanged XRIO data.
• The purpose of this stage was to determine whether the imported engineering hierarchy was complete and logically organised before examining any graphical relay characteristics.
• Inspection of the imported structure demonstrated that the engineering environment had recognised multiple engineering objects associated with the exchanged relay configuration. At this stage, no abnormal hierarchy or obvious omission was observed.

The engineering workflow, therefore, progressed from confirming file acceptance to confirming the engineering organisation.

• Figure 2. Imported Engineering Hierarchy Recognised Following XRIO Import

The engineering hierarchy was reconstructed from the imported First Field Sample XRIO file. The recognised engineering objects indicate that the imported engineering data has been organised into a structured hierarchy suitable for further examination.

• Successful recognition of the engineering hierarchy is an important milestone because it demonstrates that the imported engineering data has progressed beyond simple file acceptance.
• However, successful hierarchy reconstruction still does not establish whether the resulting distance relay characteristics accurately represent the originating engineering intent.
• The investigation therefore progressed to an examination of the reconstructed characteristic itself.

• 3.4 Initial Observation of the Reconstructed Characteristic
• Having confirmed that the imported engineering objects were organised correctly, attention naturally shifted to the engineering result produced by these objects.
• The reconstructed distance relay characteristic immediately attracted attention because its appearance raised an engineering question requiring further investigation.
• At this stage, the investigation deliberately avoided attempting to explain the observation. Instead, the characteristic was documented exactly as reconstructed by the engineering environment.
• Recording observations before interpretation is a fundamental principle of engineering investigations because explanations introduced too early may unintentionally influence subsequent analysis.

• Figure 3. Initial Observation of the Reconstructed Distance Relay Characteristic

The reconstructed distance relay characteristic observed immediately following the import of the first XRIO field sample. The purpose of this stage is to document the engineering observation rather than explain its origin

• The observation documented in Figure 3 raised an important engineering question. Before any interpretation could be attempted, it was necessary to verify that the engineering environment was displaying the intended active characteristic.
• This verification eliminated the possibility that the observed result was simply caused by selection of an unintended engineering object.

• 3.5 Verification of the Active Characteristic
• The unexpected observation documented during the previous stage required verification before further interpretation could be attempted.
• Engineering investigations must eliminate simple explanations before considering more complex ones.
• Accordingly, the active characteristic displayed within the engineering environment was examined to confirm that the reconstructed characteristic corresponded to the intended engineering object.
• Verification demonstrated that the displayed characteristic was indeed the active characteristic under investigation.

• Figure 4. Verification of the Active Characteristic

• Verification of the active characteristic ruled out incorrect object selection as the explanation for the previously observed reconstructed characteristic.

• Having confirmed that the correct engineering object was being examined, the investigation could proceed with greater confidence.
• The next logical question was no longer whether the correct characteristic had been selected, but whether sufficient engineering data existed within the imported XRIO file to explain the reconstructed characteristic.

• 3.6 Examination of Available Engineering Data
• The investigation now turned to the engineering data contained in the imported XRIO file.
• Rather than searching for information expected by a particular software environment, the objective was to determine whether the exchanged engineering data itself appeared sufficiently complete to support reconstruction of the observed distance relay characteristic.
• This stage therefore focused on examining the engineering information available within the imported hierarchy without making assumptions regarding how individual engineering environments might subsequently interpret that data.

The First Investigation (Continued)

3.6 Examination of Available Engineering Data

Following verification of the active characteristic, the investigation focused on the engineering data contained within the imported XRIO file.

At this stage, the objective was not to determine how a particular engineering application reconstructed the characteristic. Instead, the investigation sought to establish whether the exchanged engineering data itself appeared sufficiently complete to support the observed engineering result.

The examination therefore remained evidence-driven. Every available engineering object within the imported hierarchy was reviewed before considering any explanation involving software-specific processing.

This distinction is important because an apparent difference in characteristic reconstruction does not necessarily imply that engineering data is absent. The difference may instead arise from the manner in which available engineering data is interpreted within a particular engineering workflow.

The investigation therefore continued by examining the engineering components available within the imported structure.

3.7 Examination of Available Engineering Components

The review of the imported engineering hierarchy identified additional engineering objects associated with the exchanged XRIO file.

These objects were not actively sought at the beginning of the investigation. They became relevant because they formed part of the engineering structure reconstructed following successful import.

Their presence significantly changed the direction of the investigation.

Until this point, the primary engineering question had been the following:

Is important engineering data missing from the exchanged XRIO file?

The engineering observations now suggested a different question:

How is the available engineering data interpreted during characteristic reconstruction?

This was a significant shift.

Rather than continuing to search for missing information, the investigation now focused on understanding the engineering workflow through which the available information was transformed into a reconstructed distance relay characteristic.

Figure 5. Examination of Available Engineering Components

Engineering components identified within the imported First Field Sample. Their presence demonstrated that additional engineering information existed within the imported structure and changed the focus of the investigation from searching for missing data to understanding engineering interpretation.

The observations documented in Figure 5 did not explain the reconstructed characteristic.

Instead, they demonstrated that the engineering investigation had reached an important milestone.

The engineering question itself had changed.

The investigation was no longer attempting to determine whether sufficient engineering data existed.

Instead, the investigation sought to understand how the engineering data was used in the reconstruction workflow.

No conclusions regarding software implementation or proprietary algorithms were drawn at this stage.

3.8 Assessing the Sufficiency of the Available Evidence

Having examined the imported engineering hierarchy, verified the active characteristic, and reviewed the available engineering components, the investigation assessed whether the accumulated engineering evidence was sufficient to explain the reconstructed distance relay characteristic.

Within the scope of the First Investigation, no further engineering observations were available that could directly explain the reconstruction process.

This conclusion should not be interpreted as indicating that additional engineering mechanisms do not exist.

Rather, it indicates that the available evidence from the First Investigation had reached its practical limit.

This distinction is fundamental to the methodology adopted throughout this article.

Engineering investigations should proceed to additional stages only after the available observations from the current stage have been fully examined.

Figure 6. Assessment of Available Engineering Evidence

Assessment of the engineering evidence available during the First Investigation. The accumulated observations established that the practical limit of the available evidence had been reached, providing the justification for initiating a second stage of investigation.

The conclusion of the First Investigation did not provide a complete explanation for characteristic reconstruction.

Instead, it achieved something equally important.

It established a well-defined engineering question supported by documented observations.

At this point, the investigation had established the following:

• The XRIO file imported successfully.
• The engineering hierarchy was reconstructed correctly.
• The observed distance relay characteristic had been documented.
• The active characteristic had been verified.
• Additional engineering components were present within the imported structure.
• The available engineering evidence had reached its practical limit.

These observations provided a sound engineering foundation for the next phase of the investigation.

Rather than attempting to speculate beyond the available evidence, the investigation proceeded to a second field sample, where an additional stage of the engineering workflow could be examined.

This transition marked an important methodological principle of the investigation.

The First Investigation successfully answered several engineering questions but also identified the precise stage of the workflow that required additional evidence.

The Second Investigation was not initiated because the First Investigation had failed.

It was initiated because the First Investigation had successfully established the precise engineering question that remained unanswered.

The Second Investigation

4.1 Why a Second Investigation Was Necessary

The First Investigation concluded that successful file import, recognised engineering hierarchy, verified engineering objects, and available engineering data were collectively insufficient to explain the complete reconstruction of the observed distance relay characteristic.

The remaining engineering question was therefore no longer about the availability of engineering data.

Instead, it focused on the engineering workflow used to interpret that data.

To investigate this additional stage, a second field sample was examined using an engineering workflow that included relay-specific engineering interpretation.

The purpose of the Second Investigation was not to validate or invalidate the First Investigation.

Instead, it was designed to extend the investigation beyond the practical evidence limit established during the first phase while maintaining the same disciplined, observation-based methodology.

4.2 Beginning the Second Investigation

The Second Investigation commenced with a new engineering sample that permitted observation of an additional stage of the engineering workflow.

Unlike the First Investigation, the objective was no longer limited to file import and examination of exchanged engineering data.

Instead, the investigation examined how relay-specific engineering interpretation contributed to the reconstruction of the distance relay characteristic.

As with the First Investigation, observations were recorded in chronological order.

No conclusions regarding interoperability were introduced before the corresponding engineering observations had been established.

Figure 7. Second Field Sample Introduced into the Relay-Specific Engineering Workflow

The second field sample is entering an engineering workflow that includes relay-specific engineering interpretation. This stage extends the investigation beyond the practical evidence limit established during the First Investigation.

The Second Investigation (Continued)

4.3 Observation of Relay-Specific Engineering Interpretation

The First Investigation established that the available engineering evidence had reached its practical limit without fully explaining the reconstruction of the observed distance relay characteristic. The second investigation, therefore, examined an additional stage of the engineering workflow in which relay-specific engineering interpretation became observable.

At this stage, the investigation remained strictly observational. It did not attempt to evaluate proprietary software algorithms or determine how individual engineering applications internally process engineering data. Instead, it focused on documenting the engineering activities that became visible during the import and reconstruction workflow.

The distinction is important. The investigation does not claim that relay-specific engineering interpretation is unique to any particular software environment. Rather, it demonstrates that characteristic reconstruction may involve engineering activities beyond the simple exchange of engineering data.

Figure 8. Relay-Specific Engineering Interpretation Observed During Import

4.4 Reconstruction of the Distance Relay Characteristic

Following completion of the relay-specific engineering interpretation stage, the reconstructed distance relay characteristic became available for examination.

Unlike the initial observations documented during the First Investigation, the purpose of this stage was not merely to record the appearance of the characteristic. Instead, the investigation examined the relationship between the exchanged engineering data and the reconstructed engineering information.

The accumulated observations indicate that characteristic reconstruction results from the interaction between exchanged engineering data and relay-specific engineering interpretation.

This conclusion is deliberately limited to the engineering workflow observed during this investigation. It does not imply that all engineering environments reconstruct characteristics identically, nor does it suggest that a particular reconstruction method is universally applicable.

Rather, it demonstrates that evaluating interoperability requires examination of the complete engineering workflow rather than successful file exchange alone.

Figure 9. Reconstructed Distance Relay Characteristic Following Relay-Specific Engineering Interpretation

Distance relay characteristic reconstructed following relay-specific engineering interpretation. The observations indicate that the resulting engineering information emerges from the interaction between exchanged engineering data and the engineering workflow applied during reconstruction.

The reconstructed characteristic documented in Figure 9 represents the first stage of the investigation, in which the engineering workflow itself provides an observable explanation of the reconstruction process.

This stage does not conclude the investigation.

Engineering observations should be independently verified whenever practical.

Accordingly, the investigation proceeded to an independent verification stage.

4.5 Independent Verification

Independent verification is an established engineering practice used to increase confidence in observations by examining them through an alternative engineering environment.

The purpose of this stage was not to compare software products.

Nor was it intended to certify interoperability.

Instead, independent verification examined whether the engineering observations established during the Second Investigation remained consistent when viewed using an independent engineering environment.

This distinction is essential because the consistency of engineering observations provides stronger support than those obtained from a single workflow alone.

Figure 10. Independent Verification Using MPWIN

Independent verification of the reconstructed distance relay characteristic using an alternative engineering environment. The objective is to assess the consistency of the engineering observations rather than evaluate software equivalence.

The independently reconstructed characteristic demonstrated engineering observations that were consistent with those established during the Second Investigation.

The investigation does not conclude that different engineering environments are identical.

Neither does it conclude that interoperability can be certified through a single verification exercise.

Instead, the independent verification supports the broader engineering observation that characteristic reconstruction should be evaluated within the context of the complete engineering workflow.

4.6 Engineering Evidence Established by the Second Investigation

The Second Investigation extended the engineering evidence established during the First Investigation by examining an additional stage of the reconstruction workflow.

Taken together, the investigation established the following engineering observations:

• Successful import confirms acceptance of exchanged engineering data but does not establish interoperability.
• Recognition of the engineering hierarchy demonstrates the successful organisation of imported engineering objects.
• Observation of a reconstructed characteristic should precede attempts at explanation.
• Verification of the active characteristic is necessary before interpreting engineering observations.
• Examination of available engineering data should be completed before assuming that important information is absent.
• Relay-specific engineering interpretation forms an observable stage of the reconstruction workflow.
• Independent verification provides additional confidence in engineering observations without implying software equivalence.

These observations collectively support the central engineering principle developed throughout this investigation:

XRIO interoperability should be evaluated as a complete engineering workflow rather than as a simple file import exercise.

This conclusion emerges from the chronological accumulation of engineering evidence rather than from any single observation.

The investigation therefore provides a repeatable methodology for evaluating interoperability while avoiding premature assumptions regarding software behaviour or engineering implementation.

5.4 Practical Engineering Implications

The investigation has several practical implications for protection engineers.

During commissioning activities, engineers should avoid assuming that successful import confirms successful engineering interpretation.

Similarly, observed graphical differences should not immediately be interpreted as missing engineering data.

Instead, engineers should systematically verify the following:

• successful import,
• engineering hierarchy,
• active characteristic,
• available engineering data,
• engineering interpretation workflow,
• independent verification where practical.

Following this sequence reduces the likelihood of incorrect engineering conclusions during commissioning and troubleshooting.

5.5 Limitations of the Investigation

Every engineering investigation has defined boundaries.

This investigation does not:

• evaluate every relay manufacturer,
• examine every engineering software platform,
• analyse proprietary reconstruction algorithms,
• certify interoperability,
• Establish universal engineering behaviour.

Instead, it documents engineering observations obtained from two field samples examined using a structured and reproducible methodology.

Future investigations involving additional relay families, engineering environments, and exchange workflows may extend these observations.

5.6 Engineering Questions Answered

This investigation provides evidence-based responses to several important engineering questions.

Does successful XRIO import demonstrate interoperability?

No. Successful import demonstrates a successful exchange of engineering data but does not, by itself, establish successful characteristic reconstruction.

Should graphical differences immediately be interpreted as missing engineering data?

No. The investigation demonstrates that engineering interpretation should also be considered.

Can interoperability be evaluated using a single engineering observation?

No. The investigation supports evaluating the complete engineering workflow.

Why was a second investigation necessary?

The available evidence from the First Investigation had reached its practical limit and did not explain the reconstruction workflow.

5.7 Why This Investigation Matters

Protection engineering increasingly depends on the digital exchange of engineering information.

As utilities adopt engineering workflows involving multiple manufacturers and engineering applications, understanding interoperability becomes progressively more important.

Rather than focusing on individual software implementations, this investigation proposes a repeatable engineering methodology for examining interoperability itself.

That methodology is likely to remain relevant even as engineering software evolves.

5.8 Common Misconceptions

This investigation also addresses several common misconceptions.

Engineering Conclusions

6.1 Revisiting the Original Engineering Question

The investigation began with a straightforward engineering question:

Can XRIO interoperability be evaluated solely by successful file import?

The accumulated engineering observations indicate that the answer is no.

Successful file import represents an important stage of the engineering workflow, but it does not, by itself, establish successful reconstruction of engineering information.

6.2 Principal Engineering Findings

The investigation supports the following principal findings:

1. Successful XRIO import confirms the successful exchange of engineering data. A successful import alone should not be interpreted as confirmation that the expected relay characteristic has been reconstructed
2. Engineering hierarchy reconstruction should be verified before examining relay characteristics.
3. Observed relay characteristics should be documented before interpretation.
4. Active engineering objects should be verified before engineering conclusions are drawn.
5. Available engineering data should be examined before assuming information is missing.
6. Relay-specific engineering interpretation represents an observable stage of the reconstruction workflow.
7. Independent verification increases confidence in engineering observations.
8. Interoperability is best evaluated as a complete engineering workflow.

6.3 Engineering Significance

The significance of these findings extends beyond the specific field samples examined in this article.

The methodology developed during the investigation provides engineers with a structured approach for analysing interoperability problems without relying on assumptions or vendor-specific claims.

As engineering environments continue to exchange increasing amounts of digital engineering data, disciplined investigation methods will become increasingly valuable.

6.4 Implications for Engineering Practice

Engineers involved in relay commissioning, maintenance, retrofit projects, and interoperability evaluation should consider adopting a workflow-based approach rather than relying solely on file exchange results.

Such an approach promotes more reliable engineering conclusions while reducing unnecessary troubleshooting arising from premature assumptions.

6.5 Final Conclusion

The engineering evidence presented throughout this investigation supports the following conclusion:

XRIO interoperability should be evaluated through systematic examination of the complete engineering workflow rather than through successful file exchange alone.

The observations demonstrate that characteristic reconstruction involves more than acceptance of exchanged engineering data. It emerges from the interaction between engineering data, engineering interpretation, and engineering verification.

This investigation therefore contributes a repeatable engineering methodology that can assist future interoperability studies while remaining independent of specific software implementations.

6.6 Closing Remarks

Engineering investigations are strongest when conclusions emerge from observations rather than assumptions.

Throughout this article, every engineering conclusion has been presented only after the supporting observations were established.

We hope that the methodology presented here will encourage similarly structured investigations into other aspects of protection engineering interoperability.

6.7 Engineering Recommendations

Based on the observations documented throughout this investigation, the following engineering practices are recommended:

1. Verify successful import, then verify that the expected relay characteristic has actually been reconstructed before assessing interoperability
2. Confirm the engineering hierarchy before analysing relay characteristics.
3. Verify the active characteristic before interpreting engineering observations.
4. Examine available engineering data before assuming missing information.
5. Consider relay-specific engineering interpretation as part of the interoperability workflow.
6. Perform independent verification whenever practical.
7. Evaluate interoperability using the complete engineering workflow rather than isolated observations.

6.8 Summary

The investigation progressed from the successful import of the first field sample through examination of the engineering hierarchy, documentation of the reconstructed characteristic, verification of the active engineering object, assessment of available engineering data, and recognition of the practical evidence limit.

A second field sample was then examined to investigate relay-specific engineering interpretation and independently verify the resulting engineering observations.

Together, these stages demonstrated that interoperability is best understood as a structured engineering workflow rather than a simple file exchange process.