The DSS Back-end Giulio Morpurgo, IT/CO Design issues & User interface.

The DSS Back-end

Giulio Morpurgo, IT/CO

Design issues & User interface

Table of contents

Back-end goals and users Back-end + Front-end : how does the system work

Configuration Monitoring OPC Optimization Strategy

Tools for the Expert Some Open Issues Conclusion / Future Developments

PROPAEDEUTICS

THE REAL THING

WORK IN PROGRESS…

Back-end goals and Users : three profiles Operator

Needs to see, at a glance, what is going on Needs to react : acknowledge/ reset Needs tools to get more detailed information

Configurator (“GLIMOS”) Defines the Safety by configuring and connecting the DSS

entities (Sensors, Alarms, Actions) Has the responsibility for temporarily disabling part of the system

DSS Expert Assists the Configurator (for instance in testing the Alarm

Conditions, but also whenever help is needed) Needs access to all information to solve possible problems

BACK-END GOALS AND USERS

Data Flow between Front-end and Back-end

PLC DATABLOCKS

OPC

PVSS DATAPOINTS

PVSS CTRL MANAGER

MONITOR

CONFIGURE

PVSS ARCHIVE

ARCHIVE MANAGER

TREND

B-E + F-E: HOW DOES THE SYSTEM WORK

MAPPING

SAFETY PART

SMS/EMAIL

PLCDATABLOCKS

DSS Dataflow (2)

PVSS DATAPOINTSOPC

CTRL MANAGER

CONFIGURE-

MONITOR


SAFETY PART

THE

HARDWARE

THE

USERS

The DSS PVSS Control Script : event driven 1) Define all “queries” and “connections” (dpConnnect,

dpQueryConnectSingle) 2) Sleep until a datapoint element referred by the queries

or the dpConnect is modified Start Find who called and why Perform necessary action (modify some datapoint) Go back to sleep

2bis) In some cases, 2) will modify another datapoint element associated with another query or dpConnect, and therefore 2) is repeated again.


One complex datapoint element, one handler Be careful with “parallel threads”: do not use two

handlers to update the same “list”.

DATAPOINT ELEMENT (Ex. ALARM_ACTION_LIST)

ROUTINE 1

ROUTINE n

QUERY INITIALISATION

EVENT HANDLERS

ROUTINE 2

write

read

read

write

PVSS VARIABLE

modify

modify

CONTROL SCRIPT

EVERY MODIFICATION OF A DPE REQUIRING AN UPDATE OF THE ALARM_ACTION_LIST (NEW ALARM, NEW ACTION, ACKNO, RESET, ETC…) HAS TO PASS THROUGH THE SAME HANDLER (ROUTINE 1)


CONFIGURATION

Configuration General Principles(1/3) The DSS system is fully “data-driven”; “configuring” the

DSS ultimately means changing the data on which the Front-end “safety” code is operating

CONFIGUREOPC

PLC DATABLOCKSPVSS DATAPOINTS

USER INPUT

The configuration process is incremental. New data items can be added at any time without perturbing the operation on the already defined ones

Configuration General Principles (2/3) What has to be configured

Hardware (Crates and Modules), from PLC Configuration File Logistic Entities (Geographical Locations, Subsystems)

Basic Entities : THE CORE OF THE DSS SYSTEM Input Channels Alarm Conditions Output Channels (== Actions) Alarm-Action relationships

Auxiliary Entities (Sensor Types, Channel Classes) Access Control (Users and their privileges)

Configuration General Principles (3/3)

Making it easier

Whenever possible, options are selected from a list

Coherent design of the different panels

Coherent usage of colors through the interface (ex. yellow = action on datapoint, cyan = no action, orange = compulsory …)

CONSISTENCY CHECKS on User Input

…. (filtering, auxiliary entities, “copy” button)

Still to be defined : logging of modifications

The Configuration Panel

This panel gives access to the specialized panels dedicated to the different configuration operations.

The actual configuration actions are restricted to privileged users (GLIMOS). The normal Operator can only view the current configuration.

(directly reachable from the Back-end Front Panel)

Hardware configuration : “Show modules” panel

This panel shows to the User

• A list of the I/O modules in his DSS system

• The features (type, address, number of channels, hardware address …) of each module

• The current allocation state of the module (which sensors or actuators are connected to the module)

The Back-end extracts the information about crates and modules from the “PLC configuration file”, and creates the corresponding PVSS datapoints.

For consultation only : The User does not have

to edit this panel

Logistic entities : user-defined classification of DSS items Every entity (input channel,

alarm condition, action) - belongs to a subsystem - is attached to a location

-Locations - user defined - tree structure - used by the system to build

the synoptic tree -Subsystems

- user defined - used to filter selection list

INPUT CHANNELS

ALARM CONDITIONS

ACTIONS (OUTPUT CHANNELS)

Subsystem Configuration

LIST OF DEFINED ITEMS

LIST OF MODIFIED ITEMS

PARAMETERS

RELATIONS AND DYNAMIC INFORMATION

ACTION ON DATAPOINTNO ACTION ON DATAPOINT

Geographical Location Configuration

X and Y will determine the position on the synoptic panel

Click here to see all items currently attached to this location

LO_lab_rack1

LO_lab

ROOT

DSS Main Entities (defining the detector Safety)

Input and Output channels correspond to real hardware User configured

Logical Conditions Autom. derived from the Inputs Input value versus thresholds Used by the Alarm Conditions

Alarm Conditions are “software” (data) entities User defined Mapped into the PLC memory

Alarm-to-Action Link Alarms to Actions OUTPUT CHANNELS (ACTIONS)

ALARM-TO-ACTION RELATIONS

LOGICAL CONDITIONS

INPUT CHANNELS (DIGITAL, PT100, 4to20mA)

ALARM CONDITIONS

LEVEL2 SUBCONDITIONS

- N_OF_M

- COMPARE

EXIST ALSO IN THE FRONT-END

Configuring the DSS Main Entities

Mapping the Front-end representation (OPC items) Determine the position of an entity in the corresponding Front-

end datablock (next slide) Define the OPC addresses

Checking the consistency of the User’s input Ex. Low threshold < High threshold Ex. High threshold < Max. Physical Value Ex. An Alarm Condition can effectively become true or false.

Track the interdependences among the different entities which Inputs are used by which Alarm which Actions are triggered by which Alarm

THE FOLLOWING THINGS HAVE TO BE IMPLEMENTED IN THE BACK-END DATAPOINTS AND IN THE CONFIGURATION PANEL SCRIPTS

Determination of the position of an item in the corresponding Front-end datablock Items corresponding to real hardware (I/O channels)

The position is determined from the address of the I/O module to which the channel is attached (and from the channel number)

“Software” items (Alarm Conditions, Alarm-to-Action relationships, N_OF_M, COMPARE) The Back-end uses some PVSS datapoints as “allocation lists”

for these entities. Every time a new item has to be created, an entry is removed

from the corresponding “free” list. If later on the item is deleted, the corresponding entry is added

again to the “free” list.

Analogue Channel Configuration (4to20mA)

THE FIELDS “SENSOR TYPE” AND “CHANNEL CLASS”

ENABLE THE USER TO FILL THE SECTIONS BELOW WITH

PREDEFINED VALUES

PHYSICAL MIN and MAX define the physical range for the Sensor, and

are used to convert from real numbers to the 16-bit acquisition

value

Here is where 4to20mA and PT100 are different (for PT100 these values

are predefined)

REASONABLE MIN and MAX define a range out of which the Sensor value should be considered wrong (ex. The temperature in an office will never go

below 0). The goal is to avoid false alarms

TOO_LOW and TOO_HIGH define the thresholds out of

which the situation has to be considered as potentially

dangerous and an Alarm could be generated

The WARNING values are entirely treated at the

Back-end level. They are not part of the Safety

Chain

From MODULE_NAME and CHANNEL the system gets the position in the F-E datablock,

and the “Channel Index”

(for an Analogue Channel the index goes from 8193 to 9216)

NEW: the Copy button will copy all parameters (apart

from Name, Module, Channel) of an existing datapoint to a new one

PLEASE NOTE THAT THIS FIELD IS NOW CALLED “CHANNEL”. IT

DEFINES THE INDEX OF THE POSITION (IN THE I/O MODULE)

TO WHICH THE SENSOR IS ATTACHED

THE FIELD “MODULE NAME” WILL LET THE USER

SELECTING A I/O MODULE ONLY AMONG THE ONES

SUPPORTING 4to20mA SENSORS

PT100 Configuration

FOR A PT100 “CLIMATE” TEMPERATURE SENSOR, SOME PARAMETERS ARE

PREDEFINED AND CANNOT BE MODIFIED BY

THE USER. THEY ARE MARKED IN GREY

THE “ON FAILURE” BEHAVIOR CAN BE SET TO

IGNORE (==inhibit on error)

OPTIMIST(==use value like if sensor was good)

PESSIMIST(==trigger on error)

(this applies also to 4to20mA and digital sensors)

Digital Input Channel Configuration

THE SYSTEM WILL NOT LET THE USER

SELECTING A CHANNEL ALREADY OCCUPIED

SIMPLER THAN THE ANALOGUE CHANNEL CASE, BUT THE BASIC STRUCTURE OF THE PANEL (AND

ALSO OF THE SOFTWARE BEHIND) IS THE SAME

Alarm Condition Configuration (1/5) An Alarm Condition is a logical expression of values and

logical states of one or more Input Channels In the DSS Front-End implementation, an Alarm

Condition is a “N_OF_M” function of up to 8 sub-conditions.

Each sub-condition is either An elementary comparison (Analogue Sensor TOO HIGH (or

TOO_LOW), Digital sensor TRUE). A “N_OF_M” function of up to 8 elementary comparisons. A “COMPARE” function, where the difference between two

analogue values is compared with a threshold value. Every element (elementary comparison, N_OF_M or

COMPARE function) can also be negated.

Alarm Condition Configuration (2/5) A SIMPLE CONDITION : ALARM IS TRUE IF |PT_8193-PT_8194|>2.0

IF THE ACTIONS ARE DISABLED, THE

FRONT_END WILL PROCESS THE ALARM, BUT IT WILL NOT TRIGGER THE

ACTIONS EVEN IF THE ALARM WAS TRUE

IF THE ALARM WAS “DISABLED”, IT WOULD

NOT BE PROCESSED BY THE FRONT-END

THIS ALARM USES ONLY ONE SUB-CONDITION, OF

THE “COMPARE” KIND

THIS IS THE ID THAT THE SYSTEM HAS

ALLOCATED FOR THIS ALARM

WHILE 12239 IS THE ID ALLOCATED FOR THE

“COMPARE” FUNCTION

Alarm Condition Configuration (3/5)

A “TOO_HIGH” condition means comparing the measured value for an

analogue sensor with the “TOO_HIGH” threshold defined in the sensor

configuration.

Once more, the User is assisted by the system, that

presents a list of all the defined analogue sensors.

The list could even be filtered if the User had selected a

specific Subsystem

Alarm Condition Configuration (4/5) A MORE COMPLEX ALARM CONDITION

THIS BLOCK READS LIKE

IF DI_261 OR NOT DI_262

THE DIFFERENT POSSIBILITIES FOR THE USER WHEN DEFINING A SUB-CONDITION TYPE.

THE “ALE” OPTION IS USED TO SELECT AN

ALREADY DEFINED SUB-CONDITION

THE “HIDE”, “SHARE” and “CLONE” buttons are used to reserve, share or

copy a sub-condition

Alarm Condition Configuration (5/5) Consistency checks before validating the Alarm

Condition and writing it into the PVSS Datapoint Detect repetitive usage of sensors Detect repetitive usage of sub-conditions Fully test the Alarm Condition, to detect “contradiction” that would

make the Condition always True or always False. To do this : Make a list of all sensors used more than once One sensor at a time, assign to the sensor the different logical

values, while keeping the other sensors used by the Condition as undefined : for each case compute the Condition value

Verify that the values are neither all True, nor all False

Connecting Alarms with ActionsSELECT AN ALARM : THE

ACTIONS CURRENTLY CONNECTED TO IT WILL

BE LISTED.

TO CONNECT AN ACTION, SELECT IT FROM THE LIST.

TO DISCONNECT AN ACTION, CLICK IN THE “DELETE” FIELD

A DELAY BETWEEN THE ALARM AND THE ACTION

CAN BE SPECIFIED

Configuring Alarm Help for the Operators

TO BE REFINED …

VIA THIS PANEL THE USER CAN FILL

1) ALL THE INFORMATION THAT THE OPERATOR

WILL BE SHOWN WHEN LOOKING AT THE

DETAILS OF AN ALARM

2) THE SMS AND EMAIL ADDRESSES THAT

SHOULD BE NOTIFIED

(NOT YET IMPLEMENTED)

Editing a Sub-condition A Sub-condition used in one or

more Alarm Condition can be modified if

Its shared flag is set

The modification will not break the correctness of one of the Alarms

IN THIS CASE, THE MODIFICATION IS REJECTED, AS IT WOULD MAKE THE ALARM “AL_BERTO” WRONG

THE USER CAN MODIFY THE SUB-CONDITION WHILE VIEWING THE OLD

SETTING

THE USER CAN TEST THE MODIFICATION BEFORE SAVING IT

LIST OF THE SHARED “N_OF_M”

LIST OF THE SHARED “COMPARE”

Configuring an Action (==Output Channel)

VERY SIMILAR TO CONFIGURING A DIGITAL INPUT

AS THESE ARE THE THINGS THAT COULD

SWITCH PARTS OF YOUR

DETECTOR OFF, IT IS GOOD

PRACTICE TO USE

MEANINGFUL NAMES AND

DESCRIPTIONS

Sensor Types and Channel Classes

THESE TWO PANELS ENABLE THE USER TO DEFINE CONFIGURATIONS THAT CAN BE LATER INHERITED BY SEVERAL INPUT CHANNELS

“PHYSICAL” PROPERTIES, USED IN CONVERTING BETWEEN RAW ACQUISITION

VALUES AND REAL NUMBERS

“LOGICAL” PROPERTIES, USED IN ALARMS, WARNINGS AND DETECTION OF FAULTY

SENSORS

IN THIS CASE THE PARAMETERS

ARE PREDEFINED

“Frequent” modifications : Inhibiting a SensorIT COULD HAPPEN THAT AN

ALARM IS TRIGGERED BECAUSE A SENSOR IS GIVING

A WRONG VALUE

IF THIS IS THE CASE, AFTER HAVING CHECKED

EVERYTHING, THE SENSOR HAS TO BE INHIBITED IN

ORDER TO RESTORE THE DETECTOR’S OPERATIONAL

CONDITIONS

THIS PANEL ENABLES THE USER TO SET/RESET A

INPUT INHIBIT

IT SHOWS

1) A LIST OF ALL THE INHIBIT SENSORS

2) THE CURRENT STATE OF THE SENSOR

3) THE CONSEQUENCES OF THE SET/RESET

OPERATION

IF PT_8194 IS INHIBITED, AL_8194 WILL BECOME FALSE, BUT THE SYSTEM WILL NOT

BE ANYMORE ABLE TO EVALUATE AL_CAPONE

“Frequent” modifications: Change a Threshold

SENSOR PT_8194 IS MEASURING 22.77

DEGREES. IT IS MARKED AS “TOO_HIGH”, AS ITS “HIGH” THRESHOLD IS SET AT 20 DEGREES

CHANGING THE TOO_HIGH THRESHOLD FROM 20 to

25 DEGREES WOULD CHANGE THE SENSOR

STATE FROM “TOO_HIGH” TO NORMAL

THIS COULD HAVE AN IMPACT ON THE CURRENT

STATE OF THE ALARMS USING PT_8184.

THE USER CAN TEST THIS IMPACT BEFORE

ACTUALLY CHANGING THE THRESHOLD

IN PARTICULAR, THE ALARM AL_8194 WOULD

CHANGE FROM “TRUE” TO “FALSE”

Configuring Users and Access Rights It goes without saying that all

the configuration operations described until now can only be carried out by authorized Users

The normal Operator will only have “Read” and “Ack-Reset” rights.

The privileges currently available depend on who is logged in on the Front Panel. In case of necessity, a GLIMOS can login, and later logout, without having to restart the Front Panel

PANEL TO CREATE DSS USERS AND ESTABLISH THEIR ACCESS RIGHTS

MONITORING

Monitoring Goals

INFORM Put under the Operator’s eyes a complete overview of the current

DSS status (Alarms, Actions, Sensors)

RESTORE Enable the Operator to easily take the necessary “normality

restoring actions” (acknowledge Alarms, reset Actions)

UNDERSTAND Give access in a friendly way to more detailed information, useful

to better understand the DSS behavior

Monitoring Panels

INFORM & RESTORE Front Panel

UNDERSTAND Detail Panels Summary Panels Trend Panels Synoptic Panels

The DSS Front Panel

HERE ALL THE CURRENTLY ACTIVE ALARMS AND ACTIONS ARE DISPLAYED.

THE OPERATOR ACKNOWLEDGES THE ALARMS AND RESETS THE ACTIONS BY CLICKING HERE.

MORE DETAILED INFORMATION ARE AVAILABLE BY CLICKING HERE

THIS BUTTON GIVES ACCESS TO THE EXACT SEQUENCE OF EVENTS

CHANNELS OUT OF RANGE, IN WARNING, INHIBIT OR FAULTY ARE DISPLAYED HERE

AN ALARM IS “MASKED” IF THE FRONT-END IS UNABLE TO EVALUATE IT (DUE TO INHIBIT OR BROKEN SENSORS)

SHOW SYNOPTIC PANELS

SHOW CONFIGURATION PANEL

SHOW SUMMARY PANELS

HISTORY TABLE, WHERE ALL THE EVENTS ARE SHOWN

CLICK HERE TO CHANGE WHO IS LOGGED IN

Summary of Alarm Condition status

BY CLICKING ON AN ALARM NAME, A DETAILED VIEW OF THAT ALARM WILL APPEAR

THE ALARM IS TRUE (RED) BECAUSE (AT LEAST) 2 OF ITS SUBCOMPONENT (1 and 4) ARE TRUE

Summary of Analogue Input Channel status

SELECT CHANNELS TO BE DISPLAYED

CLICK HERE TO SHOW TREND

CLICK HERE TO SEE DETAILS

CLICK HERE TO POPUP TREND SELECTION

THE UNITS ARE AUTOMATICALLY RESCALED, SO THAT THE TOO_HIGH AND TOO_LOW LINES ARE OK FOR ALL CHANNELS

TOO HIGH

TOO LOW

TOO HIGH

TOO LOW

WARNING HIGH

WARNING LOW

Archive strategy

A new value is archived for an Analogue Input if The new value differs by more than “delta” from the last archived

value (delta = (TOO_HIGH-TOO_LOW)/50). The new value crosses a threshold (ex. Last archived value was

“TOO LOW” and new value is not “TOO LOW”, or viceversa)

If the value needs to be archived, the Control Script writes it into the .Archive.Value datapoint element of the corresponding datapoint. This datapoint element defines the PVSS archive config.

Also the state transitions of Alarms, Actions, Digital and Analogue channels are archived.

Synoptic (a first implementation) From the Front Panel the Operator can initiate the synoptic navigation.

Here is what a synoptic page looks like.

CURRENT LOCATION

SUB-LOCATIONS

THE SHOW BUTTON GIVES ACCESS TO THE LIST OF ITEMS (SENSORS, ALARMS, ACTIONS) ATTACHED TO A LOCATION

A synoptic page is automatically generated for every user-defined geographical location. It displays the “children” (sub-locations) of the current location.

The navigation tree and the “Back” and “Home” buttons can also be used to navigate.

The synoptic page displays a summary of the abnormalities associated with the current location and with its children.

By clicking on a sublocation the user will navigate to the corrispondent page.

SUMMARY STATUS

OPC Optimization Strategy (1/4)

The total amount of “state” information contained in the PLC datablocks (for a fully configured system) is of the order of 100 kbytes.

A permanent OPC monitoring of all this information would create serious delays in the refresh rate of the OPC items that are actually modified.

Therefore, we needed to improve our strategy

OPC OPTIMIZATION


1) Regroup information which needs constant monitoring Creation of bit arrays containing, for instance, the status of the

alarms and of the actions, the sensors out of range etc. Creation of an integer array containing the raw values of the

analogue sensors.

2) Regroup information only needed “on demand”, and automatise the activation/deactivation of their monitoring. OPC items of this category are grouped into different OPC

groups, so that each OPC group would roughly cover 1 Kbyte. OPC groups are activated only when needed (for instance to

show the details on an alarm, or of an input channel), and deactivated afterwards. This is done automatically.

OPC OPTIMIZATION


Automatic activation/deactivation of OPC Groups To each OPC group we associate a “visibility counter” datapoint The OPC group is activated (by the Control Script) when the

counter goes from 0 to positive, and deactivated when the counter goes back to 0

The counter is incremented every time the Back-end needs information associated with an OPC Item attached to the group If an Alarm becomes TRUE, we would like to update the detailed

information of all the Input Channels used by the Alarm The same if the details of an Alarm are displayed The same if an Input Channel is out of range, or if its details are

displayed… The counter is decremented when the information is not needed

anymore (ex. when a detail panel is closed)

OPC OPTIMIZATION


Results: 2176 bytes (10 OPC items) are monitored constantly, with a

refresh rate of 500 ms. (Alarm triggers/errors/masked, sensor triggers/errors, action trigger/errors).

2048 bytes (7 OPC items) are monitored constantly, with a refresh rate of 2 secs. (Level2 triggers/errors, alarm-to-action triggers/errors, digital input raw data).

2048 bytes, corresponding to the Analogue values, have been divided in 5 OPC items, refreshed every 3 secs.

The items modified are received by the Control Script, that finds which bits were changed and updates the corresponding datapoint elements

Every other OPC item is only monitored while its information need to be presented to the Operator.

OPC OPTIMIZATION

Tools for the Experts

In addition to the Configuration and Monitoring panels, several facilities have been added, to ease the maintenance of the DSS system in case of problems.

These “Service facilities” enable the Expert to get a more immediate access to the information contained in the PVSS datapoints, in order to reduce the time needed to fix a problem.

In the next slides we will show a few examples

Expert Tools : OPC Group Monitoring Via this panel the Expert can monitor and control the

activation state of the different OPC Groups

TOOLS FOR THE EXPERTS

Expert Tools : Import/Export of datapoint elements The Expert can easily create text files containing the parameters assigned to

one or more DSS objects. These files can be also read back by the system


Example of parameter file for a PT100 sensorOmissis

Omissis

PT_8193.Definition.Location LO_OPC_Corner

PT_8193.Definition.Subsystem SU_GENERAL

PT_8193.Definition.ModuleName A__DSU_2__6

PT_8193.Definition.SlotNumber 1

PT_8193.Definition.Index 8193

PT_8193.Config.OnFailure IGNORE

PT_8193.Config.TooLow 15

PT_8193.Links.UserCount 3

PT_8193.Links.UserList 3

AL_CAPONE

AL_PACINO

AL_8193

THE LINES “Omissis” REFER

TO PARAMETERS THAT HAVEN’T

BEEN DEFINED BY THE USER


Example of parameter file for an Alarm Condition OmissisOmissisAL_CAPONE.Definition.Location LO_OPC_CornerAL_CAPONE.Definition.Subsystem SU_DETECTOR1AL_CAPONE.Definition.Lev1_Dp 8 11 AAM_COMP_12339AL_CAPONE.Definition.Lev1_Op 8 11 COMPAREAL_CAPONE.Definition.Lev1_Sign 81 1 1 1 1 1 1 1 AL_CAPONE.Definition.Lev2_Dp 64 31 PT_81932 PT_81943 2.0AL_CAPONE.Definition.Lev2_Op 64 31 A2 A3 VAL_CAPONE.Definition.Lev2_Sign 641 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 AL_CAPONE.Definition.Index 16435AL_CAPONE.Definition.Type ORAL_CAPONE.Definition.Nmin 1AL_CAPONE.Definition.OnDoubt DO NOT TRIGGERAL_CAPONE.Links.UserCount 0AL_CAPONE.Links.UserList 0AL_CAPONE.A2A_list 0


Expert Tools : reading back parameters from F-E The Configuration Parameters of the different DSS

entities are transmitted from the B-E to the F-E via OPC For OPC optimization reasons, they cannot be kept

under constant monitoring. To read them back :

Creation of a new OPC Group “DSS_READBACK” For every DSS entity type, creation of a “read-back” datapoint Dynamic reconfiguration of the OPC addresses of the read-back

datapoint elements, to match the addresses of the DSS entity whose F-E parameters need to be checked

Comparison between the F-E parameters (accessible through the read-back datapoint) and the B-E parameters (contained in the elements of the PVSS datapoint corresponding to the DSS entity).


Some Open Issues

Logging/Tagging of configuration modifications into ORACLE Database : define goals->implementation

Adding sophistication to the synoptic pages

Connecting to the “External Systems”

Making our data available to the DCS

Defining operational procedures for upgrades/testing/maintenance

Logging/Tagging of Configuration Modifications Logging modifications is easy

Define ORACLE tables (one for every kind of entity you want to log)

Every time an entity changes, copy it into a newly created record in the corresponding table.

Examining the modification history is also easy Just retrieve the right records from the database

Reloading old configurations in a consistent way is not so easy Hardware might have changed Interdependencies between entities

To avoid useless developments, the real User’s needs must be well understood

OPEN ISSUES

Synoptic pages

What level of sophistication is needed in the graphic representation ?

If drawings of the experimental areas are required, who has to provide them ?

Who is going to use the synoptic pages, and how ? DSS is a “Automatic Safety System”, not a Control System. The DSS Operator can only perform “Safe” actions (acknowledge

Alarms and reset Actions). For every Alarm the Configurator can define the instructions that

the Operator has to follow to try and restore normal Operation conditions. These instructions are displayed when looking at the details of the Alarm, but are executed outside the DSS.

OPEN ISSUES

Connecting to “External Systems”

OPEN ISSUES

Making our data available to the DCS Two reasons to keep things apart

The DSS is a “Safety System”. Access to its PVSS datapoints from outside should be prevented.

DSS naming convention (Digital Inputs == DI_..., PT_100 sensors == PT_...)

A possible solution (simple and easy to implement) The DSS datapoints containing information interesting for the

DCS will have a “.DCS_name” datapoint element. This element will contain the DCS name of the DCS datapoint

where the information should be put. When the information is modified on the DSS side, the Back-end

will copy the information into the specified DCS datapoint.

OPEN ISSUES

Operational Procedures (for testing, upgrading, maintenance) Once more, real needs have to be understood. Operational scenarios have to be defined

An idea for the implementation of the DSS “working modes” Define “software switches” : similar to digital inputs, but the value

is set by the User (GLIMOS). These “switches” will be mapped into a Front-end datablock. They can be used in the Alarm Condition definitions. Ex. If a given Alarm is not wanted in “Shutdown” mode, its Alarm

Condition could contain an “AND (NOT SHUTDOWN)”, where SHUTDOWN is a software switch.

OPEN ISSUES

Conclusions / Future developments (1/3) The DSS Back-end is now fully operational

It is easy and intuitive to use (user friendly), both for configuring and for monitoring

It is powerful (flexibility, easy access to full information) Critical parts (OPC) have been well optimized, so that even the

largest configurations should not cause problems

The DSS Back-end is Fully PVSS based Designed in a modular way

It is easy to add new parts It is easy to incorporate new requirements

This is good news, because …

SUMMING UP

Conclusions / Future Developments (2/3)

Some well defined developments Ex. Incorporating Stefan’s PLC Back-end monitoring inside this

application Adding new Expert Facilities

Work on the Open Issues mentioned before Logging/retrieval of configuration modifications Synoptic pages “External Systems” Link to the DCS Operational Procedures

And, above all …

… for quite some time the DSS Back-end will be an evolving application.

SUMMING UP

Conclusions / Future developments (3/3) …playing with the system in the “Real World”, to

get experience and User’s feedback.

BYE-BYE !

The DSS Back-end Giulio Morpurgo, IT/CO Design issues & User interface.

Documents

Transcript of The DSS Back-end Giulio Morpurgo, IT/CO Design issues & User interface.