Logic Execution

[sbeadle1]

📖 Home  Back  

The logic engine is single threaded, this means that Geo SCADA can only run one logic program at a time. To protect logic programs from being affected by poorly written programs which cannot execute correctly, Geo SCADA includes an instruction limit. This instruction limit prevents programs with large or infinite loops from locking out other programs, refer to Maximum Number of Opcodes Executed for more information on this error.

A Logic Program Will Run...

• At regular intervals (On Interval). The intervals are defined in the logic program's configuration.

• At regular intervals but only if its inputs have changed (On Interval with Input Change Detection enabled) The intervals are defined in the Logic program's configuration.

• At regular intervals only if the source of the trigger has changed value (the trigger is a value that is not used as an input in the logic program). The source of the value is defined in the trigger setting of the logic program's configuration.

• At regular intervals only if the trigger has changed value or the logic program's inputs have changed.

• When its inputs are processed (On Input Processed). Each point update is queued and the logic program will run once for each input update. The input updates are queued according to the time at which the server receives the updated values. See On Input Processed Execution for examples and further information.

• When it is triggered by a change to a value in the database

• When the Execute method is triggered by a user, master station schedule, script, automation interface, etc.

How to Stop Logic from Executing

The following applies to logic where the execution method is "On Interval".

On busy systems with large numbers of logic there can be a large amount of Overruns. This is caused when logic is being triggered faster than it can be executed. Some logic only needs to run under certain circumstances and most of the time the logic can be turned off, once it is required a script or other logic will turn it on and when the logic has finished performing its task it can be configured to turn itself off. This is not as easy to achieve as one would think.

Using the method DisableExecution will stop the logic program from executing, however it still loads the logic into the execution queue. With this setting, overruns still occur indicating that the logic is placed in the execution queue. The contents of the logic never execute while execution is disabled.

Using the InService property (set to false) will stop the logic program from executing, however it still loads the logic into the execution queue. With this setting, overruns still occur indicating that the logic is placed in the execution queue. The contents of the logic never execute while execution is disabled (or at least the outputs are never written). The frequency of the overruns increasing is less in this method than the DisableExecution method.

Using the InService property (set to false) and the ExecutionInterval property (set to 0) will stop the logic program from executing and stops the logic being loaded into the execution queue. Using this method will stop the logic overruns from increasing.

Example of turning off a Structured Text Logic Program:

VAR
  InServiceProperty AT %M(.LogicObject.InService) : BOOL;
  ExecutionIntervalProperty AT %M(.LogicObject.ExecutionInterval) : REAL; 
END_VAR
  ExecutionIntervalProperty := 0; (* Disable the logic *)
  InServiceProperty := 0;

Order of Execution

When a logic program is scheduled to run it is added to an execution queue. If there are no other logic programs waiting in the queue the logic program will run immediately. However, if there are other logic programs in the queue or another logic program is already running at that time the logic program will not be executed immediately - it waits in the queue. When the running logic program has executed successfully, the next queued logic program in executed.

Essentially, there are a number of phases to the triggering and execution of a logic program, and every logic program is run sequentially. The important considerations are:

• In each phase of the triggering and execution a Database Write Lock may be held, and long duration activities could affect the performance of the whole database server

• Slow / long duration activities, even those occurring under just a Database Read Lock, will delay the execution of subsequent logic program(s)

A primary example of a 'long duration activity' is the execution of any SQL statement. The SQL activity could be an explicit SQL-initialised variable or could be implicit through the use of Linked-Tables (which are populated behind-the-scenes by ODBC access to another database, which can be very slow and unreliable). Any SQL query compared to a directly accessed variable such as %M, %I or %O is an order of magnitude slower but when used in a single logic program the effects of that SQL query may not be noticeable. However, if used in Templates as the database scales up the impact may become noticeable and as such SQL statements can be too slow to use in logic. When any query is used in logic it needs to be specifically reviewed to ensure the query is as optimal as possible. All queries should be enclosed in NOCACHE declarations otherwise additional performance issues may be observed.

Refer to the Linked Tables section below for additional information regarding queries and linked tables.

Giving proper consideration to what 'long duration activity' means requires an understanding the execution flow of a structured text program:

Triggered Execution

(Triggering / execute from a method or "On Input Processed" => Write Lock)

Gain write lock
  Request to execute...
  Read all ["cache"] input variables and queries. (Avoid using "cached" SQL-initialised variables)
  Add execution request, along with cached inputs values, to the execution queue.
Release write lock.

[small delay]

Gain read lock
  Read all [NOCACHE] input variables and queries (everything declared with NOCACHE; any SQL-initialised variables should be NOCACHE).
Release read lock

Execute

Gain write lock
  Write all outputs
  Execute all methods
  Execute SQL commands
Release write lock

[small delay]

Issue SYSTEM commands.

Scheduled Execution

Gain read lock
  Read all input variables and queries (both cached and non-cached).
Release read lock

Execute

Gain write lock
  Write all outputs
  Execute all methods
  Execute SQL commands
Release write lock

[small delay]

Issue SYSTEM commands.

The [small delay] is because the request gets put on a request queue rather than it being in a sequence, so depending on the current queue size it could be a few milliseconds but could be longer.

If multiple programs are ready to execute, the execution will be interlaced to minimize lock transactions. I.e. two programs A and B are both triggered at the same time the inputs for both programs will be read under the same lock, and the outputs for both will also be written under the same lock:

Get read lock
  Read inputs for program A
  Read inputs for program B
Release lock

Execute A
Execute B

Get write lock
  Write outputs for program A
  Write outputs for program B
Release lock

Whilst this interlacing will increase overall system efficiency, it does mean that if program B is dependent upon the results of program A, you will have problems as program B executes before program A writes its outputs, not even the NOCACHE keyword will help.

Priority

Each logic program can be allocated a priority number (0 by default). If multiple logic programs are set to run at the same time, the priority numbers of the logic programs are used to determine the order in which the logic programs are run. Geo SCADA will run the Logic program with the lowest priority number first. The priority number is only used when multiple logic programs are set to run at the same time. At all other times, the logic programs are run according to the time at which they were added to the execution queue.

If there are Logic programs set to run at the same time and these programs also have the same priority numbers, Geo SCADA will run the logic programs according to the amount of time for which they have been queued. The logic program that has been queued the longest will be executed first.

Priority Example

There are three logic programs: ST Program 1, ST Program 2, and ST Program 3. ST Program 1 has a priority number of 3, ST Program 2 has a priority number of 5 and ST Program 3 has a priority number of 0. All of the ST programs are scheduled to run at 10:00.

A Function Block Diagram named 'FBD 6' has a priority number of 0 and is scheduled to run at 10:01.

At 10:00, Geo SCADA runs ST Program 3 as it has the lowest priority number (0). When ST Program 3 has run, Geo SCADA will run ST Program 1 as it has a Priority number of 3, and when ST Program 1 has run, Geo SCADA will run ST Program 2 as that has the highest Priority number (5).

ST Program 2 is not run until 10:02. The Function Block Diagram 'FBD 6' has not been executed, despite being scheduled to run at 10.01 and having a lower priority number than ST Program 2. This is because ST Program 2 was scheduled to run before 'FBD 6'. The priority number is only used if logic programs are scheduled to run at the same time.

Configuration Settings

Execution Method	Trigger	On Input Change	Executed When
On Input Processed	N/A	N/A	Whenever any of the inputs are processed, regardless of change. See On Input Processed Execution for more clarification.
On Interval	No	No	On every Interval
On Interval	Yes	Yes	On the Interval if the Trigger or any Input has changed since last execution
On Interval	No	Yes	On the interval if any of the inputs have changed since last execution
On Interval	Yes	No	On the interval if the trigger has changed since last execution

Change Detection

• A change is detected if on interval a trigger/input has a different value to that at the last execution.

• If an input/trigger changes but reverts to its original value between intervals the logic will not execute.

Linked Tables

Linked tables in Geo SCADA are a useful feature to provides an integrated environment for all your data. The Geo SCADA database may be linked to other Geo SCADA databases, Microsoft SQL Server, Oracle or any other third party database. The issue with linked tables however is that:

• Typically the linked-table database is located remotely to the Geo SCADA database and so network issues, transient or permanent, such as congestion and TCP packet retries will affect the query's performance and as the query is done under a write lock the performance of the Main server in general

• Connection to third party databases require third party components that are outside the control of Schneider Electric and their behaviour may not be as desired. We have seen some third party which do not respond to query requests from Geo SCADA and so the server deadlocks waiting forever for a reply; with applications such as Excel the lack of a responding query can be easily handled however in the Geo SCADA server it must wait for a reply from the third party components

As such it is not recommended to use linked-tables in logic given it executes at the core level in Geo SCADA. Linked tables in scripting and directly as a list in ViewX and WebX, whilst may still have performance issues due to the network or third party components, will not direct impact Geo SCADA's core functionality.

If data from a third party is required an application may be required to transfer data from that third party into a data table for use by logic, effectively providing a cache.

Go: Home Back