Closed-Loop Formal Verification Framework with Non-determinism, Configurable by Meta-modelling Sandeep Patil, Sayantan Bhadra, Valeriy Vyatkin The University of Auckland, Auckland, New Zealand

PLC Programming Programmable Logic Controllers (PLCs) are most widely used in industrial automation devices PLC Programming: IEC 61131-3 standard

Testing of PLC Programs Verification/Testing options: On a real plant Simulation – Visualization Formal Verification: based on formal models.

Formal Verification Mathematically prove or disprove correctness of an algorithm Verify certain properties or formal specifications Liveliness Deadlocks Safety EF (BACK and FWD) PLC program Formal model Start End

Closed – loop Modelling

Closed-loop model in Net Condition-Event Systems

Complexity of Model vs. Complexity of Behaviour

Model of Plant: Composition and Configuration Library of Automated Mechatronic Components Transfer Storage Sensor Cylinder Panel

Visual Verifier Tool

Case Study : Pick and Place robot Pick and Place system modeled by José Machado in his Ph.D. dissertation in 2007 carried out at University of Minho (Portugal) and ENS Cachan Paris (France). Good example of mechatronic modularity. Good for benchmarking (modeled with UPPAAL and verified with SMV)

Configurator and the Meta Model Meta model contains information about object’s structure, models’ structure (FB and NCES) and links between them. The Configurator interactively Configures Plant model for simulation. Selects a controller from library. Configures NCES model of Plant. Configures non-determinism.

Reconfiguration of NCES model NCES model has to be configured based on the physical plant configuration, same as simulation model. The same Meta model is used for that. Apart from plant configuration, Meta model is used to control whether the model in NCES is deterministic or non-deterministic. Work Piece Available

Error Prone Plant Model? One option is developer has to introduce errors in the deterministic model to make plant generate tricky outputs. Resulting in many versions of Models being created and use them in testing. Hence not a good idea....... For each error scenario, the developer will need to maintain a different Plant Model. Error in Trays Error in Sensors Error in Cylinders

More general solution: add non-determinism Different modeling approaches for non-determinism. (a) Conflict. (b) Conflict only when a condition is true (controlled non-determinism) and (c) Controlling presence of non-determinism during modeling. To allow user weather or not user wants to induce erroneous behaviour into the Plant model.

Controlled Non-Determinism

CTL Specifications of Behaviour In ViVe model checker, we can use CTL properties to specify erroneous or correct behaviours Example 1: If WP2 is present and WP1 is disappeared and WP3 is not yet in the tray, then both horizontal cylinders should not extract (erroneous behaviour) CTL for this property: EF(p12&p55&p88&&p98&p105) Example 2: Whenever a work piece arrives on any of the trays, it should be ultimately picked up and dropped in the output tray (expected behaviour) CTL: AG(pp1->EF(s1^vcd^vaccum))

Erroneous Behaviour of the System

Complexity: Methodology for Improvement Benchmarked with state machines and established tool chains: UPPAAL + SMV. For a deterministic model, our methodology took about 2 seconds to generate the reachability space. For a non-deterministic model, our result is 1-1.5 minutes, compared to state machine approach that took about 120 minutes! The gain is attributed to our tool supported methodology of incremental non-determinism. No of places where non determinism exists No of States generated before an error was detected Time taken to generate the reachability graph 1 3552 60 seconds 2 5268 90 seconds