Download Intelligent Field Devices for Process Control

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Control theory wikipedia , lookup

Distribution management system wikipedia , lookup

Automatic test equipment wikipedia , lookup

Telecommunications engineering wikipedia , lookup

Control system wikipedia , lookup

Distributed control system wikipedia , lookup

Opto-isolator wikipedia , lookup

Resilient control systems wikipedia , lookup

Transcript
Intelligent Field Devices in Networked Control Systems
(reading for “Elements of Industrial Automation” at ELDE)
Introduction
The integration of microelectronics and network communications, in
control and instrumentation design has greatly increased device
functionality. This combination of technologies has given rise to a
generation of devices that are often referred to as "smart instrumentation.'
Increasing plant availability comes directly from improving component
availability and can be achieved through the early detection of anomalies
(variances or irregularities in the equipment), and by providing conditionbased real-time maintenance.
There have already been some attempts to improve plant availability
by applying signal validation schemes to process control systems. For
instance, with three or more sensors measuring the same process variable,
one can implement a consistency checking or majority voting type of
algorithm as a signal validation method to detect signal anomalies. In
addition, model-based techniques are used when different types of
measurements are available for the same process or the same system.
Most of these techniques are based on the modelling of the normal
behaviour of a sensor by auto-regression time series and then monitoring
its behaviour. Signal validation has been integrated with high-level control
systems and their data acquisition systems to provide the assistance that
the plant operators need during operation.
However, the inefficiency of these schemes becomes apparent when
we consider the signal linearization, damping, and communication delays
that mask the true readings of sensors. Even though readings are accurate
by the time they reach the high-level sensor validation system, the critical
information hidden in the raw data has been lost.
Understanding the failure rate of various pieces of equipment is key to
a predictive maintenance program. Industry data (Fig. 5.0.1) have shown
that the least reliable instruments are typically rotating equipment.
Transmitters, on the other hand, are the most reliable.
Also, industry data indicate that transmitters and sensors are the first
candidates for inspection in the event of an anomaly. For example, 1997
Hydrocarbon Petroleum Industry maintenance spending data indicate that
nearly 20% of the maintenance budget is spent on inspecting transmitters
(Fig. 5.0.2), which are the least likely candidates for the detected anomaly.
Elimination of these unnecessary inspections can have a major impact on
maintenance costs. Knowing that the instrument is healthy is, therefore,
equally as important as knowing if it has failed.
S. Djiev, Industrial Networks for Communication and Control.
1
Fig. 5.0.1
Fig. 5.0.2
A typical service call for a process instrument can cost 300 Euros per
call, which can quickly exceed the purchase cost of the instrument. Figure
5.0.3. shows the results of a large chemical company’s field maintenance
logs. 35% of the trips made to the field were routine checks, where no
problems were found. Another 28% of the field trips were reactions to a
problem, but the problem was not found to be in the transmitter. A total of
63% of the trips to the transmitter would have been unnecessary if the
health of the transmitter had been known. This is a waste of resources,
which increases the operational cost of a plant.
Fig. 5.0.3
2
S. Djiev, Industrial Networks for Communication and Control.
5.1. Common characteristics of intelligent field devices
Smart instruments cannot exist without the power of the
microprocessor. The ability of the onboard processor to locally handle large
amounts of data is essential to their operation. Use of microsensors, when
applicable, contributes greatly to the miniaturization and modularization of
sensor packages.
Intelligence is available in all types of instrumentation, including
pressure, level, temperature, flow, electrochemical and chemical
composition measurement. The most common capabilities of smart
sensor/transmitter/actuator packages include:
• Multivariable capability – the ability of an instrument to measure more
than one variable at a given process point;
• Self-diagnostics – the capacity of a device to check its own operating
condition and report operational anomalies or component failure;
• Self-calibration – the ability of the instrument to adjust its calibration
when process conditions change;
• Remote instrument rearranging in analog output situations;
• Direct digital transmission of measurements – eliminates the need for
rearranging instruments should process conditions change. Digital
output also provides greater accuracy over the 4-20 mA mode, all
things being equal.
While not all capabilities are available in all devices, instrumentation
suppliers have made great strides in packing five pounds of capability into
the proverbial two-pound bag. And as more features are integrated into one
instrument, capabilities should expand exponentially. Instrumentation will
soon be on the front line, bringing users advantages as diverse as
eliminating technician trips into hazardous areas for instrumentation
maintenance and recalibration or collecting documentation data for ISO
9000 reporting procedures.
To realize the benefits of implementation of intelligent end devices we
have to translate them into a system architecture and define the features of
that architecture. Among other things, this required addressing the issue of
just what a smart sensor/actuator is. Figure 5.1.1 shows a general
architecture for one concept of a smart sensor/actuator.
S. Djiev, Industrial Networks for Communication and Control.
3
Application
Algorithms
Transducer
Signal
Conditioning
A-D or
D-A
conversion
User
Interface
Communication
Data Storage
Figure 5.1.1. General architecture of a smart sensor/actuator
•
•
•
•
•
4
The architecture consists of seven major elements:
Transducer. A device converting energy from one domain into another.
The device may be either a sensor or an actuator.
Signal conditioning module. This circuitry prepares the electrical signal
for conversion to the digital domain. (some transducers, such as simple
presence detectors, limit switches, counters, etc., are inherently digital.
For simplicity, this discussion concentrates on analog transducers.)
Signal conditioning can include conversion from one form of electrical
signal to another (e.g., current- or frequency-to-voltage), amplification,
bandwidth limiting through anti-aliasing filters, and more.
Analog-to-digital conversion. A device that converts the analog input
signal into a digital code that represents the magnitude of the analog
signal. It is generally beneficial to perform this conversion as close as
possible to the point of measurement.
Application algorithms. Application-level software or hardware whose
functions include converting the data to user-specified IFD units, signal
processing, data analysis and reduction, watching for alarm conditions,
logging time-stamped records to memory, running local control loops, or
other operations appropriately performed close to the point of
measurement. These algorithms, along with self-calibration and selfdiagnostics, provide the “smarts” in smart sensors.
Data storage. Digital data storage for sensor identification and
configuration information, calibration data, user display preferences, the
time-stamped logged data, and anything else that is valuable to store
within the sensor. As memory and communications bandwidth become
more available, it is likely that the entire sensor documentation, including
manufacturing and use history, and setup and user manuals, can be
stored in the sensor where they will not be misplaced.
S. Djiev, Industrial Networks for Communication and Control.
• User interface. A standardized presentation of corrected data to the end
user in the user’s language and terminology, and in the applicationspecific physical units.
• Communication. An interface to a communications medium for remote
access to the sensor for setup, calibration, diagnostics, data capture,
and general status monitoring. For smart actuators or systems with
mixtures of sensors and actuators, communications can include
commands such as updating outputs and changing set points.
5.2. Specifications for the design of smart field devices.
The main goal of the design of modern networked control solutions is
to standardize the interfaces between the transducer and the
microcontroller and the microcontroller node and the network.
In view of this situation the Technical Committee on Sensor
Technology of the Institute of Electrical and Electronics Engineer (IEEE)’s
Instrumentation and Measurement Society has sponsored a series of
projects, designated as IEEE P1451, to address these issues through the
development of a family of smart transducer interface standards for
connecting transducers to networks. When these standardized interfaces
are in place, transducer producers can design their devices to a single set
of specification for transducers and networks connectivity.
IEEE 1451 Specification for intelligent transducers
IEEE 1451 is part of a planned family of adopted and proposed
standards whose objective is to simplify the complexities designers have
traditionally faced in establishing communications between networks and
transducers.
In its simplest
terms, 1451 specifies a plug-and-play capability in a
transducer (sensor/ actuator) module (Fig. 5.2.1). This isolates the choice of
the transducer from that of the control network by specifying an electronic
data sheet (memory) in a smart transducer module. The protocol also
defines a serial digital interface that allows the control network to
interrogate the sensor, access the data sheet, and monitor/configure sensor
and actuator channels.
S. Djiev, Industrial Networks for Communication and Control.
5
Figure. 5.2.1
The Smart Transducer consists of the Smart Transducer Interface
Module (STIM) and the Network Capable Application Processor (NCAP).
Note that the transducers themselves are considered part of the STIM. In
fact, to provide the critical self-identification features, the transducer must
be inseparable from the TEDS during normal use.
Network capable application processor (NCAP)
The STIM is controlled by an NCAP, which mediates between the
STIM and the control network and may provide local intelligence. IEEE
1451.1 defines an NCAP network-independent information model, or a
meta-language, that describes how NCAPs can adapt to various network
standards and fieldbuses.
Objectives of the 1451 Standard
The objectives of the IEEE P1451 projects, Standards for Smart
Transducer Interface for Sensors and Actuators, are to define a set of
common communication interfaces for connecting transducers to
microprocessor-based systems, instruments, and field networks in a
network-independent environment. The projects are to develop hardware
and software standardized connection methods for smart transducers to
control networks utilizing existing control networking technology. There are
no set requirements for the use of different analog-to-digital converters,
microprocessors, network protocols, and transceivers. This in turn will
reduce the industry’s effort to develop and migrate to networked smart
transducers. The ultimate goals of the standards are to provide the means
for achieving transducers to network interchangeability and transducer to
networks interoperability.
As a result of the initial work by the TC9 committee, the standard
emerged as a set of four sub-standards - 1451.1, 1451.2, 1451.3, and
1451.4. Each focused on one area of the smart networked sensor’s signal
S. Djiev, Industrial Networks for Communication and Control.
6
path, and each can be used individually or as part of an overall network
solution. To date, only the 1451.1 and 1451.2 have been formally adopted
by the IEEE. P1451.3 and P1451.4 are still under development, hence the
prefix P, denoting a proposed document.
Figure 5.2.2. IEEE P1451 family relationship
The four sub-standards spell out how each substandard relates to the
others:
• 1451.1 defines a network capable application processor (NCAP)
model, which is network independent, allowing NCAPs to be adapted to
various networks. The model provides a hardware-independent abstraction
layer for the sensor interface and defines how the model is mapped through
a network abstraction layer to the control network.
• 1451.2 defines a transducer electronic data sheet (TEDS) for the
smart transducer interface module (STIM) and specifies the digital interface
and communications protocols between the STIM and the NCAP.
• P1451.3 proposes a standard digital interface, called a transducer
bus interface module (TBIM), which can connect multiple physically
separated transducers in a multi-drop configuration. The standard can be
used in harsh environments, where it may not be possible to site the TEDS
with the transducer, or in applications where transducers are distributed
across an area in which it is not feasible to install an NCAP for each
transducer channel.
• P1451.4 proposes a standard interface that will allow analog
transducers to operate in a mixed-signal mode. First, operating in a digital
mode, it transfers TEDS data on power-up or on command. After
S. Djiev, Industrial Networks for Communication and Control.
7
transmitting the TEDS data, the transducer switches to the analog mode
and sends its primary analog sensor signals.
Figure 5.2.3. Data flow in an IEEE 1451.2 device
5.3. Design of an Intelligent Field Device (IFD) for a networked control
system
The following sections are an example representation of the main
steps to be taken when deigning an IFD. There is no hardware or software
platform specified but more stress is given on the architecture design and
algorithmic support.
5.3.1. Design objectives and specifications
Let us consider that the design objectives define the following
specifications of the intelligent field device (IFD) behavior and capability:
1. Connection of the IFD to the medium is all that is required for the IFD to
become operational in the system.
2. Deletion of the IFD for any reason (e.g., disconnection or power-down)
does not cause any failure of system behavior, other than those effects
due to missing the production or consumption of data and messages
associated with the IFD.
8
S. Djiev, Industrial Networks for Communication and Control.
4. All IFDs are capable of accepting an “application script” that tailors the
inherent behavior of the IFD to meet the requirements of the specific
overall system application.
5. Central control is permitted but is not required as a means of managing
the modification of IFD behavior for specific applications.
6. All IFDs implement the same standard data, control, and behavioral
models.
7. The IFD contains clocks that are synchronized with the clocks in other
IFDs of the system.
8. The IFD provides information sufficient to properly interpret
communications with the IFD.
9. An IFD, which meets these design criteria is referred to as “smart node”.
5.3.2. Pre-design considerations
Distributed measurement and control systems generally require more
“intelligence” to be built into the sensors/actuators/valves etc., than a
traditional centralized system designed for the same task. There exist three
aspects of distributed IFD intelligence:
• transducer-related intelligence;
• measurement-related intelligence;
• system or application-related intelligence.
These aspects might be named “levels of smartness.” This section
presents some properties of measurements that need to be considered
when designing IFDs for a distributed system. In general, the more of these
properties that are managed by the IFD, the more useful the IFD will be as
a general component in distributed measurement systems.
For example, consider the transformation of the voltage output of a
thermocouple into temperature. If this is not handled in the IFD containing
the thermocouple, then every other IFD in the system that makes use of the
thermocouple output must either make this transformation itself or obtain
the result from a IFD that does make the transformation. Either of these
choices provides less system design flexibility than doing the transformation
in the IFD containing the sensor.
A. Transducer-related properties of IFDs
Transducer-related properties include:
1. Physical variable: temperature, stress, etc.
2. Form of transducer input or output: voltage, change in resistance, digital
signal
S. Djiev, Industrial Networks for Communication and Control.
9
3. Calibration: relationship of transducer output to sensible value, e.g.,
converting the value of the voltage from a thermocouple to the
measured temperature
4. Identity: transducer serial number, description, etc.
5. Limits of use: maximum and minimum values, acceptable operating
environments, stability of calibrations, repeatability, etc.
In the control system, these items are handled at the IFDs containing
the sensor or actuator. Current instruments generally manage these
properties, while most available sensors and actuators do not. Many of the
“smart sensors” available today manage only a few of these properties.
Examples of such existing smart sensors are:
• Analog Devices ADXL50 accelerometer, which has built-in signal
conditioning and self-test
• Smartec SMT160-30 temperature sensor with built-in signal
conditioning and digital interface
• Omega Engineering PX763 pressure sensor with signal conditioning
and an interface to the HART communications protocol
B. Measurement-related properties of IFDs
Measurement-related properties include:
1. Measurement timing management: timed, polled, random, etc.
2. Local data management: store until requested, broadcast upon
collection, etc.
3. Local computation: average, peak value, etc.
4. Identity: IFD identification, description, etc.
5. Location: coordinates or identifier of the measurement point
For IFDs in distributed systems, these properties need to be managed
within the IFD.
C. System or application-related properties of IFDs
System or application-related properties include:
1. Changing measurement properties in response to application-related
messages, e.g., changing the sample rate in a collection of IFDs
2. Defining the communication patterns among IFDs, e.g., master/slave,
client/ server, peer to peer, etc.
3. Establishing and modifying communication patterns among IFDs, e.g.,
modifying multicast membership
4. Managing the transport properties of communication among IFDs: flow
control, reliable delivery, etc.
5. Synchronizing the IFD clocks, if present
6. Conforming to system data and control models
10
S. Djiev, Industrial Networks for Communication and Control.
D. Communication protocol issues for IFDs
Multicast communication capability is desirable for distributed
measurements/controls. Here, multicast means that multiple sources can
communicate with multiple sinks.
In a distributed system, the logic that determines behavior resides in
the IFDs. In all but the most trivial measurements, this logic requires
communication between IFDs in a variety of patterns. For example, data
collected at a given IFD may be needed at several other IFDs for display,
archiving, or perhaps setting an actuator.
Most existing protocols in field-, control- and information-level
industrial networks present a point-to-point interface to the designer.
However, it is worth noting that at the physical layer most are fundamentally
multicast protocols since all IFDs share a common multicast medium such
as coax or RF. Notable exceptions are RS-232 and the 4-20ma loop which
are dedicated physical links and can not support a multicast protocol. Pointto-point protocols are not adequate for distributed measurement and
control. LAN protocols often have a multicast capability for specialized
needs. However, the normal application interface is point-to-point. The
internet protocol, IP, layer in the protocol stack is usually used for point-topoint links. Most network applications (e.g., FTP, Telnet, RPC, NFS) use IP
in this manner. There is provision for multicast in the IP layer. This multicast
capability is often used for system-level protocols, e.g., Ethernet/IP (see
4.3.), and can be used for distributed measurement protocols as well.
E. Data management issues for IFDs
In a distributed system the management of data must be more
structured than in traditional systems. In centralized systems many data
management tasks such as identifying the source and time of a
measurement, are based on the properties of point-to-point communication
links. In a distributed system, using multicast, other techniques must be
used for binding the various pieces of information in the system.
An example of such a technique is the data model for physical
measurements. It is necessary to include the value or a reference to the
value in the data sent from a distributed IFD for any item normally inferred
from the properties of a point-to-point link in a traditional system, e.g.,
source IFD identity. The minimum elements of the relation representing a
measurement include attributes for the value, units, time of measurement,
the location of measurement, and usually some name. Depending on the
type of system being built, additional elements such as accuracy or
precision may be included.
The use of data models with the information binding implemented in
the IFDs, provides the best basis for realizing the design objectives, e.g.,
the “plug-and-play” behavior.
S. Djiev, Industrial Networks for Communication and Control.
11
F. Control protocol and real-time issues for IFDs
In a traditional centralized system, behavior is managed by the
controller issuing detailed command messages to each of the remote IFDs.
Such systems, built using existing instruments and sensors, require many
of these messages to be concerned with details of the internal operation of
the IFD. These detail messages often dominate network traffic.
In distributed control systems, the details of system behavior are
determined by the IFDs. The control protocol must therefore support each
IFD internally managing the application details occurring at that IFD. In
addition, the control protocol must support the transmission of
synchronization messages between IFDs to produce the correct overall
system behavior. Synchronization includes not only the timing of
measurements but the overall progress of the application from one
sequence of events to another.
5.3.3. Intelligent Field Device structural synthesis
The common architecture of an IFD is illustrated in Fig. 5.3.1.
Figure 5.3.1. Common Architecture of an Intelligent Field Device.
12
S. Djiev, Industrial Networks for Communication and Control.
The Communication Media Access block handles the low-level
protocol required to access the physical medium. Included in this block, is a
media-dependent transceiver. This transceiver is the physical interface to
the medium. The interface between this block and the Control and
Configuration block, i.e., the network interface, is media and protocol
independent. The Control and Configuration block includes the remainder of
the protocol stack, i.e. the media and protocol independent portion, and the
control and computation circuitry needed to implement the functions of the
IFD. This Control and Configuration block is identical in all IFDs. The
optional Application block consists of a ROM containing an applicationspecific script. Applications may also be loaded over the network. This
block is located on a card that plugs into the smart IFD. The Sensor or
Actuator block contains the sensor or actuator transducer, any additional
circuitry not contained in the control and configuration block, and an
electronic data sheet containing specifications and calibration information
unique to the specific sensor or actuator.
Figure 5.3.2. Possible IFD structure, based on IEEE 1451.
The two possible data paths within the IFD Control and Configuration
block are illustrated in Fig. 5.3.3.
S. Djiev, Industrial Networks for Communication and Control.
13
Figure 5.3.3. Intelligent Field Device data paths.
The physical transformation converts between the digital
representation in the International System of Units, SI, and the raw digitized
representation provided by the transducer. This conversion is based on
information from the “electronic data sheet” contained in the transducer.
The application transformation is converts between the SI units
representation and the application representation which appears at the
network. In addition to the transformations on the data, the Control and
Configuration block implements the behavior models defined for the smart
IFD. These models specify the behavior of the IFD with respect to
properties like sampling rate and data management.
14
S. Djiev, Industrial Networks for Communication and Control.
Examples of Intelligent (Smart) Filed Devices for Process Control
Figure 5.3.4. Honeywell's HercuLine 10260S Smart Actuator
Figure 5.3.5. Masoneilan's Smart Valve.
S. Djiev, Industrial Networks for Communication and Control.
15
Figure 5.3.6. Honeywell Smart VAV Actuator.
The W7751H Smart VAV Actuator is an integrated Variable Air Volume (VAV) Box
Controller and a 90 second ML6161B Direct-Coupled Actuator. This VAV Box Controller
provides Pressure Independent airflow control and Pressure Dependent damper control.
16
S. Djiev, Industrial Networks for Communication and Control.