ControlSpec Validator
CSV to PLC

Turn Your CSV Test Matrix into Executable PLC Tests

Move from a spreadsheet-based test plan to repeatable PLC validation without modifying the controller program for every test.

CSV to PLC uses a structured CSV test matrix to drive external test execution, write defined test values, read PLC responses, compare results against expected conditions, and record the outcome.

No temporary test logic. No manual copy-and-paste between the test sheet and PLC.

Request a Demo Explore the Workflow
The Problem

PLC Testing Still Relies Too Heavily on Manual Work

FAT, commissioning and validation teams often have a well-defined test procedure in Excel or CSV — but the execution still happens manually.

That creates several recurring problems:

Re-keying Test Data

Engineers manually transfer stimulus values from the test sheet into PLC tags, then copy the observed results back into the test record.

Temporary PLC Test Logic

Some test approaches require temporary simulation, forcing functions or dedicated test code inside the controller. That can create additional review, configuration and handover work.

Inconsistent Evidence

A test may be completed successfully, but the evidence is often distributed across spreadsheets, screenshots, notes and separate commissioning records.

Repetition at Scale

When hundreds or thousands of signals, interlocks or sequences must be checked, manual execution becomes slow and difficult to standardise.

The CSV to PLC Approach

Keep the Test Definition in CSV. Execute the Test Externally.

CSV to PLC is designed around a simple separation:

The CSV defines the test.

The PLC executes the control logic.

CSV to PLC performs the external validation.

A test matrix can define:

  • PLC tag or address
  • Test stimulus
  • Expected response
  • Acceptance criteria
  • Sequence or test step
  • Pass / fail condition
  • Test notes and result metadata

The validation client then uses that matrix to interact with the controller through a supported industrial communication interface.

How It Works

How It Works: Define Test, Connect, Execute, Validate, and Record results and evidence
Step 1

Generate the Test Matrix from the Engineering Specification

The CSV Is the Output of the Spec-to-CSV Engine — Not a Manual Starting Point

CSV to PLC does not assume that engineers manually create the CSV test matrix from scratch.

The upstream Spec-to-CSV Engine converts layout-rich engineering specifications into a structured, traceable IEC 62381 functional test checklist. It reads the functional specification, maps requirements and tag nomenclature, generates the required test fields, and verifies the resulting logic before the CSV is handed to the execution layer.

Specification Spec-to-CSV Engine Verified CSV Test Protocol CSV to PLC PLC Validation

This creates a clear separation between test generation and test execution.

What the upstream engine does

The Spec-to-CSV Engine processes the engineering specification through four stages:

  1. READ — Intelligent Perception

    Reads layout-rich PDFs while preserving document structure, tables, headings, tags and page-level visual provenance.

  2. MAP — Ontological Alignment

    Aligns extracted variables, tags and sequences with the plant's structured nomenclature and logical relationships.

  3. TRANSLATE — Schema-Constrained Generation

    Converts the mapped requirements into the defined IEC 62381 CSV test schema, including fields such as Test Case ID, Annex Reference, Functional Category, Test Activity and Acceptance Criteria.

  4. VERIFY — SME Safety & Correction Loop

    Applies automated logic checks and human engineering review before the generated test protocol becomes an executable validation asset.

The upstream engine therefore produces the structured CSV that CSV to PLC consumes.

Example output

A generated checklist may contain fields such as:

Test Case ID,Annex Ref,Functional Category,Test Activity,Acceptance Criteria
TC-FUN-VSD-052,A.3.19,Application Logic,With VSD Earth Switch Closed simulate S4.ES053 = 1 and issue remote Close Command,Circuit Breaker Close Command executes successfully

The exact CSV schema is determined by the project's test methodology and the configured IEC 62381 template.

Traceability from specification to test

An important part of the upstream process is maintaining the relationship between each generated test and its source requirement.

For example:

Engineering Specification
Spec-to-CSV Engine
READ MAP TRANSLATE VERIFY
IEC 62381 CSV Test Protocol
CSV to PLC

This means CSV to PLC starts with a structured, specification-derived test protocol, rather than treating CSV as an isolated spreadsheet.

Step 2

Connect to the PLC

CSV to PLC is designed to operate as an external test client.

Depending on the control platform and project configuration, communication can be provided through supported native industrial protocols or OPC UA.

The objective is to interact with the controller without requiring the test sequence itself to become part of the production PLC application.

Step 3

Execute the Test

The test engine reads each row of the matrix and performs the defined actions.

A typical sequence is:

  1. Write the defined stimulus.
  2. Allow the PLC logic to process the condition.
  3. Read the required response variables.
  4. Apply the acceptance rule.
  5. Record the measured result.
  6. Continue to the next test step.

This creates a repeatable execution path from the original engineering test definition to the observed PLC response.

Step 4

Validate the Result

The platform compares the PLC response with the expected result defined in the CSV.

Depending on the test, acceptance criteria may include:

  • Boolean state
  • Numeric value
  • Range or tolerance
  • Alarm or interlock state
  • Sequence completion
  • Response condition
  • Timing or timestamp information

The result should be recorded as part of the test evidence rather than relying on manual transcription.

Step 5

Generate Test Evidence

Each executed test can produce a structured result containing information such as:

  • Test ID
  • Tag or address
  • Stimulus applied
  • Observed response
  • Expected result
  • Pass / fail status
  • Timestamp
  • Test notes
  • Execution metadata

This creates a more consistent evidence trail for engineering review, FAT documentation and commissioning records.

Supported Connectivity

Designed for Industrial Automation Environments

The concept is intended to support common PLC communication methods, with the final connection method depending on the controller model, firmware, configuration and available interfaces.

Platform / Protocol Example Connectivity Typical Use
Rockwell Automation EtherNet/IP / CIP Read and write controller tags where supported
Siemens S7 communication Read and write configured data areas where supported
Modbus TCP TCP/IP Register and coil based testing
OPC UA OPC UA client Unified access to exposed PLC/server variables

Connection requirements

Actual connectivity depends on the project environment. Typical requirements may include:

  • Network access to the controller
  • Correct controller configuration
  • Appropriate permissions
  • Supported protocol features
  • Correct tag/address mapping
  • OPC UA server functionality where applicable

CSV to PLC does not bypass PLC security or vendor configuration requirements.

What Makes It Different?

The Test Definition Stays Separate from the PLC Application

A key design principle is to keep test intent outside the production control program.

Instead of repeatedly embedding project-specific test code into the PLC, the test procedure can remain in a structured external file.

That separation can simplify:

Repeatability

Run the same test matrix again after a software revision, configuration change or troubleshooting activity.

Traceability

Link each result back to the originating test case.

Maintainability

Update the test matrix without rebuilding a large block of temporary PLC test logic.

Reuse

Use the same test structure across similar machines, panels or project revisions where the tag mapping is consistent.

Where CSV to PLC Fits

FAT, Commissioning and PLC Validation

CSV to PLC is particularly relevant to engineering teams responsible for:

Factory Acceptance Testing (FAT)

Execute repeatable functional test cases against a PLC application and capture the results in a structured format.

Commissioning

Repeat selected validation tests during site commissioning after hardware, instrumentation or configuration changes.

Regression Testing

Re-run an established test matrix after PLC software revisions to identify unexpected changes.

Interlock & Sequence Testing

Validate defined permissives, interlocks, alarms and process sequences against expected behaviour.

Engineering Verification

Provide structured evidence from the test execution rather than relying only on handwritten notes or screenshots.

Example Workflow

Engineering Specification
CSV Test Matrix
CSV to PLC
Write stimulus
Read response
Acceptance Check
Test Result
Validation Evidence
Example Test Case

Motor Start / Stop Interlock

Test objective: Verify that a motor can start when permissives are healthy and stops when the stop command is applied.

Inputs

  • Start command
  • Stop command
  • Safety/permissive status

Expected responses

  • Motor run status
  • Fault status
  • Alarm status

CSV-driven execution

1. Confirm permissives = healthy
2. Apply Start_Command = TRUE
3. Read Motor_Running
4. Compare with expected = TRUE
5. Apply Stop_Command = TRUE
6. Read Motor_Running
7. Compare with expected = FALSE
8. Record result

The same structure can then be repeated for additional motors, valves, sequences or interlocks.

Designed for Engineers

Use the Tools You Already Understand

CSV to PLC is intentionally centred on an engineering workflow that is familiar to controls and commissioning teams:

Specification Test Matrix Execution Result Evidence

The goal is not to replace engineering judgement.

The goal is to reduce repetitive manual execution so engineers can spend more time on:

  • Investigating failures
  • Reviewing logic
  • Troubleshooting plant behaviour
  • Resolving design issues
  • Verifying the final result

A Practical Test Automation Layer for OT

CSV to PLC sits between the engineering test document and the control system.

Engineering Specification
CSV Test Matrix
CSV to PLC Test Engine
PLC / OPC UA Interface
Test Results & Evidence

This provides a practical path toward more repeatable and data-driven PLC validation without requiring the test definition to become part of the production control application.

Technical Notes

Built for Controlled Test Environments

CSV to PLC should be used as an engineering test tool within an appropriately controlled environment.

Before execution, the engineering team should confirm:

  • Correct PLC and project revision
  • Correct tag/address mapping
  • Safe test conditions
  • Network access and segmentation
  • Controller operating mode
  • Appropriate write permissions
  • Isolation from unintended production equipment
  • Recovery procedure for failed or interrupted tests

Why Use CSV to PLC?

Reduce Manual Data Entry

Drive test execution from the same structured test matrix used by the engineering team.

Make Testing Repeatable

Run a defined test sequence again after changes instead of recreating the procedure manually.

Keep Tests External

Reduce the need for project-specific temporary test code inside the production PLC application.

Create Better Evidence

Capture structured results that can be reviewed, filtered and retained with the project documentation.

Scale the Test Process

Apply the same execution model to large numbers of signals and repetitive functional tests.

Ready to Automate Your PLC Test Matrix?

From CSV Test Case to PLC Result

Turn your existing test matrix into a repeatable engineering workflow.

Request a Demo Discuss a Pilot Test