Scribd Logo
Upload

Welcome to Scribd!

  • 23 views

    1

    Uploaded by

    Fares Chetouh
    44

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    1

    Uploaded by

    Fares Chetouh
    23 views9 pages
    44

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    44

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    23 views9 pages

    1

    Uploaded by

    Fares Chetouh
    44

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 9

    Introduction

    There are many digital communication technologies being promoted as the


    future replacement for the venerable 4–20 mA analog standard, and most are
    self-described as fieldbus. With the exception of FOUNDATION™ fieldbus,
    virtually all of these technologies were developed for non-process
    environments such as automotive manufacturing, building automation, or
    discrete parts manufacturing, and later adapted to process control. Generally,
    they are well suited to the applications for which they were originally
    developed. Some of these technologies are open, some are proprietary. Most
    are a combination, having some open aspects but requiring the use of
    proprietary hardware or software components. All but FOUNDATION
    require a proprietary application to provide a complete control solution.

    Every communication technology provides a method for transmitting data


    between various devices and a host, and some provide communications
    directly between devices. The various schemes differ in how well they are
    optimized for moving data quickly, their suitability for real-time control, the
    cost of hardware implementations, their networking capability for branches,
    spurs and long distances, and for how power is distributed.

    Comparisons among “fieldbus technologies” typically reduces to


    comparisons of data rates, message length, number of devices on a segment,
    etc. These are all important communications issues and each technology
    represents a particular set of trade-offs which adapt it to its original
    application, and each is rooted in the technology that was available or in
    vogue at the time of its
    development.

    Using a strategy exactly opposite of FOUNDATION fieldbus, these


    various communications technologies minimize dependence on local
    intelligence in deference to minimum device cost, and maximize reliance on
    a centralized control architecture. Measurement instruments in such
    structures communicate to a central computing system at the request of that
    central system. A proprietary control application, running on the central
    system processes the field data and distributes control signals to other
    devices back in the field. Regardless of how open the communication
    scheme may be, the control application is always proprietary.

    The key distinctions between these technologies and FOUNDATION


    fieldbus are;

     FOUNDATION fieldbus provides an open specification for both


    communications and the control application.

     FOUNDATION fieldbus distributes control


    functionality across the bus, making maximum use of local intelligence
    to improve performance and reduce total system cost.
     Devices are required to be interoperable, providing the user with tools to
    implement a control system with products from multiple manufacturers
    without custom programming.

    With FOUNDATION fieldbus, the network is the control system. The


    major goals of this primer are to illustrate how this new architecture
    behaves, what it means to users, and what it requires of control equipment
    manufacturers

    Structure of Foundation Fieldbus

    Foundation Fieldbus uses the OSI Model as a basis and uses three layers.
    The three layers are indicated in the diagram below. They are:

    ◆ The Application Layer (broken into the Fieldbus Message


    Specification and Fieldbus Access Sublayer)
    ◆ The Data Link Layer
    ◆ The Physical Layer

    In addition there is a fourth layer called the User Layer. This is important to
    define as it allows for interoperability between equipment from different
    manufacturers by specifyingthe use of Function Blocks.
    Physical Layer

    The physical layer comprises a 31.25kbps data communications network


    often referred to as the H1 layer. Both communications signals and the current
    for each device are conveyed down this pair of wires. A terminator is placed
    at each end of the pair of wires to eliminate any reflections. There is also a
    High Speed Standard (HSE) standard which will run on 100 Mbps Ethernet
    and which is due to be released shortly.

    Note in the Figure 3, the terminator at each end. The power


    supply has a power conditionerto ensure that the data signals on the main
    homerun do not get drained into the low impedance power supply. The
    maximum length of the homerun is 1900m. In addition, thereare spurs that
    connect off the main homerun. These lengths are defined within the
    Foundation Fieldbus standard. (Note that RS-485 does not allow any spur
    lengths off themain homerun).
    Data Link Layer

    As indicated in figure 3, there are three types of devices specified in the


    Data Link Layer specification for Foundation Fieldbus. These are:

    ◆ Basic Device
    ◆ Link Master
    ◆ Bridge

    Link Master devices have the potential of becoming a link Active


    Scheduler (LAS). The LAS issues a Compel Data command to devices on
    the network at defined intervals. When a device receives a Compel Data
    Command it publishes its data on the bus for all devices to use. The devices
    that have been configured to read this data in are called Subscriber devices.
    This scheduled data transfer is used for the regular cyclical transfer of control
    loop data between devices on the bus.
    Bridges are used to interconnect different Foundation Fieldbuses. The
    Basic Device is effectively an Instrument or actuator. Note that a Basic
    Device cannot become a LAS.
    Application layer

    The Application Layer provides an interface for the device’s application


    software. This layer defines how to read, write, or start a task in a remote
    node. The main task of this layer is to define syntax for the messages.
    The main components of the Application Layer are the Fieldbus Access
    Sublayer (FAS) and the Fieldbus Message Specification (FMS).

    The FAS uses the scheduled and unscheduled features of the Data Link
    Layer to provide a service for the Fieldbus Message Specification (FMS).
    The types of FAS services are described by Virtual Communication Rela-
    tionships (VCR).

    The VCR is like the speed dial feature on your memory telephone. There
    are many digits to dial for an international call—an international access
    code, country code, city code, exchange code, and the specific telephone
    number. This information only needs to be entered once and then a “speed
    dial number” is assigned. After setup, only the speed dial number needs to
    be entered for dialing to occur.

    In a similar fashion, after configuration, only the VCR number is needed to


    communicate with another Fieldbus device.

    Just as there are different types of telephone calls, such as person-to-person,


    collect, or conference calls, there are different types of VCRs. VCRs and
    their management are covered in more detail in Chapter 5.

    Fieldbus Message Specification (FMS) services allow user applications to


    send messages to each other across the Fieldbus using a standard set of mes-
    sage formats.

    FMS describes the communication services, message formats, and protocol


    behavior needed to build messages for the User Application.

    Data that is communicated over the Fieldbus is described by an “object


    description.” Object descriptions are collected together in a structure called
    an object dictionary (OD).

    The object description is identified by its index in the OD. Index 0, called
    the object dictionary header, provides a description of the dictionary itself
    and defines the first index for the object descriptions of the User Applica-
    tion. The User Application object descriptions can start at any index above
    255.
    Index 255 and below define standard data types such as Boolean, integer,
    float, bitstring, and data structures that are used to build all other object
    descriptions.

    A Virtual Field Device (VFD) is used to remotely view local device


    data described in the object dictionary. A typical device will have at least
    two VFDs: a Network and System Management VFD and a User
    Application VFD.

    Network Management is part of the Network and System Management


    Application. It provides for the configuration of the communication stack.
    The Virtual Field Device (VFD) used for Network Management is also used
    for System Management, and provides access to the Network Management
    Information Base (NMIB) and to the System Management Information
    Base (SMIB). NMIB data includes Virtual Communication Relationships
    (VCR), dynamic variables, statistics, and Link Active Scheduler (LAS)
    schedules (if the device is a Link Master). SMIB data includes device tag
    and address information and schedules for Function Block execution.
    Conclusion

    The specifications that define Foundation fieldbus are owned and maintained
    by the Fieldbus Foundation, and are promoted as Foundation fieldbus.

    The solution distributes functionality across the network and makes


    maximum use of intelligence in the individual field devices. It provides a
    deterministic protocol for real-time control. It defines a standardized, object-
    oriented, function block model for application software and a unique Device
    Description technology to achieve multi-manufacturer device and host
    interoperability without custom programming.

    Foundation fieldbus represents an extensive combination of technology and


    organizational infrastructure. It provides a tested, open specification for
    interoperable devices which are designed to support diagnostics, monitoring
    and control in mission critical applications. But the technology goes well
    beyond written specifications. It includes multiple sources for development
    and configuration tools, communication stacks and applications software.
    There are automated test systems and documented test procedures for testing
    stack conformance and device interoperability

    The Fieldbus Foundation provides an established infrastructure which


    supports the test programs, maintenance and improvements in the
    specification, maintains and supplies key software utilities, and provides an
    organization where member companies can cooperate on technology
    development and exchange.

    Industrial process and manufacturing automation applications share many


    common requirements. Both can benefit from devices having multi-
    manufacturer interoperability, both need realtime scheduled and unscheduled
    bus access, they must deal with physical resource constraints, and both need
    increasing device autonomy. There is a common need for monitoring and
    control systems where subsystems can report error and operational health
    conditions, and perform remote calibration, diagnostics and program
    execution.

    You might also like