The Front-End Software of the DSS: PLC Cycle, Code Structure, and Example

1. The Front-End Softwareof the DSS Stefan Lüders, EP/SFT & IT/CO DSS Advisory Board, March 17th 2003

2. Outline • The PLC Cycle • The Front End Software • Code Structure • The DSS Process Code • The DSS Monitoring Code • An Example The Front-End Software of the DSS

3. Remark This is the Front-End Software V0.9: • It is NOT really fancy nor expert friendly.It can’t be. The HMI is the Back-End. • Dimensions of arrays, functionalities, …might change. The sizes of the data blocks have direct impact on the cycle time. Optimization has NOT been done yet. • Some functionality is NOT even appreciated and will be hidden in the final implementation or by the Back-End. The Front-End Software of the DSS

4. PLC: Main cycle T>Tthres T>Tthres AND Alarm T>Tthres Input: Sensors Output: Action (e.g. switching off power) The PLC Main Cycle The PLC Main Cycle (OB1): • PLCs continuously monitor the sensors • e.g. temperatures, water flow,sub-detector status • Input values are compared to defined thresholds. • Several conditions can be logically combined. Their fulfillment will produce an alarm. • Alarms will trigger defined actions. • Actions are on a coarse level (e.g.cutting power to a complete sub-detector). End-of-Cycle The Front-End Software of the DSS

5. DIN Main Cycle AIN ALE ALM A2A ACT PROC status PLC status DSU status DSS status PROC status PLC status DB ALE DB DIN DB AIN DB ALM DB ACT DB A2A DSU status DSS status The Code Structure • The DSS process code consists of six levels running inside the main cycle. • Each level acts on a corresponding data block (“data driven approach”) • Four different DSS monitor code routines check the status. • All status are stored in additional DBs. The Front-End Software of the DSS

6. Data Blocks • The #entries are fixed at compile time. Each entry corresponds to e.g. a DIN, AIN, a logical function, an alarm, an action. • Sections: • State of the entry, e.g. its value, unused flag, error flags • Parameter, which can be set by the Back-End, e.g. inhibits, acknowledges, resets, trigger, enable / disable entry • Relations to DBs of lower levels, e.g. of an ALM to DIN, AIN or ALE. Relations are transmitted by the Back-End via a special receive buffer to keep consistency. • Collected status of all entries, e.g. an entry has gone off, is inhibited, is in error state • All DBs are different. The Front-End Software of the DSS

7. How a Routine looks like… • All routines are written in a FORTRAN / PASCAL like language (“SCL”). • Each routine uses the DB structure, i.e. loops on all used entries. • State values are determined according the specific rules on relations and parameters. Errors, inhibits, acknowledgements, trigger, resets etc. are considered. • The collected status is managed. • Entries might be enabled or disabled. The latter only, if the entries has NOT gone off. The Front-End Software of the DSS

8. DIN AIN ALE ALM A2A ACT DSU status PROC status DSS status PLC status PROC status PLC status DB ACT DB ALM DB ALE DB AIN DB DIN DB A2A DSU status DSS status The DSS Process Code • DIN/AIN:Reading and checking digital and analog inputs • ALE:Evaluation of different logical functions with DIN and AIN as inputs • ALM:Evaluation of a logical AND with DIN, AIN and ALE as inputs.Triggering of alarms, managing of acknowledges and the alarm sound • A2A:Relations between alarms and actions • ACT:Execution of actions, managing of resets Main Cycle The Front-End Software of the DSS

9. AIN ALE ALM A2A DB DIN DB AIN DB ALE DB ALM DB A2A DB ACT ACT Digital INputs • Digital values are sampled fromthe I/O modules before OB1 starts. • Only used channels are considered (to save time, DIN are processed in groups of 16). • Faulty modules / channels are flagged. The behavior on error must be defined by the GLIMOS: • TriggerOnError, • BeGoodOnError, • InhibitOnError. • DIN can be inhibited or triggered. DIN • Value changes are notified to theDIN history buffer (size currently fixed to 1000 entries) The Front-End Software of the DSS

10. ALE ALM A2A ACT Analog INputs • Analog values are sampled during the AIN routine. Only used channels are considered. DIN • The value is compared to… • upper and lower thresholds, the so-called Virtual AIN (VAIN), • physical boundaries and the previous value, to detect faulty sensors. AIN • The behavior in case of an error, inhibits or trigger is the same as for DIN. • Changes of a VAIN are notified in the AIN history buffer. The Front-End Software of the DSS

11. ALM A2A ACT ALarm Evaluation • The DIN, AIN and VAIN can be combined by four functions: • 4fold AND, 4fold OR • 2 of 3 • analog value comparison Each function has its own DB. DIN AIN ALE • The access is done by an unique addressing scheme, e.g. • DIN: [1…8192] • AIN: [8193…10240,-8193…-10240] • Access errors, i.e. the access to unavailable or unused entries are notified and treated as inhibited. The Front-End Software of the DSS

12. A2A ACT ALarM Trigger • The DIN, VAIN and ALE are combined by a 8fold AND (t.b.c.). DIN • Again access via the unique addressing scheme, e.g. • ALE (AND): [10241…11264] • ALE (2of3): [12289…13312] • Access errors are again notified and treated as inhibited. AIN ALE • ALM can be acknowledged at any time. The alarm is reset after all actions have been executed and the 8fold AND results FALSE. ALM • ALM can be inhibited or triggered. • Changes of an ALM are notified in the ALM history buffer. The Front-End Software of the DSS

13. ACT A2A and ACT • Each ALM can start several actions with different delays (up to 600 seconds in steps of 10s). DIN • A pending A2A inhibits the reset of the corresponding ALM / ACT. AIN • ACT executes the action on the hardware. ALE • ACT can be reset, if no A2A are pending and the corresponding ALM has been acknowledged. ALM • The behavior in case of an error, inhibits or trigger is the same as for DIN. A2A • Changes of a ACT are notified in the ACT history buffer. The Front-End Software of the DSS

14. PROC status DSS status DSU status PLC status PROC status PLC status DSU status DSS status The DSS Monitor Code • Every status is collected in a corresponding DB. • The status is determined by… • event-based interrupts in case of coming / going failures • periodic interrupts to queries specific information • The PROC, DSU and DSS status are queried every second. • The PLC status is queried… • every second for the H-CPUs • every minute for the communication • every hour for all modules • All statuses are queried at warm or cold start, when the system enters the redundant mode or on Back-End request. DIN AIN ALE ALM A2A ACT The Front-End Software of the DSS

15. PROC status PLC status DSU status DSS status The DSS Monitor Code • “PROC” is based on the collected state of the DBs. PROC status PROC status: Channel / module error Access / Value error Alarms, Actions Inhibits • “PLC” monitors the CPU / ET crates and the commu-nication to the OPC server. PLC HW / SW status: Warm / Cold starts Power failure Module failure I/O access error Redundancy error CPU memory mismatch CPU timing error OK flag PLC status • Errors are persistent and must be reset. • Fatal errors harm the PROC chain. Some I/Os are unprocessable. DSU status DSU status: PS / UPS status CPU / ET crate status • “DSU” monitors all entities inside a DSU. DSS status DSS status: Alive signal PROC status PLC status DSU status • “DSS” wraps up all of the above and provides an alive signal. The Front-End Software of the DSS

16. DIN ALE ALM A2 ACT An Example • A PT100 (ET #4, Module #2, Channel #1, HW addres #1024) is monitoring the temperature of a bottle of wine. The upper threshold is set to 30°C (SORRY!). AIN • If T>30°C “ValueTooHigh” goes off and leads to an alarm. • After 20s, the action (ET #4, Module #3, Channel #1, HW address #257) is triggered. The action can be reset if the alarm has been acknowledged. • Remarks: Positive safety is currently NOT applied here. And the Back-End will NOT allow for delayed actions. Be invited to the lab ! The Front-End Software of the DSS