A critical contractual milestone in validating heavy-industry control systems is the Factory Acceptance Test (FAT). Historically, translating complex, layout-rich PDF specifications (such as your Conveyor Hydraulic Brake or Variable Speed Drive specifications) into standard-compliant, executable IEC 62381 functional test sheets has been an expensive, manual, and error-prone process.
Control system integrators and client engineers spend an excessive amount of time manually copying and pasting functional requirements and operational rules from engineering documents into test sheets. Worse than the wasted hours, this tedious process creates a massive cognitive bottleneck, leading to "requirements leakage"—where critical functional requirements defined in the document fail to be verified during testing.
Our Spec-to-CSV Engine is designed to automate this transition. It ingests unstructured, layout-rich engineering specifications, resolves their visual design hierarchies, aligns their operational rules to a plant ontology, and produces structured, traceable IEC 62381 CSV functional checklists designed to support IEC 62381 FAT workflows.
The engine uses a structured four-stage workflow to transform engineering documentation into reviewable FAT test cases:
Extract requirements and recover document structure. The engine maps the 2D layout of dense, multi-column PDF specifications, isolating headings, paragraphs, nested tables, and logic blocks with coordinate precision rather than flattening the page into raw text.
Identify equipment, signals, operating states and engineering relationships. Instead of placing text into a generic search index, extracted tags, variables, and sequences are aligned to a Plant Ontology so the engine can structure how equipment, signals, and operating states relate.
Convert functional requirements into structured test conditions and expected results. Rather than relying solely on generative interpretation, the engine applies structured schemas, engineering rules and validation checks to constrain how requirements are transformed into test cases, including Test Case ID, Annex Ref, Functional Category, Test Activity, and Acceptance Criteria.
Apply consistency and traceability checks before presenting the output for engineer review. Automated checks flag inconsistencies against mapped operational rules and source references. Generated test cases remain subject to review and approval by the responsible engineer.
Operational rules, conditions, interlocks and sequences are structured during the transformation process to help preserve the intent of the original specification.
Every generated test case retains a reference to its source requirement, allowing engineers to review the generated result against the original specification before approval.
The biggest barrier to adopting AI in high-risk engineering environments is the "black-box" problem: a test case is difficult to defend if you cannot show the engineering requirement that mandated it. Every row in the synthesized IEC 62381 CSV checklist retains its original page-level coordinates from the READ stage. In the floor execution app, a control engineer or witness can select a test case and split the screen—displaying the original PDF specification and highlighting the table cell, diagram, or paragraph that justifies the test. This helps reduce hours of document-searching during site audits and handovers.
The Spec-to-CSV Engine is designed to assist engineers, not replace engineering judgement.
Generated test cases remain subject to review and approval by the responsible engineer. Source references and traceability information allow reviewers to compare generated tests against the original specification and refine them where required.
The objective is not to automate engineering responsibility. It is to remove repetitive document-processing work so engineers can spend more time on engineering verification.
For control engineers, systems integrators, and IT architects, the Spec-to-CSV Engine uses a neuro-symbolic software architecture to combine machine-learning-based document understanding with structured engineering models and rules to transform specifications into reviewable test cases:
Traditional text-stripping libraries (like PDFMiner or PyPDF) flatten the PDF canvas into a jumbled string of text, which destroys tables, mixes vertical column flows, and breaks tag naming structures.
We deploy Docling, a deep-learning layout segmenter powered by visual models (like RT-DETR and TableFormer). Docling segments the PDF canvas into structured hierarchies.
A highly detailed visual JSON tree where every extracted word, register tag, or table cell retains its Visual Provenance—its exact page number and bounding-box coordinates on the page.
Once the document is parsed into structure-aware markdown and tables, raw variables are aligned to equipment, signals, operating states, and engineering relationships.
We use a parent-child indexing strategy. The system generates coarse vector embeddings of paragraph and table summaries (allowing the retrieval engine to navigate the layout), while separately embedding the raw markdown detail vectors. This helps keep related trigger signals and interlock outputs in a shared semantic neighborhood.
The semantic mapping is not intended to replace engineering interpretation. The plant ontology and symbol relationships are developed and refined using controls and automation domain knowledge, providing the engineering context required for meaningful downstream test generation.
Extracted variable ranges are mapped against a standardized Symbol Table (e.g., mapping S4.ES051FL as a state register representing "Earth Switch Closed"), converting contractor terminology into a structured data dictionary.
Rather than relying solely on generative interpretation, the engine applies structured schemas, engineering rules and validation checks to constrain how requirements are transformed into test cases.
Libraries such as Outlines and Instructor apply a strict Pydantic data schema to the LLM's output. Grammar masks on the model's token distribution help constrain characters and formatting to the expected schema.
The system outputs structured CSV strings aligned to the columns of the IEC 62381 functional test schema:
ControlSpec Validator
Test Case ID, Annex Ref, Functional Category, Test Activity, Acceptance Criteria
Synthesized test steps are checked against structured models of operational rules (such as Petri nets, timed automata, or state decision tables) to help preserve the intent of the original specification.
If validation checks detect a logical contradiction (e.g., an alarm limit tripping before its permissive threshold is met), the issue is flagged for correction and engineer review.
The system packages the flagged exception with the page coordinate of the original requirement, prompting a re-synthesis of the logic block. Operational rules, conditions, interlocks and sequences remain structured during this transformation so reviewers can compare the result against the source specification.
Industrial specifications contain more than text. They encode equipment behaviour, operating states, interlocks, permissives, alarms, sequences and engineering conventions that require domain knowledge to interpret correctly.
The Spec-to-CSV Engine is therefore developed through continuous collaboration between data science and controls & automation engineering specialists.
Our data and AI specialists develop the document intelligence, semantic extraction, structured generation and validation components of the pipeline.
Their focus is on making complex engineering documentation machine-readable while preserving document structure, context and source traceability.
Our controls and automation specialists provide the engineering context required to interpret industrial specifications.
They contribute to the plant ontology, equipment models, control philosophy, interlock logic, operating states, test templates and engineering validation rules used by the engine.
The two disciplines work together throughout the development and refinement of the engine.
This collaborative loop allows engineering feedback to be incorporated into the plant ontology, validation rules and test-generation logic as the system is refined.
See how the engine transforms a real industrial control requirement into traceable FAT test cases.
SPEC-006-E-12225_1.pdf, Section 4.12)
For the 11kV Feeder Circuit Breaker Remote Close sequence to be ready:
| Requirement | Source |
|---|---|
| Earth Switch closed | Section 4.12 |
| Earth Switch feedback verified | Section 4.12 |
| Protection relay 48VDC healthy | Section 4.12 |
| VSD Ready status | Section 4.12 |
| Remote Close permitted | Derived control relationship |
Source: Page / section / bounding-box reference retained from the READ stage.
Normalized engineering representation
| Test ID | Test Condition | Expected Result |
|---|---|---|
TC-FUN-VSD-052 |
Earth Switch closed, 48VDC healthy, VSD Ready; issue Remote Close | CB Close command accepted |
TC-FUN-VSD-053 |
Earth Switch open; other permissives healthy; issue Remote Close | CB Close command inhibited |
TC-FUN-VSD-054 |
Earth Switch closed; 48VDC supply unhealthy; issue Remote Close | CB Close command inhibited |
TC-FUN-VSD-055 |
Earth Switch closed, 48VDC healthy, VSD not Ready; issue Remote Close | CB Close command inhibited |
Controls & Automation Engineer
“Does this test accurately represent the intended control philosophy?”
See how the Spec-to-CSV Engine extracts requirements, structures functional logic, generates FAT test cases and preserves source traceability.
Our controls and automation engineers and data scientists can work with your team to evaluate the output against your existing FAT workflow.
Start with a private, on-premise pilot using representative project specifications.
Start a private on-premise pilot