the dss back-end giulio morpurgo, it/co design issues & user interface
TRANSCRIPT
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
B-E + F-E: HOW DOES THE SYSTEM WORK
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.
B-E + F-E: HOW DOES THE SYSTEM WORK
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)
B-E + F-E: HOW DOES THE SYSTEM WORK
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
OPC Optimization Strategy (2/4)
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
OPC Optimization Strategy (3/4)
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
OPC Optimization Strategy (4/4)
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
TOOLS FOR THE EXPERTS
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
TOOLS FOR THE EXPERTS
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
TOOLS FOR THE EXPERTS
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).
TOOLS FOR THE EXPERTS
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 !