(00) Basic concepts
R. Trausmuth
Senior Developer, ETM Austria
The Datapoint Concept
The Manager Concept
PVSS Installation
A New Project (PVSS Project Management)
A New Datapoint (PVSS UI Para)
PVSS Configs
PVSS Alert Concept
The Datapoint Concept
process-variables of a valve
commands
response
opening
opening
engine start
opened
engine stop
closed
....
engine runs
....
malfunction
list-oriented datapoint concept
data-points rigidly organized in one-dimensional lists
difficult to understand
every process variable is a single data-point
difficult to maintain
individual groups of components divided up into a lot of
datapoints
modifications necessary at many different places
object-oriented data-point concept
valve
commands
opening
response
malfunction
status
opening
opened
engine runs
closed
objectoriented datapoint concept
DP is actual representation of an object
defined by name (and type)
type modifications will modify all instances (= datapoints)
of this type
elements may have several attributes (configs) for further
processing parameters
current value
value change
alert handling
peripheral address
archiving details
types of datapointelements
valve
structure
commands
structure
response
structure
opening
float
malfunction
bool
status
structure
opening
float
opened
bool
simple types
complex types
unsigned int
multilang. text
integer
reference
character
array
boolean
dyn. list
bitpattern
structure
floating point
blob
closed
bool
engine runs
bool
text
date / time
a datapointelement and its configs
valve
structure
commands
structure
opening
float
response
structure
malfunction
structure
status
structure
opened
bool
periphery address
closed
bool
value range
conversion E-> R
default value
...
engine runs
bool
opening
float
periphery address
value range
smoothing
conversion R -> E
...
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
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)
10
Addressing Data Points (1)
Six parts of the address:
[system:]dpName.[dpElement(s)]:config.[detail].attribute
system:
name of the PVSS system
dpName:
name of the data point
dpElement:
element name of the DP type
config:
attribute group
detail:
detail number of the attribute group
Expressions
in [ ] are optional
attribute:
real value of an attribute
Several items are separated by periods
11
Addressing Data Points (2)
valve
Example:
structure
commands
structure
opening
float
response
structure
malfunction
structure
original value
default value
online value
peripheral address
status
structure
opening
float
opened
bool
closed
bool
engine runs
bool
value range
command conversion
[system:] dpName. [dpElement(s)] : config. [detail] .attribute
valve1.commands.opening:_online.._value
12
Objects in PVSS
Real world representations in PVSS consist of
A datapoint object
Holds all relevant data for the object
A graphical object
Knows how to display the data
13
Objects
datapoint object
graphical object
open
D
closed
V06N23
open
V06N23
R
closed
malfunction
M
engine_runs
14
creating objects: the usual way
V1.R.open
V1.R.closed
V1
V1.M.malfunction
V3
V1.M.engine_runs
V3
V1
V3.R.open
V3.R.closed
100
V2
V3.M.malfunction
0
V3.M.engine_runs
V2
V2.R.open
V2.R.closed
V2.M.malfunction
V2.M.engine_runs
15
creating objects: references
$valve=V1
$valve=V3
V3
$valve
V1
100
V2
0
$valve=V2
$valve.R.open
$valve.R.closed
$valve.M.malfunction
$valve.M.engine_runs
16
creating panels: the usual way
detail-view station 05
V05N12
Overview
detail-view station 06
V06N12
pump station 5
V07N12
detail-view station 07
pump station 6
V07N03
100
pump station 7
V07N04
0
17
creating panels: the object oriented way
Overview
detail-view station $StatNr
V12N05
V12N06
V12N07
pump station 5
V12N05
V12N06
V03N07
$StatNr=06
100
pump station 6
V12N05
V12N06
V04N07
0
pump station 7
$valve=V03$StatNr
$valve=V04$StatNr
$valve=V12$StatNr
$valve
18
The Manager Concept
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 ?
Centralized systems
One single process data image
All components connect to this image
-> values in central image are always consistent
20
managers overview
UIM
UIM
Ctrl
DM
UIM
API
user interface layer
processing layer
communication and
EV
memory layer
driver layer
21
driver layer
software protocol
smoothing
PVSS
smoothing
(reduction of the dataflow)
data-type transformation
conversion
(raw value engineers value)
conversion
transformation
old / new
SW telegram
HW/kernel
22
Event Manager
administers data points
administers user authorization
contains and administers the current
process image
EV
receives and evaluates messages
distributes messages to other managers
only one Event Manager per PVSS system
23
Database Manager
high-speed database for
archiving process status
parallel historical value-archives
DM
administration of the system
parameterization
last values
internal SQL-SELECT interface
24
Control Manager
Complex processing of data points
Interpreter with syntax similar to C
Multithreading capability
Time- or event-controlled
Large scope of functions
Ctrl
(loops, procedures)
Extensible by User
-> CtrlExt dll
25
API-Manager
C++ class library
All PVSS-Managers based on API
API
Full PVSS-access
Integration of existing software
Can set up own managers with specific functions
Integration of PVSS functions for specific projects
26
User-Interface-Manager / Runtime
Graphic visualization of messages
received by EV
Animation of graphic components
Forwarding the user entries to EV
User log on/off
27
User-Interface-Manager / PARA
Online parametrization
Graphical datapoint-type editor
Datapoint-treeview
Para uses CTRL-scripts
and panels
Drag & drop
DP-groups
28
User-Interface-Manager / System Management
Configuration via
standard-panels
Database
Reporting etc.
29
User-Interface-Manager / Diagnostic, Debugging
System-State, Memory
Manager Connections
Message Statistic
CTRL-Script Debugger etc.
30
Online-Help
Full-featured HTML-based online-help
including full text search, bookmarks, etc.
31
PVSS Installation
In case "autostart" is disabled ...
33
New entry in the start-menu
entry for PVSS
entry for dongle
34
Get hardware code...
35
... order license file ...
nameOfComputer
nameOfComputer 12345678901
36
... and install it
37
The shield-file
Hardware-Code
Hostname and Shield-Code
Valid until ...
Features of the license
38
PVSS Project Administration
Project administration
Lists all projects installed
on this computer;
Shows their PVSS-Version
and currend state
40
Create new standard project ...
41
... name, languages and path ...
<projectDir>
42
... confirm settings
<projectDir>
43
PVSS-directory / project-directory
44
Open the PVSS-Console ...
<projectName>
<projectName>
45
... append new manager or set individual options .
<projectName>
46
... or edit config file ...
<projectName>
47
... and start project
Starts entire
project
<projectName>
Process Monitor;
already running
Default-Manager;
automatically added
by PVSS when
Starts individual
managers
setting the project;
not yet running
48
Managers start one after the other ...
<projectName>
already running
about to start
not yet running
49
... until the project is up and running
<projectName>
<projectName>
50
PVSS UI Para
Object-oriented datapoint concept
valve
commands
opening
response
malfunction
status
opening
opened
commands
response
closed
engine_runs
52
Access PARA
53
PARA in detail
Hides
system datapoints"
Predefined standard
datapoint types
Standard datapoints
Reduces display to datapoints
corresponding to filter criteria
determined.
for experiments"
Predefined standard
datapoint types
54
Task
Technical object "motor driven flap"
Which object properties ?
Structuring all properties
Implementation of the structure with
the PARA-module
55
Properties of object
flap
defaults
opening
response
malfunction
status
end_of_travel
opened
motor_temp
running
opening
closed
56
Open Dp-Type-Editor ...
right
click
57
... insert name of root-node
58
Insert node after node ...
59
... set type of node ...
60
... finish tree ...
61
... and save
62
Create datapoint ...
63
... and save
64
Datapoint and it's configs
65
PVSS Configs
Basics
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 DatapointElement. And those which can be added to a variety of types will then have
a different set of Attributes, depending on the type of the DPE.
Configs (21 different kinds) and their Attributes (depending on the Config
from 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").
67
Alert handling
Defining the discrete status
of a value
Links certain alert-classes
to certain value- ranges
Discrete
alerts
68
Alert class
Selects a certain
acknowledgement type
Defines the characteristics
of an assigned alert range
69
Basics - PowerConfig
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 hold
it's individual amount of Configs and/or individual values for the Attributes of a
Config (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 for
every new Datapoint of a certain Type again and again.
70
Basics
Solution (1):
Would it be possible to add Configs right to a DP-Type, all Datapoints of this
Type would get them (compare: "class -> instance"; Module Para).
Beside this is not possible in PVSS, it would imply that all DPs of that Type
do 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"
will always be different), there is a special kind of Datapoint standing between
the 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 as
belonging to a Master-DP.
71
Basics
Solution (2):
As some of the Attributes of a Power-Config will be identical for all DPs of a
Type, but some will be/have to be different or have to be changeable
afterwards, 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", ....
72
Basics
Result (1):
If there is a Master-Datapoint existing and a new Datapoint is going to be
generated, the DP-Type is handing over the information about it's structure
and the Master-Datapoint about the Configs and their Attributes.
As the Configs and their Attributes can't just be copied, there has to be a
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 something
fixed, but is just a Control-Script. And this Control-Scripts can be modified
by the user!
73
Basics
Result (2):
To set up a Power-Config utilizes basically the common dialogs of the
Para-Module. Entered values are not written directly to the database as it is
done by "normal" Configs, but they are promoted to the Configuration of that
Power-Config. The Configuration is performing it's commands/calculations
and when finished, writes the values to database.
If a new Datapoint is going to be generated, the Configuration of the used
Power-Configs are called also and the values for the (dynamic) Attributes of
the new DP are written to the database by them.
There is a predefined set of Power-Configs with default values for their
Attributes 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 some
Power-Configs bundling such Configs to one.
74
PVSS Alert Concept
Definitions (1)
Alert:
Triggered when one status changes to another
Alert range:
Range, defining the discrete status of a value.
Alert class:
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
76
Definitions (2)
alert range
upper alert limit
alert went
warning range
warning came
upper warning limit
warning went
good--range
good
warning went
lower warning limit
warning came
warning range
alert went
lower alert range
PVSS- value range
alert came
alert came
alert range
77
Alert Status
alert range (A)
type of
acknowledgment: 4
warning range. (W)
type of
acknowledgement: 2
good range (G)
state of alert
handling:
current range:
acknowledgement
G
OK
W
came
came /
unack
A
went /
unack
came
OK
executed alert:
W came
A went
W went
A came
78
Acknowledgement = Canceling
came
cam
e
aknow.
went
no alert
79
Not acknowledgeable
came
came
went
no alert
80
Came can be acknowledged
came /
unacknowledged
aknow.
came /
acknowledged
came
went
went
no alert
81
Alert pair requires acknowledgement
came /
unacknowledged
aknow.
came /
acknowledged
came
went
came
went /
unacknowledged
aknow.
went
no alert
82
Came and Went require acknowledge
came /
acknowledged
went
aknow.
went
came / went
unacknowledged
aknow.
came
came /
unacknowledged
came
came
went /
unacknowledged
aknow.
no alert
83
Group Alerts Basics (1)
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 handlingconfig will not watch the datapoint-element itself, instead it can watch the
states of any other alert handling-configs somewhere in the database.
Such an alert handling-config is called group alert. It will summarize the state
of other alert handling-configs, e.g. if one changes to the state alert came
unacknowledged, the group alert will also change to that state....
Such a group alert can be used to indicate that there is something wrong in a
part of the project.
84
Group Alerts Basics (2)
Solution:
Alerts are (always) display in a panel ( = a graphical attribute of an graphicobject 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 paneltopology can be used to scan all contained panels if there is somewhere a
link to a alert handling-config. They can be summarized by a group alert and
displayed somewhere....
85
Group Alerts Basics (3)
Result:
The wizard for the panel topology is also responsible for setting up group
alerts. Each node (e.g. panel) of the topology containing a sub-node will
receive a group alert responsible for the sub-nodes. As all nodes are
connected to the root node, there will be a cascade of group alerts from
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 be
special objects in the standard-catalogue to do this. The navigation-buttons
in 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 this
group alert to indicate that there is somewhere on a panel of the topology
a pending alert displayed.
86
Configure AES settings
87
Open AES
88
Control Scripts
What a CTRL script does
Processes changes in the data points
Animates screen objects
Links data points to screen attributes
Creates a user guidance system
Controls system states
90
Control Language
Syntax similar to C
Interpreter
No compiling, no linking
Time- or event-driven
Multithreading (parallel processing)
91
Types of execution
Spontaneous:
Changes in a data-point attribute automatically trigger a CTRL
function.
After user input:
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.
92
main()
Each script has a main() function.
The main() function (normally) does not have a parameter.
The main() function is executed first.
The curled brackets form the
statement-block
main()
{
...
...
}
93
Declaration of Variables
Syntax:
<variable typ> <variable name>;
Examble:
int
x;
variable types:
int
float temperature;
float
bool pump_on;
bool
string user;
string
...
94
Syntax of a Ctrl- Function
Parameters
Definition
function([typ var [, ....]])
Start
{
typ var;
Local variables
...
Instructions of
the function
statements;
....
....
End
95
dpGet() / dpSet()
query / modify a datapointelements
attributes:
dpGet(<DP attribute>, <variable>)
dpSet(<DP attribute>, <value>)
Example:
dpGet("valve1.commands.opening:_online.._value",
opening_value);
dpSet("valve1.commands.opening:_original.._value",
40.5);
96
dpConnect()
To enter a callback function to monitor
changes in values of DP attributes:
dpConnect(<Callback>, <DP attribute>)
Example:
dpConnect("workCB",
"valve1.response.opening:_online.._value");
97
Control Editor: Syntax highlighting
98
