Sei sulla pagina 1di 67

Chapter 14: Foundation Fieldbus

Written by: Salvatore Cavalieri


Presented by: Chuan Li
CSC 8260: Wireless Networking and Cyber Physical Systems.
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
Outline

● Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
Introduction

●Foundation filedbus (FF) is an all-digital, serial, two-way


communication system for industrial applications.
●Fieldbus foundation has developed specifications for Foundation
fieldbus.
●Standardization
–20 years ago, the international Electrotechnical Commission
(IEC) and Instrument Society of America (ISA) embarked on a
joint standardization effort identified by two codes: 61158 on
the IEC side and SP50 on the ISA side.
–the purpose of this joint standardization is to define a unique
communication system able to merge the main features of the
fieldbus available on the market.
Introduction
●In IEC 61158, the specifications have put different types of foundation fieldbus
together. Among all the types of foundation fieldbus, the following two different
specifications are produced by the fieldbus foundation.
– H1 foundation fieldbus.
● type1: for physical and data link layer definition
● type9: for application layer definition
– HSE foundation fieldbus.
● type5: for application layer definition
●Two features of H1 FF:
– emphasis on the standardization of the description of fieldbus devices
– adoption of both the distributed and centralized link access mechanism.
●Besides basic H1 FF, the Fieldbus Foundation also adopts high-speed
Ethernet(HSE) for wireless environment integration and other different
standards to improve interoperability.
Outline

●Introduction

● Technical description of foundation fieldbus


–Introduction

–H1 foundation fieldbus


–HSE foundation fieldbus
–H1 and HSE foundation filedbus user application layer
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
Outline

●Introduction
●Technical description of foundation fieldbus
–Introduction
–H1 foundation fieldbus
–HSE foundation fieldbus
–H1 and HSE foundation filedbus user application layer
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
H1 Foundation Fieldbus Intro.

●H1 foundation fieldbus


–It is for distributed continuous process control.
–running at 31.25 Kbit/s.
–interconnects field equipment such as sensors, actuators, I/O
devices.
–Communication stack is minimal
–It also has a system and network management layer.
H1 FF vs ISO OSI Architecture

●H1 foundation fieldbus only has application, data link and


physical layers.
HSE Foundation Fieldbus Intro.

●HSE foundation fieldbus


–It is for discrete manufacturing applications.
–Itprovides integration of controllers, H1 subsystems, foreign
protocols, conventional I/O, data servers and workstations.
–HSE FF has an application layer and associated management
functions that can operate over TCP/UDP over IP.
HSE FF vs ISO OSI Architecture

●Different from H1 FF, HSE FF also has a transport layer and a


network layer.
Outline
●Introduction
●Technical description of foundation fieldbus
– Introduction

–H1 foundation fieldbus


● PHY layer
● DLL layer

● APP layer

● System management

● Network management

– HSE foundation fieldbus


– H1 and HSE foundation filedbus user application layer

●Wireless solutions for foundation fieldbus


●Open system implementation
●Conclusion
Outline
●Introduction
●Technical description of foundation fieldbus
– Introduction
– H1 foundation fieldbus

● PHY layer
● DLL layer
● APP layer

● System management

● Network management

– HSE foundation fieldbus


– H1 and HSE foundation filedbus user application layer

●Wireless solutions for foundation fieldbus


●Open system implementation
●Conclusion
H1 Foundation Fieldbus PHY Layer
●H1 FF PHY layer has a speed of 31.25 Kbit/s.
●Encode method is synchronous Manchester Biphase-L technique.
●Within a bit time, a positive transition is interpreted as a logical '0', and a
negative transition is interpreted as a logical '1'.
●Special codes are used to denote preamble, start delimiter and end delimiter.
●H1 FF supports intrinsically safe (I.S.) feature for bus-powered devices by
putting barriers between the power supply in safe areas and the device in
hazardous areas.
●H1 FF wiring.
– Trunk cable with terminators at both ends.
– Up to five trunks can be connected using repeaters.
– Spurs are connected to trunk cable using junction boxes.
–A spur can connect one device.
– The maximum number of devices is 32 on a Fieldbus link.
H1 FF PHY Layer Demo
Outline
●Introduction
●Technical description of foundation fieldbus
– Introduction

– H1 foundation fieldbus
● PHY layer
● DLL layer
● APP layer
● System management
● Network management
– HSE foundation fieldbus
– H1 and HSE foundation fieldbus user application layer
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
H1 Foundation Fieldbus DLL Layer

●In DLL layer, there are two transmission paradigms: circulated


token and scheduled access.
●Scheduled access
–Guarantee desired data transmission at needed time.
●Circulated token
–Use unscheduled time instants for transmission.
●Link active scheduler (LAS)
–It is used as an arbitrator to schedule transmissions.
–A centralized coordinator.
H1 FF DLL Layer – Scheduled Transmission

●LAS controls all data buffers in all devices to be cyclically


transmitted.
– LAS sends a compel data (CD) message to the device that should transmit
data.
– The device, upon receiving CD, publishes the data item (DT) in its buffer
to all devices on the fieldbus.
– Any device configured to receive the DT is called a subscriber.

●Scheduled transmissions are used for regular, cyclic transfer of


control loop data between devices.
H1 FF DLL Layer – Unscheduled Transmission

●In unused bandwidth, LAS sends out a pass token (PT) to its 'live list'.
●Token has maximum utilization interval
●After maximum utilization interval expires, the token is returned to LAS
using a return token (RT) frame.
●A target token rotation time (TTRT) defines the interval time for each
rotation.
H1 FF DLL Layer – Live List Maintenance

●The list of all devices that are properly responding to the pass
token(PT) is called the live list.
●Device discovery process
–LAS periodically sends out a probe node(PN) message.
–New device responds a probe response(PR) message to LAS
–After receiving a PR message, LAS adds the device into its live
list, and then sends a node activation message to the device.
●Probe is according to address, and at least one probe message has
to be sent out after LAS finishes sending a cycle of PTs.
●Unless a device failed to reply relevant PT for three times, the
device will always be in the live list.
H1 FF DLL Layer – Data Link Time Sync

●For scheduled transmission and scheduled function block (FB),


timing is very important.
●The sync process
–LASsends out time distribution(TD) message periodically to
make sure all devices have exactly the same data link time.
Outline
● Introduction
● Technical description of foundation fieldbus
– Introduction

– H1 foundation fieldbus
● PHY layer
● DLL layer
● APP layer
● System management
● Network management
– HSE foundation fieldbus
– H1 and HSE foundation fieldbus user application layer
● Wireless solutions for foundation fieldbus
● Open system implementation
● Conclusion
H1 FF APP Layer – Fieldbus Access Sublayer
●Fieldbus access sublayer (FAS) is described by a virtual communication
relationship (VCR).
●VCR defines the main features of information exchange between two
applications.
– Number of receivers (one or many).
– Memory organization (queue or buffered).
– Data Link Layer (DLL) mechanism (PT or CD).
●Types of VCR
– Client/server VCR type.
● Queued, unscheduled, user-initiated, one-to-one communication.
– Report distribution VCR type.
● Queued, unscheduled, user-initiated, one-to-many communication.
– Publisher/subscriber VCR type.
● Buffered, scheduled, LAS-initiated, one-to-many communication.
H1 FF APP Layer – Fieldbus Message Specs.
●Fieldbus message specification(FMS) describes the communication services,
message formats and protocol behaviors needed to build messages for user
applications.
●Data transmitted over Fieldbus are described by objects in object
dictionary(OD). Each object can be identified by index in OD.
●Virtual field device(VFD) is used to remotely view local device data described in
OD. VFD is accessed using VCRs.
●A device should have at least two VFDs: the network and system management
VFD and the user application VFD.
– The network and system management VFD provides access to network
management information base (NMIB) and to system management
information base (SMIB).
● NMIB includes VCRs, dynamic variables, statistics and LAS schedules.
● SMIB includes device tag, address information and schedules for FB
exec.
– Theuser application VFD can make the device functions visible to filedbus
communication systems.
Outline
● Introduction
● Technical description of foundation fieldbus
– Introduction

– H1 foundation fieldbus
● PHY layer
● DLL layer
● APP layer
● System management
● Network management
– HSE foundation fieldbus
– H1 and HSE foundation filedbus user application layer
● Wireless solutions for foundation fieldbus
● Open system implementation
● Conclusion
H1 FF System Management
●H1 FF system management handles the following features: FB
scheduling, application clock distribution, device address assignment and
find-tag service.
●FB scheduling
– Function blocks (FB) should be executed in particular order, at
specific time.
– Within a device, there is a device macrocycle to ensure repeated
synced execution of FBs at each device. At LAS, there is a LAS
macrocycle to ensure repeated synced execution of the entire
fieldbus link.
●Application clock distribution
– This
function can publish the time of day to all devices, it also can
automatically switch over redundant time publisher.
●Device address assignment is a service to configure address for devices.
●Find-tag service helps host systems and portable maintenance devices
query devices or variables by tag search.
Outline
● Introduction
● Technical description of foundation fieldbus
– Introduction

– H1 foundation fieldbus
● PHY layer
● DLL layer
● APP layer
● System management
● Network management
– HSE foundation fieldbus
– H1 and HSE foundation fieldbus user application layer
● Wireless solutions for foundation fieldbus
● Open system implementation
● Conclusion
H1 FF Network Management

●H1 FF network management provides configuration management,


performance management, and fault management.
Tasks performed by H1 FF network management

– Loading the list of communication links


– Configuring the communication stack
– Loading the LAS
– Monitoring the performance of device communication
– Detecting communication errors.
●An H1 FF network should have at least one network manager (Nmgr),
and each field device has a network management agent (NMA).
– NMgr issues command to NMA
– NMA report status and events to NMgr.
Outline

●Introduction
●Technical description of foundation fieldbus
–Introduction

–H1 foundation fieldbus


–HSE Foundation Fieldbus
–H1 and HSE foundation fieldbus user application layer
●Wireless solutions for foundation fieldbus
●Open system implementation
●Conclusion
HSE Foundation Fieldbus

●HSE FF enhances H1 FF by providing high-speed backbone,


redundancy, and bridging capability for multiple protocols.

HSE Foundation Fieldbus
●With the help of HSE devices, the following capabilities of the
interconnections are allowed
– HSE HD/H1
● The interaction is enabled by LD.

– HSE HD/HSE

– H1/H1
● The interaction is enabled by LD.
● Real-time communication cannot be guaranteed due to lack of
unique scheduler like LAS.
– HSE HD/foreign protocols
● The interaction is enabled by GD.

●HSE FF can use commercial, off-the-shelf Ethernet equipment, which


reduces the relevant installation and maintenance cost.
HSE FF Architecture
HSE FF Architecture

●HSE FF uses IEEE 802.3 MAC and PHY layer


●HSE FF uses TCP/IP, UDP, SNTP, SNMP and DHCP.
●What corresponds to a packet in Ethernet is called a protocol data
unit (PDU) in HSE FF.
●Message forwarding
–Instead of tunneling, PDU's data part is inserted in the data
field of a TCP/IP packet, but the PDU's address is encoded as
a unique TCP/IP address and is filled into the address part of
the TCP/IP packet, this improves efficiency.
HSE FF Architecture-Field Device Access Agent

●Field device access agent (FDA Agent) is a new technology for


providing a complete high-speed communication and control
solution.
●FDA agent allows control system to operator over the HSE
through LD. It also enables remote application to access field
devices using UDP/TCP.
●Objectives of FDA agents
–Conveying H1 system management service using UDP, H1
FMS service over UDP/TCP. This allows communication
between H1 and HSE devices.
–Republish H1 data from LDs that do not support H1 bridging.
–Sending/receiving LAN redundancy messages.
HSE FF Architecture-H1 Interfaces and Bridges

●Each H1 network needs an H1 interface to attach to HSE LD.


●An H1 bridge is used to convey H1 network messages between
other H1 devices within the same HSE LD.
●H1 bridges can be present in HSE architecture and perform data
forwarding and republishing between H1 interfaces.
HSE FF Architecture-Function Block Application
Process Virtual Field Device
●The function block application process virtual field device(FBAP)
VFD provides a common means for defining input, outputs,
algorithms, control variables, and behaviors of the automation
system.
●There can be multiple FBAP VFD to satisfy particular needs of an
application.
HSE FF Architecture-HSE System Management
Kernel
●The HSE SMK maintains information and a level of coordination
that provides an integrated network environment for the execution
and interoperation of the FBAP VFD.
●HSE SMK configures certain basic system information before
device operation.
● HSE SMK also helps keep a local time and the difference between
local time and system time from time server within a certain
specified value.
HSE FF Architecture-HSE Local Area Network
Redundancy Entity
●Special integrity-checking diagnostics and redundancy management
enables the use of two completely independent networks, redundant
communication ports, and redundant device pairs.
Network redundancy

– All network parts have redundancy, including hubs.


Communication ports redundancy

– A device may have two ports, if one fails, another one can continue
take charge.
– The two ports share the same IP address.

Device redundancy

– There are two types identical devices: primary devices and


secondary devices.
– They have identical configurations. HSE specifies how these devices
communicate and switchover, but it does not specify how to
configure them and how to synchronize data between them.
HSE FF Architecture-HSE Management Agent

●The HSE management agent supports the following aspects


–Acquisition of an IP address for the device using DHCP.
–Time synchronization with a time server using SNTP.
–Managing the TCP, UDP and IP layers using SNMP.
HSE FF Architecture-HSE Network Management
Agent VFD
●Each HSE device and HSE LD should have a network
management agent(NMA) VFD. It provides means for configuring,
controlling and monitoring HSE device and HSE LD operations.
●NMA VFD is capable of the following things
–Configuring the H1 bridge
–Loading the HSE session list
–Loading the HSE VCR list
–Performance monitoring for session endpoints, HSE VCRs,
and H1 bridge
–Fault detection monitoring
Outline
●Introduction
●Technical description of foundation fieldbus

– Introduction
– H1 foundation fieldbus
– HSE foundation fieldbus
–H1 and HSE foundation fieldbus user application
layer
● Resource block
● Function block

● Transducer block

● Function block linking and scheduling

●Wireless solutions for foundation fieldbus

●Open system implementation

●Conclusion
Outline

Introduction

Technical description of foundation fieldbus


– Introduction
– H1 foundation fieldbus
– HSE foundation fieldbus
– H1 and HSE foundation fieldbus user application layer

● Resource block
● Function block
● Transducer block
● Function block linking and scheduling
Wireless solutions for foundation fieldbus

Open system implementation


Conclusion

H1 and HSE FF User APP Layer-Resource Block

●User application layer is based on “blocks”, which are


representations of application functions. There are three types
blocks: resource blocks, function blocks, and transducer blocks.
●Resource block
–Resource block describes the features of fieldbus device such
as the device's name, manufacturer, and serial number.
–There is one resource block in a device.
H1 and HSE FF User APP Layer-Function Block

●Function blocks(FB) provide the control system behaviors.


●There can be many FBs in a single user application.
●There are two types of FB: standard FB and user-defined FB.
H1 and HSE FF User APP Layer-Transducer Block

●Transducer blocks are used to configure devices. It decouples FBs


from the local input/output functionalities required to read sensors
or command actuator's output
●Transducer block also contains information such as calibration
date and sensor type.
H1 and HSE FF User APP Layer-Function Block
Linking and Scheduling
Outline

●Introduction
●Technical description of foundation fieldbus

● Wireless solutions for foundation fieldbus


●Open system implementation
●Conclusion
Wireless Foundation Fieldbus

●High installation and maintenance cost of wired FF. Wireless


network can reduce the cost.
●There are many wireless solutions available, one of them is
ISA100.11a, the “Wireless System for Industrial Automation:
Process Control and Related Applications”. It is an open wireless
standard developed by ISA SP-100 committee.
●The HART Communication Foundation(HCF) also has developed
HART 7.0, also known as WirelessHART.
●The fieldbus foundation has two project teams to aid the process.
–The wireless sensor integration team to aid the ISA 100.11a
and WirelessHART
–The wireless HSE backhaul team to aid the ISA110.15 in
developing a wireless backhaul standard.
WirelessHART Integration

●To integrate WirelessHART with FF, the Fieldbus Foundation has


defined a specification addressing fieldbus transducer for wired
and WirelessHART devices.
●It defines a fieldbus transducer block used to represent HART
devices within FF.
●It also defines the method for HART tools to access HSE devices
using native HART command via the foundation HSE network.
●It also defines structures to identify and maintain HART device
status in wired multidrop networks and WirelessHART mesh
networks.
ISA 100.11a Integration

●The ISA 100.11a project has made a considerable effort in the


integration of the ISA 100.11a wireless sensor network into FF
infrastructure.
●ISA 100.11a devices are also represented as transducer blocks in
FF.
Wireless HSE Backhaul Team

●In late 2008, the ISA and Fieldbus Foundation reached an


agreement allowing them to collaborate on wireless networks.
●This agreement will assist ISA 100.15 working group in developing
a wireless backhaul standard.
●Backhaul networks integrate remote locations and applications
with central control facilities.
Foundation for Remote Opertions Management

●The Foundation for ROM fully realized the integration of FF with


existing wireless standards. It provides both a wireless and wired
infrastructure for remote assets and applications.
●Foundation for ROM provides direct access to information and
diagnostics in wireless and remove I/O devices.
●Foundation for ROM can also take the data from those devices
and place into the FF environment for data management and
quality.
●Foundation for ROM extends the range and capabilities of FF to
encompass many more devices throughout the plant, regardless of
their communication technology.
Foundation for Remote Opertions Management
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus

● Open system implementation.


–Electronic device description language
–Field device tool
–EDDL versus FDT: field device integration
●Conclusion
Open system Implementation

●Implementation of open systems in FF has been achieved through


the adoption of the device description language (DDL)
●Recently, Fieldbus Foundation has put a strong effort to integrate
FF with field device tool/device type manager (FDT/DTM)
technology.
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation.
–Electronic device description language
–Field device tool
–EDDL versus FDT: field device integration
●Conclusion
Electronic Device Description Language

●EDDL is a generic language for describing the properties of


automation system components, such as device parameters, device
functions, graphical representations, interactions with control
devices graphical representations and persistent data store.
●It allows host systems to configure as well as to monitor devices
online.
●EDDL enables host applications to retrieve information from field
devices, and is independent from operating systems,
communication and interface paths.
●An electronic device description(EDD) can contain parameters of
a device, it can also describe communication features.
Electronic Device Description Language

●In FF, a device description(DD) file provides an extended


description of each object in the VFD. It provides the information
needed for control system or a host to understand the meaning of
the data in the VFD.
●In FF, DD file is used together with a capability file (CF) to fully
describe he functions and capabilities of a device. In this way, the
host can ensure that only function supported by the device are
allocated to it.
Device Description Services

●On the host side, device description services(DSS) are used to read
the device description.
●DSS cannot read operational values since they are read from the
field device over the filedbus using FMS communication services.
Device Description Hierarchy

●There are four levels of device descriptions.


–Universal parameters
● May consist of common attributes like tag, model, etc.
–FB parameters
● In this level, parameters are defined for the standard FBs
and resource blocks.
–Transducer block parameters
● In this level, parameters are defined for transducer blocks.
–Manufacture-specific parameters.
● In this level, manufactures can add their own FB
parameters and transducer block parameters.
Device Description Interoperability Test

●Before Fieldbus Foundation registers a DD file, there are a series


of tests using FF's interoperability test kit.
–The first test loads the DD binary into a test system to validate
correct identification information
–Then, the DD undergoes multiple test cases to ensure the DD
matches the device and follows protocol rules for maintaining
interoperability between host and device.
–Finally,FF logs the DD file information, including name, size,
date and a 320bit cyclic redundancy checksum value
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation.
–Electronic device description language
–Field device tool
–EDDL versus FDT: field device integration
●Conclusion
Field Device Tool

●The device type manager (DTM) supports the configuration, operation,


diagnostics, maintenance and calibration of the device.
●There are two types of DTMs.
– Themost common DTM that supports end devices such as pressure
and temperature transmitter, I/O blocks and valve positioners.
– Communication (COM) DTM which is provided by network
infrastructure component manufacturers. COM DTM can monitor
the health of the network and its infrastructures, it eases the
network management significantly.
●The DTM is installed in a host application, called a frame. A field device
tool(FDT) frame is a higher level software application.
●A frame gains access to the device intelligence and functionality by
installing the appropriate DTMs into the topology tree of the application.
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation.
–Electronic device description language
–Field device tool
–EDDL versus FDT: field device integration
●Conclusion
EDDL versus FDT: Field Device Integration

●EDDL and FDT seem competing technologies to each other, but


they must be viewed as complementary.
●Plants are using a combination of the EDDL and FDT.
–Case1: basic integration is done with EDDL, but additional
advanced diagnostics functionalities are provided by
FDT/DTM.
–Case 2: device vendors do not provide DTMs for their simple
to medium-complex devices, then those EDDs are run in an
EDD interpreter DTM.
●There is a Field Device Integration(FDI) initiative which consists
of a combination of representatives from EDT group and EDDL
cooperation group. It aims at combine the best features of EDDL
and FDT standards.
Outline

●Introduction
●Technical description of foundation fieldbus
●Wireless solutions for foundation fieldbus
●Open system implementation.
–Electronic device description language
–Field device tool
–EDDL versus FDT: field device integration

● Conclusion
Conclusion

●This chapter gives an overview on the main features of foundation


fieldbus.
●This chapter provides an exhaustive overview about all the
integrations already done and about all the work that is carried on
at this moment to integrate more features to keep people informed
of the latest updates.

Potrebbero piacerti anche