PLC Testing

And why should we test?

Tests cover more scenarios

Testing of PLC program is one of the important steps in PLC programming. For a PLC tester it is required to try all possible scenarios to understand how program will behave in specific conditions.

Professionally speaking, development of new PLC logic and changes to an existing logic must be tested to validate that a new implementation complies with equipment's required functionality. More importantly, changes to existing PLC logic must not inadvertently affect existing functionality.

Traditional approach

To test the PLC, a PLC programmer currently adds custom simulation code to emulate the behaviour of inputs due to the process driving them. PLC logic is required to be added to apply default setpoints or equipment statuses.

Traditional approach has a few problems:

  • Critical risk: Simulation logic could be left active once the PLC has been installed on site.
  • Low performance: Depending on test complexity, the simulation logic might use multiple computations during the execution. That can reduce PLC scan rate and interfere with results of the test and reduce test accuracy.
  • No common library: There is no centralised repository of the testing framework. Fixing bugs in the simulation logic of one PLC is not always captured by revision control and not reflected in the simulation logic of another PLC.

Our approach

We have developed a software to perform specification-based testing of PLC logic. Specification-based (or black-box) testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance.

The app creates a stand alone testing environment, runs it on a computer and communicates to a PLC (or the emulator) via Ethernet. There is no need to add additional logic to the production PLC program. For testing PLC logic the software needs to be set as per the client's specification (also known as a functional description). The test runs completely automatically and can be used for the following test cases:

  • PLC program unit tests,
  • Subsystem tests,
  • Protections tests, and
  • Plant Simulation

Our approach eliminates the problems with the traditional PLC testing approach but also adds benefits:

  • Easy to create test case: The program has a user friendly interface and the test can be done by a non-PLC programmer.
  • Runs automatically: After the execution it will go through multiple control phases to test protection logic. Some protection timers can take a few seconds but the combined test time of the protection logic can take hours. The software will wait for completion and no human interaction is required.
  • Test set library: Set of tests are written per unit or per application and can be saved to separate files.
  • One size fits all (coming up): One set of tests can be applied to different PLC brands (currently supported only ControlLogix and CompactLogix from Allen-Bradley).
  • Generates report (coming up): Upon test completion the software generates HTML report. The report has all necessary details on PLC type, time/date and pass/fail results.

As an example of a subsystem tests, PLC's inputs and outputs can be used. PLCs typically have field device inputs and outputs that will not exist in a testing environment. Via Ethernet protocol the app writes values to input memory registers and reads output registers to confirm expected behaviour.

Have a question? Post it in Github Issues or send it to alex@controlx.io