database share out_basics
DESCRIPTION
software usage basics computing computers database basicTRANSCRIPT
� The Datapoint Concept
� The Manager Concept
� PVSS Installation
2
� A New Project (PVSS Project Management)
� A New Datapoint (PVSS UI Para)
� PVSS Configs
� PVSS Alert Concept
process-variables of a valve
M
commands response
opening opening
engine start opened
engine stop closed
4
engine stop closed
.... engine runs
.... malfunction
list-oriented datapoint concept
� data-points rigidly organized in one-dimensional li sts� difficult to understand
� every process variable is a single data-point
� difficult to maintain
5
� difficult to maintain
� individual groups of components divided up into a l ot of
datapoints
� modifications necessary at many different places
opening
commands
malfunction status opening
response
valve
object-oriented data-point concept
6
Mopened
engine runs
closed
object–oriented datapoint concept
� DP is actual representation of an object
� defined by name (and type)
� type modifications will modify all instances (= dat apoints) of this type
� elements may have several attributes (configs) for further
7
� elements may have several attributes (configs) for further processing parameters
� current value� value change� alert handling� peripheral address� archiving details
simple types complex types
unsigned int multilang. text
integer reference
character array
boolean dyn. list
types of datapointelements
valvestructure
commandsstructure
openingfloat
responsestructure
malfunctionbool
statusstructure
openingfloat
8
boolean dyn. list
bitpattern structure
floating point blob
text
date / time
M
openedbool
closedbool
engine runsbool
openingfloat
commandsstructure
malfunctionstructure
statusstructure
openingfloat
responsestructure
valvestructure
M
a datapointelement and it‘s configs
9
openedbool
closedbool
engine runsbool
periphery address
value range
smoothing
conversion R -> E
...
periphery address
value range
conversion E-> R
default value
...periphery address
default value
...
Datapoint address
� A full datapoint addess consists of 6 parts:
� [System:]Datapoint.[Element][.Element]:config.[detail].attribute
� System is optional, default is local system
10
� Elements might be organized as tree• Root element is .• Element levels are separated by .
� Details are used for specail cases only, might be empty in most cases
� Internally, a datapoint address is represented by 7 numbers (including the datapoint type)
Six parts of the address:Six parts of the address:
system: name of the PVSS system
dpName : name of the data point
[system:]dpName.[dpElement(s)]:config.[detail].attr ibute
Addressing Data Points (1)
11
dpName : name of the data point
dpElement: element name of the DP type
config: attribute group
detail: detail number of the attribute group
attribute: real value of an attributeExpressions in [ ] are optional
Several items are separated by periods
Example:Example:
openingfloat
commandsstructure
malfunctionstructure
opened
statusstructure
openingfloat
responsestructure
valvestructure
Addressing Data Points (2)
12
valve1.commands.opening:_online.._value
[system:] dpName. [dpElement(s)] : config. [detail] .attribute
openedbool
closedbool
engine runsbool
original valuedefault value
peripheral address
value range
command conversion
online value
Objects in PVSS
� Real world representations in PVSS consist of
� A datapoint object� Holds all relevant data for the object
13
� A graphical object� Knows how to display the data
V06N23
Dopen
closed
datapoint object graphical object
Objects
14
V06N23
V06N23 Ropen
closed
Mmalfunction
engine_runs
100
V1
V3V1
V3
V1.R.open
V1.R.closed
V1.M.malfunction
V1.M.engine_runs
V3.R.open
V3.R.closed
creating objects: the usual way
15
0
100
V2
V2
V3.R.closed
V3.M.malfunction
V3.M.engine_runs
V2.R.open
V2.R.closed
V2.M.malfunction
V2.M.engine_runs
$valve
100
$valve=V1
$valve=V3
V1
V3
creating objects: references
16
0
$valve=V2
V2
$valve .R.open
$valve .R.closed
$valve .M.malfunction
$valve .M.engine_runs
Overview
pump station 5
detail-view station 05 V05N12
detail-view station 06 V06N12
detail -view station 07 V07N12
creating panels: the usual way
17
pump station 6
pump station 7
detail -view station 07
0
100
V07N04
V07N03
V07N12
Overview
pump station 5
$StatNr=06
detail-view station $StatNr
100
V12N05V12N06V12N07
V12N05V12N06V03N07
creating panels: the object oriented way
18
pump station 6
pump station 7
$valve$valve =V03$StatNr$valve =V04$StatNr$valve =V12$StatNr
0
V12N05V12N06V04N07
Basic system architecture
� Possible control system architectures
� Distributed systems• Servers provide process data• Clients connect to servers and get data on demand
− -> time synchronization of values ?
20
− -> time synchronization of values ?
� Centralized systems• One single process data image• All components connect to this image
− -> values in central image are always consistent
user interface layer
processing layerCtrl API
UIM UIM UIM
managers overview
21
driver layer
EV
D DD
DM communication and
memory layer
PVSS
smoothing
conversion
� software protocol
� smoothing
(reduction of the dataflow)
� data-type transformation
D
driver layer
22
transformation
SW telegram
old / new
� data-type transformation
� conversion
(raw value ���� engineer’s value)
HW/kernel
� administers data points
� administers user authorization
� contains and administers the current
process image
Event Manager
EV
23
� receives and evaluates messages
� distributes messages to other managers
� only one Event Manager per PVSS system
EV
� high-speed database for
archiving process status
� parallel historical value-archives
� administration of the system
Database Manager
DM
24
parameterization
� last values
� internal SQL-SELECT interface
� Complex processing of data points
� Interpreter with syntax similar to C
� Multithreading capability
� Time- or event-controlled
Control Manager
Ctrl
25
� Large scope of functions
(loops, procedures)
� Extensible by User
� -> CtrlExt dll
� C++ class library
� All PVSS-Managers based on API
� Full PVSS-access
Integration of existing software
API-Manager
API
26
� Integration of existing software
� Can set up own managers with specific functions
� Integration of PVSS functions for specific projects
� Graphic visualization of messages
received by EV
� Animation of graphic components
� Forwarding the user entries to EV
User-Interface-Manager / Runtime
27
� User log on/off
� Online parametrization
� Graphical datapoint-type editor
� Datapoint-treeview
� Para uses CTRL -scripts
User-Interface-Manager / PARA
28
Para uses CTRL -scripts
and panels
� Drag & drop
� DP-groups
� Configuration via
standard-panels
� Database
� Reporting etc.
User-Interface-Manager / System Management
29
� System-State, Memory
� Manager Connections
� Message Statistic
� CTRL-Script Debugger etc.
User-Interface-Manager / Diagnostic, Debugging
30
Project administration
40
Lists all projects installed
on this computer; Shows their PVSS-Version
and currend state
... and start project
<projectName>
Process Monitor;already running
Starts entire
project
48
Default-Manager;automatically added
by PVSS when
setting the project;not yet running
Starts individual
managers
Managers start one after the other ...
<projectName>
already running
49
not yet running
about to start
opening
commands
malfunction status opening
response
valve
Object-oriented datapoint concept
52
opened
closed
engine_runs
commands
response
Reduces display to datapoints
Hides„system datapoints"
Predefined standard
datapoint types
PARA in detail
54
Reduces display to datapoints corresponding to filter criteria determined.
datapoint types
Standard datapoints
for „experiments"
Predefined standard
datapoint types
� Technical object "motor driven flap"
� Which object properties ?
� Structuring all properties
Implementation of the structure with
Task
55
� Implementation of the structure with
the PARA-module
opening
defaults
opening
response
flap
Properties of object
56
opening
end_of_travel
motor_temp
malfunction
opened
running
closed
status opening
� Motivation:
Configs are a kind of "functional unit" providing the possibility to add special functions or a certain behavior to a Datapoint-Element.
As Datapoint- Elements could be of different types (structure, float, bool, ...), it is not possible to add every kind of Config to every kind of Datapoint-Element. And those which can be added to a variety of types will then have
Basics
67
a different set of Attributes, depending on the type of the DPE.
Configs (21 different kinds) and their Attributes (depending on the Configfrom 2 up to more than 70) are predefined and can not be altered by the user.
The Config "_lock" and the virtual Config "_common" do exist on every DPE,the Config "_original" only on DPEs whose type is not structure (compare "Para Module").
� Defining the discrete statusof a value
� Links certain alert-classes to certain value- ranges
Alert handling
68
�Discrete alerts
� Selects a certain acknowledgement type
� Defines the characteristicsof an assigned alert range
Alert class
69
� Motivation:
If a Config is added to a Datapoint- Element, this is done locally only.No other Datapoint (even of the same type) will get this Config on that DPE(compare: Alerthandling on Flap f1 and f2).
Thus the same DPE of a different Datapoint (even of the same type) can holdit's individual amount of Configs and/or individual values for the Attributes of a
Basics - PowerConfig
70
it's individual amount of Configs and/or individual values for the Attributes of aConfig (e.g. Flap f1 could act totally different to f2 because of it's different Configs).
But Datapoints are the representation of technical objects. And technical objects of the same type will behave in a similar or in the same way. Thus Datapoints of the same Datapoint-Type will have the same Configs and their Attributes will have almost the same values.
Hence it would be desirable not to set up the Configs and it's Attributes forevery new Datapoint of a certain Type again and again.
� Solution (1):
Would it be possible to add Configs right to a DP-Type, all Datapoints of thisType would get them (compare: "class -> instance"; Module Para).Beside this is not possible in PVSS, it would imply that all DPs of that Typedo have the same Configs and most of all the same values for the Attributes.
As this will not be proper for all of the Configs (e.g. Attributes of "_address"
Basics
71
As this will not be proper for all of the Configs (e.g. Attributes of "_address"will always be different), there is a special kind of Datapoint standing betweenthe Datapoint-Type and the "normal" Datapoints. This special DPs are called"Master" and are acting as a crossover of DP-Type and DP.
This Master-DPs do contain special Configs called "Power-Configs".This is not a new kind of Configs, but should mark ordinary Configs asbelonging to a Master-DP.
� Solution (2):
As some of the Attributes of a Power-Config will be identical for all DPs of aType, but some will be/have to be different or have to be changeableafterwards, they are called "Dynamic Attributes".
As Power-Configs will act in different ways to the user, they are called "fixed","variable", "fixed with variable parts", "fixed but calculated automatically", ....
Basics
72
"variable", "fixed with variable parts", "fixed but calculated automatically", ....
� Result (1):
If there is a Master-Datapoint existing and a new Datapoint is going to begenerated, the DP-Type is handing over the information about it's structureand the Master-Datapoint about the Configs and their Attributes.
As the Configs and their Attributes can't just be copied, there has to be akind of rule how this information is promoted to the new Datapoint.
Basics
73
kind of rule how this information is promoted to the new Datapoint.This rules are called "Configuration of a Power-Config".
The real power of a Power-Config is that the Configuration is not somethingfixed, but is just a Control-Script. And this Control-Scripts can be modifiedby the user!
� Result (2):
To set up a Power-Config utilizes basically the common dialogs of thePara-Module. Entered values are not written directly to the database as it isdone by "normal" Configs, but they are promoted to the Configuration of thatPower-Config. The Configuration is performing it's commands/calculationsand when finished, writes the values to database.
Basics
74
If a new Datapoint is going to be generated, the Configuration of the usedPower-Configs are called also and the values for the (dynamic) Attributes ofthe new DP are written to the database by them.
There is a predefined set of Power-Configs with default values for theirAttributes and their Configuration.
As some Configs are mostly set in combination (e.g.: Address, Command-/Message-conversion, PVSS value range and Smoothing) there are also somePower-Configs bundling such Configs to one.
Alert:Triggered when one status changes to another
Alert range:Range, defining the discrete status of a value.
Alert class:
Definitions (1)
76
Defines the characteristics of an assigned alert range.
Priority:Importance of an alert
came:Transition t o a state of alert
went:Transition f r o m a state of alert
warning came
alert went
warning went
alert came upper alert limitupper alert limit
warning rangewarning range
valu
e ra
nge
alert rangealert range
Definitions (2)
77
warning came
alert went
warning went
warning went
alert came
warning came
upper warning limitupper warning limit
goodgood--rangerangelower warning limitlower warning limit
warning rangewarning range
lower alert rangelower alert range
alert range alert range
PV
SS
-va
lue
rang
e
alert range (A)type of
acknowledgment: 4warning range. (W)
type of acknowledgement: 2
good range (G) acknowledgement
Alert Status
78
state of alert handling:
current range:
executed alert:
„G“
OK„W“ came
„A“
came / unack
„A“
went / unack
„W“
came
„G“
OK
G W A W G
W came
A came
A went W went
came / came / unacknowledgedunacknowledged
came
came / came / acknowledgedacknowledgedaknow.
„Came“ can be acknowledged
81
no alertno alert
camewent went
came / came / went / went /
came / came / unacknowledgedunacknowledged
aknow.
came
went
Alert pair requires acknowledgement
82
came / came / acknowledgedacknowledged
no alertno alert
went / went / unacknowledgedunacknowledgedcame
aknow.went
came / came / acknowledgedacknowledged went
went
came / went came / went unacknowledgedunacknowledged
aknow. aknow.came
„Came“ and „Went“ require acknowledge
83
came / came / unacknowledgedunacknowledged
no alertno alert
went / went / unacknowledgedunacknowledgedcame
aknow.came
came
� Motivation:
There are three different ways to use the alert handling-config:On a datapoint-element of type “digital”, on datapoint-element of type “analog”and on a datapoint-element neither nor. In the last case the alert handling-config will not watch the datapoint-element itself, instead it can watch the
Group Alerts Basics (1)
84
states of any other alert handling-configs somewhere in the database.Such an alert handling-config is called “group alert”. It will summarize the stateof other alert handling-configs, e.g. if one changes to the state “alert cameunacknowledged”, the group alert will also change to that state....Such a group alert can be used to indicate that there is something wrong in apart of the project.
� Solution:
Alerts are (always) display in a panel ( = a graphical attribute of an graphic-object is linked via a control-script to the state of an alert handling-config).Panels can be organized by the means of the panel topology. So the panel-topology can be used to scan all contained panels if there is somewhere a
Group Alerts Basics (2)
85
topology can be used to scan all contained panels if there is somewhere alink to a alert handling-config. They can be summarized by a group alert anddisplayed somewhere....
� Result:
The wizard for the panel topology is also responsible for setting up groupalerts. Each node (e.g. panel) of the topology containing a sub-node willreceive a group alert responsible for the sub-nodes. As all nodes areconnected to the root node, there will be a cascade of group alerts fromthe bottom to the top of the tree.
Group Alerts Basics (3)
86
the bottom to the top of the tree.As a group alert is a config, it has to be established on a datapoint-element.Thus there will be a special datapoint for each node of the topology.As the state of a group alert will be shown on a graphic-object, there will bespecial objects in the standard-catalogue to do this. The navigation-buttonsin the templates will do this also. As there is always the button “Start”(responsible for the root-node of the topology), there will be at least thisgroup alert to indicate that there is somewhere on a panel of the topologya pending alert displayed.
� Processes changes in the data points
� Animates screen objects
� Links data points to screen attributes
What a CTRL script does
90
� Creates a user guidance system
� Controls system states
� Syntax similar to C
� Interpreter
� No compiling, no linking
Control Language
91
� Time- or event-driven
� Multithreading (parallel processing)
Spontaneous:
Changes in a data-point attribute automatically tri gger a CTRL
function.
After user input:
Types of execution
92
The CTRL script is executed only if started by user . It does not
automatically react to changes in the data-point.
Cyclical:
The script is executed at regular time intervals.
� Each script has a main() function.
� The main() function (normally) does not have a para meter.
� The main() function is executed first.
� The curled brackets form the
main()
93
� The curled brackets form the
statement-block main()
{
...
...
}
Syntax:
<variable typ> <variable name>;
Examble: variable types:
int x ; int
Declaration of Variables
94
int x ; int
float temperature; float
bool pump_on; bool
string user; string
...
function([typ var [, ....]])
{
typ var;
...
Start
Local variables
Definition Parameters
Syntax of a Ctrl- Function
95
...
statements;
....
....
}
Instructions of the function
End
query / modify a datapointelement‘s query / modify a datapointelement‘s attributes:attributes:
dpGet(<DP attribute>, <variable>)
dpSet(<DP attribute>, <value>)
dpGet() / dpSet()
96
dpSet(<DP attribute>, <value>)
dpGet("valve1.commands.opening:_online.._value", opening_value);
dpSet("valve1.commands.opening:_original.._value", 40.5);
Example:Example:
To enter a callback function to monitor To enter a callback function to monitor changes in values of DP attributes:changes in values of DP attributes:
dpConnect(<Callback>, <DP attribute>)
dpConnect()
97
dpConnect("workCB", "valve1.response.opening:_online.._value");
Example:Example: