Transcript Industrial Automation.

Industrial Automation
Automation Industrielle
Industrielle Automation
4
Application Layer Protocols
4.1
Device Management Protocols
protocolos de gestión de dispositivos
Protocoles de gestion des appareils
Gerätezugangsprotokolle
SNMP and friends
http://tinyurl.com/IAevaluation1
Contents
Device Management Protocols.
Application layer protocols offering remote services for large networks of devices:
- Monitoring (health of devices and network, get current state)
- Management (deployment, configuration, change settings)
4.1.1 current loop 4..20 mA
4.1.2 HART
4.1.3 SNMP: Simple Network Management Protocol
4.1.4 MMS: Manufacturing Messaging Specification
Industrial Automation
2013
Device access protocols 4.1 - 2
4.1.1 Current Loop
The classical solution for analogue values
Example differential pressure transducer
4..20 mA current loop
Reminder:
fluid
Industrial Automation
2013
Device access protocols 4.1 - 3
4.1.2 HART
Data over 4..20 mA loops
Practically all 4..20mA devices come equipped with HART today
About 15 Mio devices are installed worldwide.
Reminder:
Reminder:
more info: http://www.hartcomm.org/
http://www.thehartbook.com/default.htm
Industrial Automation
2013
Device access protocols 4.1 - 4
The Round card
http://www.fint.no/ha-i4012.pdf
The round card is a standardized printed circuit board
that can be mounted in an instrument, containing the
modem, a processor, RAM, EPROM and all the logic
and software necessary to execute the HART protocol.
It is round because most hydraulic instruments have a
round case.
Industrial Automation
2013
Device access protocols 4.1 - 5
HART commands summary
Master
Request
Slave
Indication
time-out
Response
Confirmation
Universal Commands
• Read manufacturer and
device type
• Read variable and units
• Read current output and
percent of range
• Read up to four predefined
dynamic variables
• Read/write tag, descriptor,
date
• Read/write 32-character
message
• Read device range values,
units, and damping time
constant
• Read or write final assembly
number
• Write polling address
Industrial Automation
2013
Common Practice
Commands
Device-Specific Commands
(example)
• Read selection of up to four
dynamic variables
• Write damping time constant
• Write device range values
• Calibrate (set zero, set span)
• Set fixed output current
• Perform self-test
• Perform master reset
• Trim variable zero
• Write variable unit
• Trim DAC zero and gain
• Write transfer function (square
root/linear)
• Write sensor serial number
• Read or write dynamic
variable assignments
• Read or write low-flow cut-off
• Start, stop, or clear totalizer
• Read or write density
calibration factor
• Choose variable (mass, flow,
or density)
• Read or write materials or
construction information
• Trim sensor calibration
• enable PID, write PID setpoint
• Valve characterization
• Valve setpoint
• Travel limits
• User units
• Local display information
Device access protocols 4.1 - 6
Device access
device
volumetric flow rate
type
FlowPro
manufacturer
ABB
volumetric flow rate
3 cm2
cross sectional area:
field device
pipe inside diameter
network
adapter
handheld
device
SCADA
2 cm
velocity
13.32 m2/s
diff. pressure
9.8
Pa
density
0.8
kg/l
network
adapter
network
modem
adapter
4-20 mA loop for HART
13.32
Industrial Automation
2013
9.8
0.8
Device access protocols 4.1 - 7
4.1.3 SNMP
Simple Network Management Protocol
Industrial Automation
2013
Device access protocols 4.1 - 8
Simple Network Management Protocol
IETF (Internet standard) protocol for device and network management
(widely supported, especially by routers, switches, servers, workstations, printers…).
Configuration Management
 Keeping track of device settings
Fault management
 Dealing with problems and emergencies
(router stops forwarding, server loses power, etc)
Performance Management
 How smoothly is network running?
 Can it handle the current workload?
Industrial Automation
2013
Device access protocols 4.1 - 9
SNMP - MIB objects
networked
device
MIB
Agent
TCP/UDP/IP
NT network
DHCP
WINS
Appletalk
Nowell
IPX
DecNet
…..
CISCO
Device contains MIB
(managed information base)
and an agent to access MIB
(171 objects)
(90 objects)
(14 objects)
(70 objects)
(proprietary)
Mostly parameters, statistics and error counters used for communication
Industrial Automation
2013
Device access protocols 4.1 - 10
SNMP – ASN.1 Object example
tcpMaxConn OBJECT-TYP
SYNTAX
Integer32 (-1 | 0..2147483647)
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The limit on the total number of TCP connections the entity
can support. In entities where the maximum number of
connections is dynamic, this object should contain the
value -1."
::= { tcp 4 }
tcpActiveOpens OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The number of times that TCP connections have made a direct
transition to the SYN-SENT state from the CLOSED state.
Discontinuities in the value of this counter are
indicated via discontinuities in the value of sysUpTime."
::= { tcp 5 }
http://net-snmp.sourceforge.net/docs/mibs/TCP-MIB.txt
Industrial Automation
2013
Device access protocols 4.1 - 11
Example SNPM Network
Industrial Automation
2013
Device access protocols 4.1 - 12
SNMP - Access to Managed Objects
User
object interface
managed
information
base
Manager
call
(request)
reply
Agent
call
reply
(confirm)
UDP
IP
ISO 8802-2 Type 1
ISO 8802-3
(Ethernet)
MIB
(response)
management
messages
(indication)
UDP
IP
ISO 8802-2 Type 1
ISO 8802-3
(Ethernet)
network
Industrial Automation
2013
Device access protocols 4.1 - 13
SNMP - Operations on objects
Operations (PDU type):
Get
(read)
Set
(write)
GetNext
(transversal reading)
GetBulk
(optimized GetNext, v2 and v3)
Response
(variable bindings and acknowledgement)
Trap
(asynchronous agent notification, priorities)
Since SNMPv1/SNMPv2 do not provide authentication, “Set” commands are
normally disabled. Traps are rarely used.
Industrial Automation
2013
Device access protocols 4.1 - 14
Example Network and Queries
Industrial Automation
2013
Device access protocols 4.1 - 15
SNMP - How are objects identified ?
ISO defined a world-wide
addressing scheme on a
hierarchical basis:
MIB objects are identified by a
concatenation of numerical
identifiers
quite wasteful, but bearable in LANs
Industrial Automation
2013
Device access protocols 4.1 - 16
SNMP example of identification
.1.3.111.3.37.238.9999.1.1.2 ==
.iso.org.ieee.standards-association-c-series-standards.std-c37.part238.
ieeeC37238TSMib.ieeeC37238Objects.ieeeC37238DefaultDS.ieeeC37238DefaultDSClkIdentity
Industrial Automation
2013
Device access protocols 4.1 - 17
SNMP - Assumptions about the underlying communication network
- the network is connectionless (datagrams): only UDP is used (no TCP).
- manager and agent can send messages to each other spontaneously
- all entities must be able to receive and send packets of at least 484 octets
- the network supports broadcast
Further reading: www.wtcs.org/snmp4tpc/files/reference/francois/snmp.ppt
Industrial Automation
2013
Device access protocols 4.1 - 18
4.1.4 MMS
Program
Invocation
Named
Variable
Named
Variable List
Domain
Types
Operator
Station
Transaction
File
Journal
Semaphore
Event
Condition
Event
Action
Event
Enrolment
Manufacturing Messaging Specification (MMS)
Industrial Automation
2013
Device access protocols 4.1 - 19
MMS - Application field
schedule
robot
configuration
Numerous conveyors, robots, CNC machines, paint shops, logistics.
Download from production management, connection to administration.
Industrial Automation
2013
Device access protocols 4.1 - 20
Interaction between Operator Workplace and field equipment
SCADA (client)
(any technology)
network
(any)
controller (server)
(any technology)
represents automation objects,
i.e. a collection of PLC1 variables
manufacturing devices
represent pieces of equipment
MMS: we want to access all controllers, regardless of the manufacturer, in the same way.
Industrial Automation
2013
Device access protocols 4.1 - 21
The basic MMS idea: read a variable
client
(any technology)
request
read
response
variable name
value
status
network
(any)
server
I / O devices
basic MMS idea: read and write equipment variables using standard messages.
Industrial Automation
2013
Device access protocols 4.1 - 22
MMS - Manufacturing Message Specification
Developed 1980 for the MAP project (General Motor’s flexible manufacturing initiative)
Reputation: heavy, complicated and costly (due to poor implementation)
But:
• Boeing adopted MMS as TOPs (MMS on Ethernet)
• Adopted by the automobile industry and power distribution
Standardized as:
[1]
ISO/IEC 9506-1: Industrial Automation systems - Manufacturing Message Specification Part 1: Service Definition (IS 1990)
[2]
ISO/IEC 9506-2: Industrial Automation systems - Manufacturing Message Specification Part 2: Protocol Specification (IS 1990)
Industrial Automation
2013
Device access protocols 4.1 - 23
MMS - Concept
MMS (Manufacturing Message Specifications) defines:
• A set of standard objects which must exist in every conformant device, on which
operations can be executed (example: local variables, read and write) or which
can start a transmission spontaneously
• A set of standard messages exchanged between a manager and an agent station
for the purpose of controlling these objects
• A set of encoding rules for these messages
• A set of rules for exchanging messages between devices (basic protocol)
MMS does not specify application-specific operations (e.g. change motor speed).
This is covered by application-specific, “companion standards”
(e.g. flexible manufacturing, drives, remote meter reading)
Industrial Automation
2013
Device access protocols 4.1 - 24
MMS - Manufacturing Message Specification
MMS does not specify
the application interface
device
device
Application
MMS specifies a set
of messages which
allow an MMS client
to control an MMS
server
MMS specifies a set
of objects which
an MMS server is
expected to contain
MMS
client
request
Application
MMS
server
response
(command)
(reply)
communication
stack
MMS specifies how
messages are
encoded for
transmission
Industrial Automation
2013
linking
device
communication
stack
network
router
Device access protocols 4.1 - 25
MMS - Basic Communication Principles
MMS assumes that the communication stack offers two services:
MMS Requester
(client)
Request
network
MMS Responder
(server)
Indication
1) Remote Procedure Call
(Call paired with reply,
synchronous, unicast)
processing
Confirmation
2) Event Reporting
(spontaneous messages sent
by server)
Response
event
Request
Indication
Addressing not specified, messages contain communication reference to identify
connection. Usually, clients/servers are addressed by IP address and MMS server
uses port number 102.
Industrial Automation
2013
Device access protocols 4.1 - 28
MMS - Event services
MMS provides services to:
- Event Condition (define the boolean condition that triggers an event and its priority)
- Event Enrolment (define the MMS client(s) to notify when an event is triggered)
- Event Action (define the MMS confirmed service to be executed when the event occurs)
MMS client
enables/disables
event conditions
MMS client
(MMS server)
Event
Enrolment
Event
Condition
Event
Action
Who?
When?
What?
event notification
and confirmation
Events are the most complicated part of MMS
Industrial Automation
2013
Device access protocols 4.1 - 29
MMS - Event triggering
MMS client
MMS client
MMS Server
NETWORKTRIGGERED
Event
Enrolment
Event
Condition
boolean
variable
Event
Action
MONITORED
cyclic monitoring
plant
events are triggered by a change in a boolean variable in the server (monitored event) or
by an MMS client (trigger event) as an invitation procedure
Industrial Automation
2013
Device access protocols 4.1 - 30
VMD: Virtual Manufacturing Device
Definition of objects, services, and behavior
• Only specifies the network-visible aspects (device / application communication)
• Internal implementation details (programming language, operating system, CPU
type, input/output (I/O) systems) not specified by MMS
 interoperability
robot
flow meter
cell
Virtual
Device
Virtual
Device
Virtual
Device
Application Programming Interface
(MMSI = MMS interface)
communication
presentation
stack
session
Program
Invocation
Named
Variable
Named
Variable List
Domain
Types
Operator
Station
Transaction
Journal
File
Semaphore
Event
Condition
Event
Action
Event
Enrolment
transport
network
link
physical
Industrial Automation
2013
Device access protocols 4.1 - 31
Industrial Automation
Automation Industrielle
Industrielle Automation
4
Application Layer Protocols
4.2
Open Process Control (OPC)
OPC: Open Process Control
Manufacturer-independent application programming interface (API) for automation
- To implement clients which can access plant data coming from remote devices
(PLCs, field bus devices, real-time databases) easily
- Set of commands to access OPC servers
OPC clients
- read and write process variables, read alarms and events and acknowledge alarms,
and retrieve historical data from data bases according to several criteria
- Implemented on automation platforms (e.g. ABB Ax800), which may act themselves
as an OPC server to publish their data, events and historical data.
OPC server
- Supplied by manufacturer of automation devices supplies
- Communicates with its devices through a proprietary protocol
- Manages several devices of the same type, several servers can run in parallel and
each server can be accessed by several clients in the same network
Industrial Automation
2013
Device access protocols 4.1 - 35
OPC Overview
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 36
4.2.1 What is OPC ?
Industry standard set up by the OPC Foundation (http://www.opcfoundation.org/)
specifying the software interface (objects, methods) to a server that
collects data produced by field devices and programmable logic controllers.
API
covered by the
OPC standard
application
(OPC client)
OPC server
X
OPC server
(simulator)
servers
OPC server
Y
:
Ethernet
Field bus
PLCs Brand X
PLCs Brand Y
Sensors/Actors
Industrial Automation
2013
Device access protocols 4.1 - 37
Before OPC
visualization
history
data base
MasterBus
MMS driver
ABB PLCs
Industrial Automation
2013
XWAY
driver
Profinet
driver
Télémécanique PLCs
Siemens PLCs
Device access protocols 4.1 - 38
With OPC
Operator
Historian
(Information
Manager)
application software is
written independently from
the type of controller
the drivers still exist,
but the clients do not
see them anymore
ABB AC800M
Industrial Automation
2013
ABB
OPC server
Schneider
OPC server
Siemens
OPC server
MMS
XWAY
ProfiNet
Télémécanique TSX
Siemens S7
Device access protocols 4.1 - 39
Importance of OPC
• Greatest improvement in automation since IEC 61131.
• More than 150 vendors offer OPC servers to connect their PLCs,
field bus devices, displays and visualization systems.
• Used for data exchange between applications and for accessing databases
• Three major components:
1) OPC - DA = Data Access (widespread, mature)
2) OPC - AE = Alarms and Events
3) OPC - HDA = Historical Data Access
… and some profiles* (batch,…)
* A “profile” is a subset or a specialization of a standard to form a stricter standard, adapted
to an application. E.g. 100 Mbit/s, full-duplex, fibre-optical Ethernet is a profile of IEEE 802.3.
Industrial Automation
2013
Device access protocols 4.1 - 40
Specification 1: OPC DA for Data Access
Process variables describe the plant's state, they are generated by the sensors or
calculated in the programmable logic controllers (PLCs).
Process variables can be sent upon a change, on demand or when a given time elapsed.
The OPC DA (Data Access) specification addresses collecting Process Variables.
The main clients of OPC DA are visualization and (soft-) control.
Industrial Automation
2013
Device access protocols 4.1 - 41
Specification 2: OPC AE for Alarms and Events
Events are changes in the process that need to be logged, such as "production start"
Alarms are abnormal states in the process that require attention, such as "low oil pressure"
OPC AE (Alarms and Events) specifies alarms and events, their subscription, under which
conditions they are filtered and sent with their associated messages.
The main clients of OPC AE are the Alarms and Event loggers.
determine the exact time of change
(time stamping)
categorize by priorities
log for further use
acknowledge alarms
(events are not acknowledged)
link to clear text explanation
Industrial Automation
2013
Device access protocols 4.1 - 42
Specification 3: HDA for Historical Data Access
Historical Data are process states and events such as: process variables, operator actions,
recorded alarms,... that are stored as logs in a long-term storage for later analysis.
OPC HDA (Historical Data Access) specifies how historical data are retrieved from the logs
in the long-term storage, filtered and aggregated (e.g. compute averages, peaks).
The main client of OPC HDA are Trend Displays and Historians.
Industrial Automation
2013
Device access protocols 4.1 - 43
Beyond Microsoft: OPC UA
In a move to get more independence from Microsoft and use web technology:
new specification called " Unified Architecture" that uses web services for all kinds
of transactions: query, read, write, subscribe,...
The classical OPC DA, AE and HDA are implemented with XML / SOAP / WSDL
this allows encryption and authentication of process data.
OPC UA does not only standardize the interfaces, but also the transmitted data.
Industrial Automation
2013
Device access protocols 4.1 - 44
Client and Servers
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration and communication
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
Automation Interface
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 45
Server(s) and Client(s) in the same node
node
client application
(OPC client)
OPC server
devices
client application
(OPC client)
OPC server
devices devices
OPC server
devices
Clients and servers run as parallel processes
The OPC specification defines the interface between client and server in the form
of objects and methods.
Industrial Automation
2013
Device access protocols 4.1 - 46
OPC for internal communication: ABB’s SCADA (800xA) as example
ABB's Operator Workplace (800xA) is at the same time OPC server and OPC client.
Software components (agents) within AIP expose their properties as OPC objects.
Internal (within the PC) and external communication (between PCs) takes place over
OPC.
800xA
aspects
aspects
functions
Asset
Optimizer
Windows
PC
Enterprise
Historian
OPC server
process
data base
OPC
connections
OPC client
ABB
OPC server
Industrial Automation
2013
Schneider
OPC server
Siemens
OPC server
Device access protocols 4.1 - 47
Direct and Fieldbus access
direct connection
fieldbus connection
client application
(OPC client)
client application
(OPC client)
(local)
OPC server
(local)
OPC server
FB Manager
fieldbus
I/O devices
The OPC server is running
all the time, even if no
client is present
Industrial Automation
2013
proprietary
protocol
can also
be a pointto-point
link
fieldbus
fieldbus
FB agent
FB agent
PLC
PLC
Device access protocols 4.1 - 48
Accessing a server in another node
client application
(OPC client)
stub
DCOM
TCP/IP
DCOM
Limitation:
does not work over firewalls.
Solution:
Tunneller
OPC UA
Industrial Automation
2013
TCP/IP
TCP/IP
DCOM
DCOM
OPC
server
OPC server
FB Manager
fieldbus
Device access protocols 4.1 - 49
Assessment Overview
• What is the objective of OPC ?
• On which technology does OPC rely ?
• What is an OPC Server ?
• What do the main OPC specifications describe ?
• How can an OPC Server access data on another machine? And
how does it work for OPC clients?
Industrial Automation
2013
Device access protocols 4.1 - 50
OPC Data Access
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
Automation Interface
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 51
OPC DA: Item properties
The process data are represented by three dynamic properties of an item:
1. value:
numerical or text
2. time-stamp:
time at which this data was transmitted from the PLC to the server
UTC, not local time.
3. quality:
validity of the reading (not readable, dubious data, o.k.)
optional static properties
description:
a text string describing the use and of the variable (optional)
engineering unit: the unit in which the variable is expressed (optional)
ID
Industrial Automation
2013
V
Q
T
D
U
Device access protocols 4.1 - 52
OPC DA: Objects as viewed by the OPC server
An OPC server is structured as a directory with root, branches and leaves (items)
Process Line 1
Tag Name
Controller 1
Controller 2
Controller_3.Prog_1
Controller_3.Prog_2
TAG
TAG
TAG
Level_1
Level_2
An item is identified by its
"fully qualified ItemID",
e.g.
Ramp4
"Process_Line_1.Controller_2.Level_2"
Cell 1
Machine 2
Branches may contain other branches and items
The structure may also be flat instead of hierarchical
This structure is defined during engineering of the attached devices and sensor/actors.
(Intelligent servers can configure themselves by reading the attached devices)
Industrial Automation
2013
Device access protocols 4.1 - 53
OPC DA: Objects as viewed by the OPC client
A client builds its own hierarchy, using the server’s hierarchical view.
Items in the server are defined by the programmer of the PLC
A full-fledged PLC may export some 10’000 items, a client needs only a subset.
A client builds groups, populating them with items it is interested in.
Items of a group are expected to have similar real-time requirements
Groups are not hierarchical, but flat.
Industrial Automation
2013
Device access protocols 4.1 - 54
OPC DA: Mapping items to groups
Each client structures its items by groups,
independently from the server.
clients
Client1
Initially, the client browses the server structure to
check if the items it is interested in exist.
GroupX
A client registers its groups and items at the server.
The server keeps the structure of all its clients.
Server root
Client2
GroupZ
Item1 Item2 Item3 Item1 Item2
server
Area 1
TAG
Temperature
TAG
Heat_On
TAG
Level
Area 2
TAG
Empty_Valve
Area 51
TAG
Fill_Valve
Oven_1
Tank_1
Industrial Automation
2013
Device access protocols 4.1 - 55
OPC DA: Communication Model
4.2.1 OPC Common
Overview: usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
Automation Interface
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 56
4.2.2 OPC DA: Example of access to a variable
controller program
OPC application
Reactor_1.Program2
ReadItem
("OPC:Reactor1:
Program2.MotorSpeed")
Value: 112
OPC
server
load
symbol
table
MW%1003
MotorSpeed
MW%1004
Temperature
…
….
symbols
code
Get () 192.162.0.2, MW%1003)
Return (MW%1003, 112)
Network
Reactor_1
Marker: MW%1003
Industrial Automation
2013
Device access protocols 4.1 - 57
OPC DA: Read Communication Models (per group)
synchronous
client
asynchronous
server
client
Call
myGroup.SynchRead()
myGroup.AsyncRead()
Reply
server
Call
Reply
myGroup_AsyncReadComplete()
client
myGroup.IsSubscribed
on change
("subscription-based")
server
Subscribe
Notify
myGroup_DataChange()
Notify
myGroup_DataChange()
Industrial Automation
2013
Device access protocols 4.1 - 58
OPC DA: Write Communication Models (per group)
client
myGroup.SynchWrite()
server
Call
client
myGroup.AsyncWrite()
Reply
server
Call
Reply
myGroup_AsyncWriteComplete()
The OPC interface accesses only groups, not individual items.
Industrial Automation
2013
Device access protocols 4.1 - 59
OPC DA: communication paradigm
OPC DA works according to the “shared memory” paradigm.
This means that a newer value overwrites the older one, no queues or history are kept.
The server does not guarantee that different clients see the same snapshot of the plant.
The server does not guarantee that all changes to variables are registered,
changes may be missed if the polling period is too long.
OPC DA Client
OPC DA Client
OPC DA Server
Industrial Automation
2013
Device access protocols 4.1 - 60
OPC DA: Assessment
1. How does the OPC server know a) where to fetch an item? b) which items belong
to which group?
2. What are the DA the read and write operations ?
3. Is communication done by items, by groups or by collection of groups ? Why?
4. Can a change of an OPC variable be notified as an event, or shall the client poll ?
5. What are the implications of the shared memory paradigm for the application
developer?
Industrial Automation
2013
Device access protocols 4.1 - 61
OPC Alarms and Events
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 62
Alarms and Events: Purpose
The controllers (PLC) generate events in response to changes in the plant variables.
together with their precise time of occurrence, type, severity and associated message for
the human operator.
An OPC AE server registers these events and makes them available to several clients
Alarms are described as state machines and may require acknowledgement.
The OPC Alarms & Events Interface gives access to the AE server, allowing to:
- browse the OPC AE Server for predefined events.
- enable or disable alarms and events
- subscribe to alarms and events of interest
- receive the event and alarm notifications with the associated attributes
- acknowledge alarms
Industrial Automation
2013
Device access protocols 4.1 - 63
AE: Definitions
An event is a general change of state that is relevant to the OPC server.
An event signal a change:
1) in the field device ("production started")
2) in the OPC server ("alarm acknowledged")
3) in the application ("operator action")
An alarm indicates a state of the process that requires attention and is relevant to the OPC
server. An alarm is represented by an alarm condition, which is a state machine determining
if the alarm has been enabled, triggered or acknowledged. An alarm rises several events.
An event or an alarm does not transmit process values, but boolean information indicating a
change of state, its originator, the time of its occurrence and a message intended for a
human operator.
Alarms and events may not get lost
(contrarily to OPC DA, which does not guarantee completeness)
Alarms and event are precisely time-stamped by their source,
(contrarily to process variables, which are time-stamped by the receiving OPC server).
Industrial Automation
2013
Device access protocols 4.1 - 64
AE: communication paradigm
OPC AE works according to the “message passing” paradigm, contrarily to OPC DA, that
works according to the "shared memory" paradigm.
This means that an event is kept in a queue until all clients have read it (or timed out).
The AE server guarantees that different clients will see all events in the same sequence.
OPC AE Client
OPC AE
Client
OPC AE
Server
12:34 23.114
12:34 32.334
Industrial Automation
2013
Device access protocols 4.1 - 65
AE: Displaying Alarms and Events
Alarms and events are usually displayed differently on an operator screen.
- Events are displayed in an event list that can become quite long (typically 1000 entries),
entries are not cleared when the source of the event returns to normal
- Alarms are displayed in a short list (typically 50 alarms)
appearance changes when the alarm is acknowledged,
an alarm line is cleared when the alarm signal is cleared (but remains in the log).
Ack
checkbox
Industrial Automation
2013
Device access protocols 4.1 - 66
AE: Events
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 67
AE: Events kinds
OPC AE defines three kinds of events:
1.
simple: process control system related events (change of a boolean variable)
2.
condition-related: notifies a change of an alarm condition (CLEARED, ACKNOWLEDGED),
(see later)
3.
tracking-related: origin outside of the process (e.g. operator intervention)
Industrial Automation
2013
Device access protocols 4.1 - 68
AE: Event- identification
An event is identified by
- its source (the object that generates the event. e.g. Tank1) and
- the event name (which can be the same as in another object, e.g. HiLevelCond)
HiLevelCond HiLevelCond
event
event
LoLevelCond LoLevelCond
event
Tank1
event
event name
Tank2
event signal (boolean expression)
is an external signal to be used ?(boolean)
signal name for external signal (20 characters)
name of the source (30 characters)
message (60 characters)
Industrial Automation
2013
Device access protocols 4.1 - 69
AE: Events - Notification
Tank1LevelHigh_SimpleEvent
(source, timestamp, message,
severity, category)
AE Client
specified communication
COM/DCOM
OPC AE
Server
queue
unspecified communication
network, fieldbus or
internal bus
event notification
message
timestamp
Controller
Event
FB
Tank1
Plant
Industrial Automation
2013
Level Switch
Device access protocols 4.1 - 70
AE: Events - Time Stamp
There are three places where events can be time-stamped:
- at the device that originally produced the data (external event - low-level event)
allowing Sequence-Of-Events with a high accuracy, down to microseconds
- at the controller, (internal event) using the controller's clock to time-stamp messages
giving accuracy not greater than the period of the tasks, about 1 ms.
- at the OPC Server, when an event message arrives (tracking events)
not more accurate than DA, about 10 ms)
The OPC server can be configured to register the time stamp at the instant of the
event transition (positive or negative) and the instant of the acknowledgement.
Industrial Automation
2013
Device access protocols 4.1 - 71
AE: Alarm conditions
4.2.1 OPC Common
Overview: usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 72
AE: Alarms - Condition Definition
An (alarm) condition is described in a named state machine
The condition state is defined by three variables:
• Enabled:
the condition is allowed to send event notifications
• Active:
the alarm signal is true
• Acknowledged:
the alarm has been acknowledged
Alarm signal
(e.g. FIC101.PV > 100 AND FIC101.PV < 150)
Acknowledgement signal
(a positive transition of a boolean variable)
Condition
Condition state
Enable (positive transition)
Disable (positive transition)
Industrial Automation
2013
Device access protocols 4.1 - 73
AE: Alarms - Condition states and acknowledgement
event notification
alarm signal
acknowledgement
condition state
Inactive
Acked
Active
Active
Unacked Acked
Inactive
Acked
Active
Inactive
Unacked Unacked
Inactive
Unacked
Inactive
Acked
alarm_signal 
Enabled
Inactive
Acked
condition state
transitions
(here: always
enabled)
Ack 
alarm_signal 
alarm_signal 
Enabled
Inactive
Unacked
Enabled
Active
Unacked
Ack 
Enabled
Active
Acked
alarm_signal 
An event is generated each time the alarm signal changes state, or is acknowledged
Industrial Automation
2013
Device access protocols 4.1 - 74
AE: Alarms - Acknowledgement
An alarm condition becomes active when the PLC produces an alarm signal describing
an abnormal state defined by the application (e.g. the level of the tank is too high).
The operator is expected to acknowledge this condition (client ack)
Alternatively, a local operator may use a button or HMI that the PLC reads (field ack)
event notification
Tank1Level_ConditionEvent
AE Client
client ack (acknowledger ID)
COM / DCOM
OPC AE
Server
Network, field bus,
or internal bus
message
Condition
timestamp
LevelHigh
controller
Alarm Signal
Industrial Automation
2013
AckButton
(field ack)
Device access protocols 4.1 - 75
AE: Summary alarms and events
Event
Alarm
AE Client
AE Client
COM / DCOM
OPC AE
Server
event notification (source, timestamp, message)
OPC AE
Server
alarm notification (source, timestamp, message,
condition, subcondition, severity, type)
message
timestamp
Event
FB
message
controller
event
Industrial Automation
2013
Condition
controller
alarm ack
Device access protocols 4.1 - 76
OPC A&E: Assessment
1. What is the difference between Alarms and Events?
2. Where are Alarms and Events time stamped?
3. How does the “message passing” paradigm influence the OPC client application
developer?
Industrial Automation
2013
Device access protocols 4.1 - 77
OPC Common Overview
4.2.1 OPC Overview
Usage and specifications
Clients and Servers: configuration
4.2.2 OPC Data Access
Objects, Types and properties
Communication model
4.2.3 OPC Alarms and Events Specification
Events
Alarm Conditions
4.2.4 OPC Historical Data Specification
Overview
Industrial Automation
2013
Device access protocols 4.1 - 78
Historian Example
GE Fanuc/Intellution iHistorian (iFix...)
Questions to the historian:
What was the value of FIC101 last week ?
What was the flow average during October ?
Which were the daily averages in October ?
What was the total flow in each month ?
How much fuel did we use for the batch ?
Give the answers in form of tables,
pie diagrams, spreadsheet, reports
Features:
Unlimited Point Collection
Sub-Second Data Collection Rates
Enhanced Data Compression
True Thin Client Administration
Fault Tolerant Architecture
Industrial Automation
2013
Data collection, archiving and retrieval
Report generation
Computations (e.g. VBScript)
Secure access (FDA 21 CFR 11)
20'000 actions/ s,
Up to 100'000 data points
Device access protocols 4.1 - 79
HDA: Historical Data Access
HDA Clients
e.g. Trend Analysis
e.g. Event Logger
independent
processes
OPC HDA
Server
hidden
calculations
history
database
raw and
ordered data
collector
proprietary
data acquisition
OPC DA Server
Field device
Industrial Automation
2013
Field device
Device access protocols 4.1 - 80
HDA: Purpose
An OPC HDA server gives access to a historical data base (logs) in which data from the
process have been collected and time-stamped, possibly through an OPC DA interface.
The OPC HDA interface clients, such as trend analysis, product tracking or data mining,
that require ordered access these data logs.
The OPC HDA interface allows to:
- browse the historical data base
- retrieve data through proper filtering, e.g. by date range, by identity, by property
- build aggregates over the retrieved data, such as average, minimum, maximum.
- enter new entries, correct entries or remove entries
- enter / delete annotations in the history data base
Industrial Automation
2013
Device access protocols 4.1 - 81
HDA: Raw log
12.3.02 13:40
12.3.02 13:40
12.3.02 13:40
12.3.02 13:40
12.3.02 13:41
12.3.02 13:41
12.3.02 13:41
12.3.02 13:41
12.3.02 13:41
12.3.02 13:41
12.3.02 13:41
12.3.02 13:42
12.3.02 13:42
12.3.02 13:42
Gpcpt2ofpbonne
Cpt2bac
Gpcpt2bac
Gpcptbe2
Gpcpt1bac
Gpcpt1ofpbonne
Gpcptae2
Cpt1bac
Gpdefr2
Gpvoydef
Gpr3tempscycleprd
Gpstn1e1
Gpalarme1
Gpalarme2
4824
50
70
45
151
4826
45
49
64
2
318
16
0
0
12.3.02 13:43 Gpetatmodemarche
2
1346
1
16
0
317
0
0
0
1
1992
435
1
1
0
4823
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:43
12.3.02 13:44
12.3.02 13:44
12.3.02 13:44
12.3.02 13:44
12.3.02 13:44
12.3.02 13:44
12.3.02 13:44
Gptpscycle
Gpetatmodemarche
Gpdefgene1
Gpetatmodemarche
Gptpscycle
Gpdefr2
Gpvoydef
Gpdefgene1
Gpetatmodemarche
Gpr2tempscycleprd
Gptpscycle
Gpalarme3
Gpalarme4
Gpalarme3
Gpcpt2ofpbonne
Industrial Automation
2013
By definition, values are registered when they change.
(even if data are acquired by periodic polling)
Data in the historical database are identified by their
• itemID (here, represented by their name),
• value, (of the respective type)
• quality (good, stale, bad), and
• timestamp (UTC).
Device access protocols 4.1 - 82
HDA: How to reduce raw data (even before HDA comes into play)
Data sent to the OPC DA server on change, collector records data in a circular buffer log
Since storage capacity is limited, data are reduced by:
1. if a variable is received more often than the log's minimal storage interval (e.g. 1s), the log keeps
the latest of all values of the interval
2. if (and only if) a received variable changed by more than the "exception deviation" (e.g. 5%,
analog values only), it is entered into the log.
3. if a variable changed by less than the exception deviation, it may be forced into the log after the
log's maximum storage interval (e.g. 4 s) elapsed.
min time
max time
max time
max time
max
exception
deviation
min
time
= process value (event)
= log entry
If the time scale of the log is smaller than that of the trend display in this case, values have
to be interpolated to be displayed correctly
Industrial Automation
2013
Device access protocols 4.1 - 83
HDA Application: Trend Display
Parameters:
log: how were data sampled
• time scale (with possible offset, zoom, pan)
• amplitude scale (low range, high range, scale units)
• style: smoothed, stepped, filled (several ways to display the same data)
• extrapolate: how to display values not received (e.g. because they did not yet change)
Industrial Automation
2013
Device access protocols 4.1 - 84
HDA: Hierarchical logs
long-term log
1 hour_forever
 5.2 MB / Year
1
2
3 27 28 29 30
september octobre
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
october
1 mn_7 days log
 6 MB
d-7
1s_24 hours log:
50 traces @ 12 B
 52 MB
23
24
1
2
3
d-6
4
5
d-5
6
7
8
d-4
9
10
d-3
11
12
13
A hierarchical log is built on the data contained in the parent log.
To reduce the log size, several aggregations can be applied:
- record only maximum, minimum, average over a period, etc...
Industrial Automation
2013
d-2
14
15
16
yesterday
17
18
19
today
20
21
22
Actual data
Device access protocols 4.1 - 85
Toy Examples: Logging Temperature
http://home.hit.no/~hansha/documents/subjects/IA6209/project/IA6209%20Project%20Work%20-%20Weather%20System.pdf
Industrial Automation
2013
Device access protocols 4.1 - 86
Real-Life Examples and Exercise
Integration of redundant GE Mark V turbine controllers at a power plant
The controllers tie into the plant’s main DCS, an ABB Advant
control system. Process Portal B and MicroSCADA client
applications are used to visualize process data from the turbine
controllers.
Exercise: Draw schema of system and describe which OPC specifications
are used and how.
Wind Generation
AES Wind Generation manages 7 different wind farms across the
United States, five of which comprise more than 500 turbines,
with a total generating capacity of over 700 MW. There are six
different turbine models, from four different manufacturers.
Exercise: Explain which OPC concepts are useful in this context
and how they can be applied to support a SCADA system
http://www.matrikonopc.com/portal/downloads.aspx?dID=132 and
https://www.matrikonopc.com/portal/downloads/case_studies/AESWindGeneration_OPC.pdf
Industrial Automation
2013
Device access protocols 4.1 - 87
To probe further….
OPC Foundation:
Specifications http://www.opcfoundation.org
SoftwareToolbox
Examples in Visual Basic
http://www.softwaretoolbox.com/Tech_Support/TechExpertiseCenter/OPC/opc.html
The Code Project
OPC and .NET
http://www.codeproject.com/useritems/opcdotnet.asp
Matrikon
Free client and server:
http://www.matrikon.com
WinTech
Toolkit for an OPC server
http://www.win-tech.com/html/opcstk.htm
NewAge Automation
Toolkit for an OPC server
http://www.newageautomation.com
Industrial Automation
2013
Device access protocols 4.1 - 88