FOUNDATION FIELDBUS TECHNICAL SPECIFICATIONS
The FieldComm Group is the developer, owner and standards organization for the FOUNDATION™ Fieldbus technology, establishing and controlling new developments and enhancements that support the needs of the process automation industry. FieldComm Group manages the FOUNDATION Fieldbus Technical Specifications and other related documents and provides related services and development tools to product manufacturers.
The FOUNDATION Fieldbus Technical Specifications is a complete, bookmarked, word-searchable software package that includes the latest FOUNDATION Fieldbus H1, High Speed Ethernet (HSE) and Physical Layer technical specifications. These specifications are essential for field device and controls manufacturers requiring implementation of fieldbus-based control solutions. The package also includes the latest application guides as well as technical and application notes.
The purpose of this specification is to support the standardization of a common file format for use in configuring and maintaining fieldbus devices and their function block applications. The scope of this specification is the definition of file formats for two different purposes:
- Transporting information that describes all of the visible information built into a device by the device manufacturer.
- Transporting data about specific devices configured for specific applications.
This specification contains the technical overview, architecture, format definition, and content of files that are common to all FOUNDATION Fieldbus host computer applications.
The following document provides generic test procedures that would be performed or witnessed by qualified FieldComm Group staff on FOUNDATION™ Fieldbus systems as part of the Host Interoperability Support Testing (HIST) to prove that the host has the adequate test procedure for each claimed feature according to this document.
This document specifies the HSE and H1 architecture of the FOUNDATION fieldbus. It describes how the components specified in the other FOUNDATION Fieldbus specifications may be related and configured to construct and support FOUNDATION Fieldbus devices, networks, and systems. This specification supersedes FF-800.
The scope of this document is to establish requirements for design, implementation, test, and interoperability verification of a set of communication protocols in HSE Devices on High Speed Ethernet media. These protocols together define the Ethernet Stack.
The HSE Presence in a HSE Device provides services for Ethernet Stack initialization, general-purpose communication over the Ethernet media, time synchronization, and HSE Presence management.
The HSE Presence is an addition to the Fieldbus Foundation H1 system and network management model. The HSE Presence does not replace this model, but rather adds services for HSE Presence management.
This specification is intended to encompass all the physical media and signaling rates described in IEEE Std 802.3 and IEEE Std 802.3u.
However, conformance tests are only defined for 100 Mbit/s Fast Ethernet (IEEE 802.3u).
Management of the HSE Presence is employing SNMP augmented to support Fieldbus Foundation unique Ethernet Stack parameters.
The scope of this specification is the FDA Agent, its messages, and its interfaces with HSE System Management [FF-589], HSE Network Management [FF-803], the Function Block Application Process Part 1 [FF-890], Fieldbus Message Specification [FF-870], H1 System Management [FF-880], and H1 Network Management [FF-801].
This document specifies the System Management Kernel (SMK) with its services and the System Management Information Base (SMIB) for support of system functions in an HSE device.
The scope of this specification is redundancy as it applies to device connections to LANs and redundancy as it applies to HSE devices themselves.
Redundancy as it applies to HSE LANs addresses communication paths that contain repeaters, bridges, switches and hubs and device connections to those communications paths. However, because routers interconnect LANs, they are not included within redundant HSE LAN communication paths. The HSE LAN redundancy addresses communication paths among HSE Devices as well as non-HSE devices.
Redundancy as it applies to HSE devices themselves addresses devices that operate as backups to other devices.
This document provides a technical overview of the approach to LAN and device redundancy followed by details of the mechanisms for achieving LAN redundancy and the behaviors of redundant devices. The annexes provide a copy of relevant message contents, together with informative discussions of the LAN redundancy mechanism, LAN topologies, LAN redundancy implementation considerations, the responsibilities of a configuration application and a summary of the effects of the configuration parameters.
FOUNDATION Fieldbus Network Management provides for the management of a device's communication system by an external network manager application. This document specifies the network management objects and services necessary to manage the communication system of a FOUNDATION device.
The Network Management objects and services defined in this document support are:
- Configuration Management - initializes and maintains communication parameter values
- Performance Management - collects and characterizes the performance of device communications
- Fault Management - assists in fault detection, isolation, and recovery.
Definition of the network manager application that accesses these objects and services is beyond the scope of this specification.
The relationships between Network Management and the other FOUNDATION Sublayers are described in the FOUNDATION Fieldbus System Architecture Specification.
The FOUNDATION Fieldbus High-Speed Ethernet (HSE) protocol introduces new classes of Fieldbus equipment, which use the HSE and some associated protocols as a high-speed bus for field device access. This equipment needs new Network Management Agent (NMA) objects, here classified as HSE NMA Objects, which are related to:
- Field Device Access Agent (FDA) module, and/or
- H1 Bridges
FOUNDATION Fieldbus Network Management provides for the management of a device’s communication system by an external network manager application. This document specifies the HSE network management objects, and the services necessary to manage the communication system of an HSE and/or a H1 bridge device.
The Network Management objects and services defined in this document support:
- Configuration Management - initializes and maintains communication parameter values
- Performance Management - collects and characterizes the performance of device communications
- Fault Management - assists in fault detection, isolation, and recovery
Definition of the network manager application that accesses these objects and services is beyond the scope of this specification.
This document specifies a general method for the operation of bridges. Bridges provide compatible interconnection of automation equipment that use the FF DL-service specification, FF 821, and implement the FF DL-protocol specification, FF 822.
The intent of this document is twofold:
- to apply the appropriate parts of the IEC 61158-2 standards to Fieldbus Foundation devices by referencing those parts without changing any of the defined signaling and electrical (or optical) parameters. The IEC 61158-2 standards take precedence over this Fieldbus Foundation profile in the event of any conflict of requirements.
- to address Intrinsic Safety applications using either the traditional Entity model or the newer Fieldbus Intrinsically Safe Concept (FISCO). The mixing of the Entity model with the FISCO approach in the preparation of a system design is not recommended.
The purpose of this part of FOUNDATION Specifications is to define the service provided to the FAS (Fieldbus Access Sublayer) and SM (System Management) at the boundary between those layers and the FF Data Link Layer.
The Fieldbus Data Link service definitions in this document are a subset of the services defined in the IEC/TS 61158 Data Link Layer documents. This document describes the services and parameters for those services, which are used by FF FAS and SM. Only the summary of the services used by the FOUNDATION Data Link service definitions subset are specified in this document. The behavior of the service is the same as defined in the referenced IEC/TS 61158 Data Link Layer documents, unless specified otherwise. Therefore, it is necessary to read the referenced IEC/TS 61158 Data Link Layer documents for the full specifications of the services.
The purpose of this part of FOUNDATION Specifications is to define the FF Data Link Layer protocol. The Fieldbus Data Link protocol specification in this document is a subset of the specifications described in the IEC 61158 Data Link layer (IEC/TS 61158-4:1999). This subset is selected to provide the services defined in FF-821, Data Link Services Subset. In addition, this protocol subset includes node initialization, link initialization, address assignment, time-synchronous scheduling, and “Token-passing”. This document specifies:
- the elements of procedure to describe the interactions between a DL-service (DLS) provider and a DLS-user for all service primitives
- the structure of the Fieldbus Data Link (DL) Protocol Data Units used for the transfer of data and control information, and their representation as Physical Interface Data Units
- the interactions among two or more DL-entities (DLEs) through the exchange of Fieldbus Data Link Protocol Data Units
The base document is IEC/TS 61158-4 :1999. The base document and this document together form the complete specification.
The scope of this documentation is limited to conformance testing and excludes performance testing and interoperability testing. The introductory part presents a framework and methodology, based on ISO/IEC 9646, for testing conformance to the FOUNDATION Fieldbus specification. This provides sufficient information to facilitate test laboratory facility and equipment planning. The approach is independent of the test tools (equipment and software) which the users of the documentation might select for the purpose. Guidance for procurement of such tools is provided by indicating key parameters and their test equipment requirements. The present FOUNDATION™ Physical Layer profile is limited to a bit rate of 31.25 kbit/s. Future bit rate increases to 1 Mbit/s and 2.5 Mbit/s will require higher specification test equipment.
The scope of the power supply self test specification include:
- Tests that determine if a fieldbus power supply complies with the requirements stated in the IEC 61158-2: 2003 standard.
- Tests for other power supply requirements related to Foundation Fieldbus in FF-816 FS 1.5 Physical Layer Profile.
- Tests beyond the requirements of the standards that determine if the power supply is fit for its intended purpose of powering a fieldbus network. Therefore some implementations will meet the requirement of the Standard IEC61158-2 but will not pass the conformance test.
The objective of this Specification is to define Fieldbus cable specifications and conformance tests such that cables with the required characteristics and passing the tests performed by the manufacturer can be registered and received the Foundation’s checkmark. This will provide greater assurance to end users that their Fieldbus wiring systems are suitable for Fieldbus operation. The scope of the cable specification includes:
- Compliance with the requirements stated in the IEC 61158-2: 2003 standard.
- Requirements beyond those of the standard that determine if the cable is fit for its intended purpose of wiring a fieldbus network. Therefore, some cables will meet the requirement of the Standard IEC 61158-2: 2003 but may not pass this Specification’s requirements
The scope of the test specification includes:
- Tests that determine if a fieldbus device coupler complies with the requirements stated in the IEC 61158-2: 2003 standard.
- Tests for other device coupler requirements related to Foundation Fieldbus in FF-816 FS 1.5 Physical Layer Profile.
- Tests beyond the requirements of the standards that determine if the device coupler is fit for its intended purpose of preventing spur short-circuits from disrupting a fieldbus network. Therefore some implementations will meet the requirement of the Standard IEC61158-2 but will not meet the requirements of this test specification.
The Fieldbus Message Specification (FMS) is based on a series of object oriented models that provide distributed applications with the capabilities and services necessary for their implementation in an open, interoperable environment. This specification should be read in conjunction with Fieldbus Access Sublayer, Network Management and System Management Specifications.
The Fieldbus Foundation Fieldbus Access Sublayer (FAS) provides for interfaces to its service users and the Fieldbus Foundation Data Link Layer (DLL). This specification defines the FAS model, the FAS services, and its protocol.
This specification is intended to be read in conjunction with the Fieldbus Foundation Fieldbus Message Specification (FMS), Fieldbus Foundation Network Management Specification, and Fieldbus Foundation Data Link Layer Services and Protocol specifications.
The purpose of this specification is to define the system management model and services in Fieldbus systems. System management is used to coordinate the operation of the various devices in a distributed fieldbus system.
System management functions include node address assignment for devices, application clock synchronization, distributed application scheduling across the segment, and support for locating application tags. It provides the facilities which are needed to bring new devices on the segment to an operational state, and to control the overall system operation.
Following is a small subset of the things not specified in this document:
- Operation of SM on bridges.
- A means of specifying and documenting device behavior on power up
- Coordination between scheduled objects in SMIB and LAS schedule.
The purpose of this specification is to allow the field devices of any manufacturer to receive software upgrades from any host. The software upgrade for a device may consist of one or more binary images. The following sections describe the procedure for downloading one or more binary images without regard to their purpose or content.
This Common Software Download Specification (CSDS) is independent of the device architecture. The specification only specifies the services, objects, and the object behavior associated with downloading software to a device. It does not address system issues such as security, user interfaces, etc. This addendum does not preclude alternate means of upgrading software. The format of the binary image (syntax and semantics) is outside of the scope of this specification. Vendors may have proprietary syntax and semantics in this image to support, for example, incremental downloads or downloads of specific blocks.
Support for this Common Software Download procedure is optional.
Function block applications are defined in the FOUNDATION Fieldbus System Architecture as plant or factory applications that perform one or more automatic monitoring and control functions. These functions are modeled in this document as function blocks.
Field devices may operate in manufacturing and process control environments that include intrinsic safety requirements. This creates a need for devices that operate with limited memory and processing power, and buses that operate using very low bandwidth.
The purpose of this specification is to support the standardization of function block definitions for use in function block applications. The scope of this specification is to define:
- the characteristics of function block applications and their function blocks
- a base set of function block types, and
- a mechanism for the definition of specialized function block types by user groups and device vendors.
This specification consists of five parts:
- Part 1 - contains the introduction, technical overview, architecture, formal models, operation descriptions, and mapping to FMS.
- Part 2 - contains the block parameter and implementation details for an initial set of ten function blocks and the resource block. These definitions meet basic measurement and control requirements.
- Part 3 - contains the block parameters and implementation details of blocks to address more advanced calculation. Also, blocks are included for device control and discrete processing which meet many requirements of the process industry.
- Part 4 - contains components added to the Part 1 architecture and model to address special requirements of manufacturing automation.
- Part 5 - contains components added to the Part 1 architecture and model to address special requirements of user applications.
Additional blocks developed in the future which address common fieldbus requirements will be documented as other parts of this specification.
Function block applications are defined in the FOUNDATION Fieldbus System Architecture as plant or factory applications that perform one or more automatic monitoring and control functions. These functions are modeled in this document as function blocks.
Field devices may operate in manufacturing and process control environments that include intrinsic safety requirements. This creates a need for devices that operate with limited memory and processing power, and buses that operate using very low bandwidth.
The purpose of this specification is to support the standardization of function block definitions for use in function block applications. The scope of this specification is to define:
- the characteristics of function block applications and their function blocks
- a base set of function block types, and
- a mechanism for the definition of specialized function block types by user groups and device vendors.
This specification consists of five parts:
- Part 1 - contains the introduction, technical overview, architecture, formal models, operation descriptions, and mapping to FMS.
- Part 2 - contains the block parameter and implementation details for an initial set of ten function blocks and the resource block. These definitions meet basic measurement and control requirements.
- Part 3 - contains the block parameters and implementation details of blocks to address more advanced calculation. Also, blocks are included for device control and discrete processing which meet many requirements of the process industry.
- Part 4 - contains components added to the Part 1 architecture and model to address special requirements of manufacturing automation.
- Part 5 - contains components added to the Part 1 architecture and model to address special requirements of user applications.
Additional blocks developed in the future which address common fieldbus requirements will be documented as other parts of this specification.
Function block applications are defined in the FOUNDATION Fieldbus System Architecture as plant or factory applications that perform one or more automatic monitoring and control functions. These functions are modeled in this document as function blocks.
Field devices may operate in manufacturing and process control environments that include intrinsic safety requirements. This creates a need for devices that operate with limited memory and processing power, and buses that operate using very low bandwidth.
The purpose of this specification is to support the standardization of function block definitions for use in function block applications. The scope of this specification is to define:
- the characteristics of function block applications and their function blocks
- a base set of function block types, and
- a mechanism for the definition of specialized function block types by user groups and device vendors.
This specification consists of five parts:
- Part 1 - contains the introduction, technical overview, architecture, formal models, operation descriptions, and mapping to FMS.
- Part 2 - contains the block parameter and implementation details for an initial set of ten function blocks and the resource block. These definitions meet basic measurement and control requirements.
- Part 3 - contains the block parameters and implementation details of blocks to address more advanced calculation. Also, blocks are included for device control and discrete processing which meet many requirements of the process industry.
- Part 4 - contains components added to the Part 1 architecture and model to address special requirements of manufacturing automation.
- Part 5 - contains components added to the Part 1 architecture and model to address special requirements of user applications.
Additional blocks developed in the future which address common fieldbus requirements will be documented as other parts of this specification.
Function block applications are defined in the FOUNDATION Fieldbus System Architecture as plant or factory applications that perform one or more automatic monitoring and control functions. These functions are modeled in this document as function blocks.
Field devices may operate in manufacturing and process control environments that include intrinsic safety requirements. This creates a need for devices that operate with limited memory and processing power, and buses that operate using very low bandwidth.
The purpose of this specification is to support the standardization of function block definitions for use in function block applications. The scope of this specification is to define:
- the characteristics of function block applications and their function blocks
- a base set of function block types, and
- a mechanism for the definition of specialized function block types by user groups and device vendors.
This specification consists of five parts:
- Part 1 - contains the introduction, technical overview, architecture, formal models, operation descriptions, and mapping to FMS.
- Part 2 - contains the block parameter and implementation details for an initial set of ten function blocks and the resource block. These definitions meet basic measurement and control requirements.
- Part 3 - contains the block parameters and implementation details of blocks to address more advanced calculation. Also, blocks are included for device control and discrete processing which meet many requirements of the process industry.
- Part 4 - contains components added to the Part 1 architecture and model to address special requirements of manufacturing automation.
- Part 5 - contains components added to the Part 1 architecture and model to address special requirements of user applications.
Additional blocks developed in the future which address common fieldbus requirements will be documented as other parts of this specification.
Function block applications are defined in the FOUNDATION Fieldbus System Architecture as plant or factory applications that perform one or more automatic monitoring and control functions. These functions are modeled in this document as function blocks.
Field devices may operate in manufacturing and process control environments that include intrinsic safety requirements. This creates a need for devices that operate with limited memory and processing power, and buses that operate using very low bandwidth.
The purpose of this specification is to support the standardization of function block definitions for use in function block applications. The scope of this specification is to define:
- the characteristics of function block applications and their function blocks
- a base set of function block types, and
- a mechanism for the definition of specialized function block types by user groups and device vendors.
This specification consists of five parts:
- Part 1 - contains the introduction, technical overview, architecture, formal models, operation descriptions, and mapping to FMS.
- Part 2 - contains the block parameter and implementation details for an initial set of ten function blocks and the resource block. These definitions meet basic measurement and control requirements.
- Part 3 - contains the block parameters and implementation details of blocks to address more advanced calculation. Also, blocks are included for device control and discrete processing which meet many requirements of the process industry.
- Part 4 - contains components added to the Part 1 architecture and model to address special requirements of manufacturing automation.
- Part 5 - contains components added to the Part 1 architecture and model to address special requirements of user applications.
Additional blocks developed in the future which address common fieldbus requirements will be documented as other parts of this specification.
The Device Description Language (DDL) describes a language based system to describe the contents of field devices. This document describes all the components necessary to implement a DDL system. It should be read in conjunction with Function Block Application Process, Parts 1 & 2 [FF-890, FF-891], and the Device Implementer’s Guide [FD-102].
This document supplements the Device Description Language Specification [FF-900] to promote DDL application interoperability and maximize DD portability between DDL applications. This document is not a DDL tutorial and is not intended to replace the DDL specification.
The purpose of this document is to describe transducer block base parameter sets and characteristics common to Process Control devices.
This document provides further discussion and definition of the function block application process as it applies to devices, rather than to control systems. The transducer block of FF-890 is further defined.
The purpose of a Transducer Block Definition is to describe base parameter collections and characteristics common to the specific aspects of a class of device. The same parameter collections can be applied to a device whose primary or only function is the specific aspect covered by a Transducer Block Definition, or the collection can be applied by other field devices that have the specific aspect as a secondary variable. This Transducer Block Definition describes base parameter collections and characteristics common to the measurement of pressure.
The purpose of a Transducer Block Definition is to describe base parameter collections and characteristics common to the specific aspects of a class of device. The same parameter collections can be applied to a device whose primary or only function is the specific aspect covered by a Transducer Block Definition, or the collection can be applied by other field devices that have the specific aspect as a secondary variable.
The purpose of a Transducer Block Definition is to describe base parameter collections and characteristics common to the specific aspects of a class of device. The same parameter collections can be applied to a device whose primary or only function is the specific aspect covered by a Transducer Block Definition, or the collection can be applied by other field devices that have the specific aspect as a secondary variable.
The purpose of a Transducer Block Definition is to describe a set of base parameters and characteristics common to the specific aspects of a class of device. The same set of parameters can be applied to a device whose primary or only function is the specific aspect covered by a Transducer Block Definition, or they can be applied by other field devices that have the specific aspect as a secondary variable.
This document defines optional and mandatory parameters for ISA 100.11a transducer blocks in addition to "FF-902 Transducer Block Common Structures".
The transducer block used to access parameters and/or resources for ISA 100.11a devices within FOUNDATION Fieldbus gateways applies to the wireless gateway and also to the HSE Remote Input/Output gateway.
The purpose of the communication profile is to assure a degree of interoperability among hosts and field devices that are interconnected to form a fieldbus system. This is done by defining certain profile classes of communication functionality for field devices, of hosts and of related support equipment. This profile defines the minimum level of communication functionality and features that shall be supported by each of the classes. The functionality and features are chosen in a way to enable the building of fieldbus systems by the mixing of devices of different profile classes from different vendors. The communication functionality and features in each of these profile classes represents a specific combination of functionality and features selected from the Fieldbus Foundation’s Physical, Data Link, FAS, FMS, Network Management and System Management specifications. FF communications stack software can be certified as meeting one or more of these profiles. Devices may also be certified as meeting one or more of these profiles, although proper behavior of the service interfaces enumerated in this document as mandatory for a class can be tested only by inference, and not by direct observation.
The purpose of the communication profile is to assure a degree of interoperability among devices that are interconnected using an FF HSE network. Defining certain profile classes of field devices, linking devices, hosts and of related support equipment does this. This profile defines the minimum level of capabilities that shall be supported by each of the classes. The capabilities are chosen in a way to enable the building of HSE systems by the mixing of devices of different profile classes from different vendors. Each of these profile classes represents a specific combination of capabilities selected from the Fieldbus Foundation’s Ethernet Presence, Field Device Access Agent, HSE Network Management, HSE System Management and HSE Redundancy specifications. Devices may also be registered as meeting one or more of these profiles.
The purpose of this document is to offer an easy way of mapping field device requirements to ITK versions. ITK traceability to specifications is difficult because of several reasons:
- ITK and FOUNDATION specifications have different product maintenance cycles.
- New device requirements are spread into several specification documents.
This document is also intended to better highlight future mandatory requirements for field devices.
This document defines the requirements, definitions and features for a FOUNDATION Fieldbus HSE-Remote I/O (RIO) in addition to FF-894 – Function Block Application Process.
This document defines optional and mandatory parameters for FF HSE-Remote I/O module transducer blocks in addition to FF-902 “Transducer Block Structures”.
Some users need to be able to interface HART® and WirelessHART™ devices to FOUNDATION™ fieldbus to improve their integration into a control system and integration with Fieldbus Foundation devices. A networked method for an asset managing host to access a large set of HART and WirelessHART™ devices for HART configuration and HART maintenance purposes is also needed.
This specifies a Fieldbus Foundation transducer block used to represent HART devices within Fieldbus Foundation gateways. Both wired HART and WirelessHART™ devices may be represented. This specification also describes the expected method for HART tool such as a configuration tool or an asset managing host to access the HART or WirelessHART™ devices using the native HART command protocol transported through the Fieldbus Foundation HSE network.
This also specifies a Fieldbus Foundation transducer block used to represent HART Gateway within Fieldbus Foundation gateways to provide access to the HART portion of the gateway using HART protocol.
The scope of this specification includes architecture-related additions to the FOUNDATION Fieldbus architecture that are required to meet the uses of the modular architecture extensions such as the HSE remote input/output unit and the wireless gateway, and descriptions contained within this document may not be applicable to H1 devices or other FOUNDATION™ fieldbus devices.
This guide has been prepared to aid understanding of the technical aspects of FOUNDATION Fieldbus. The document includes a brief summary of fieldbus benefits followed by the goals, principles and organization of the not-for-profit Fieldbus Foundation. The main portion of the guide is devoted to the definition and explanation of key technical concepts inherent in FOUNDATION Fieldbus technology.
This application guide has been prepared to aid understanding of the application considerations of FOUNDATION™ Fieldbus. It addresses both developers and users. The guide provides an overview of 31,25 kbit/s intrinsically safe Fieldbus Systems, followed by an outline of the specifications of field devices and other related equipment.
The updates in revision 2.0 follow the actual state of the art of intrinsically safe fieldbus technology. The booklet provides guidance on certifying equipment and offers advice on sound design and installation practices. Having read the Introduction and Fundamentals of Part 1, the reader will follow the Entity model in Part 2 or alternatively the FISCO model in Part 3. Part 4 deals with fieldbus installation and shows other variants of explosion protected fieldbus systems that include Intrinsic Safety, such as the IIB/IIC split architecture concept and the field bus barrier concept.
This guide provides application notes and advice for wiring and installation of 31.25 kbit/s FOUNDATION Fieldbus networks. It is based on the current approved definition of the Fieldbus Foundation Physical Layer and on the appropriate IEC and ISA Physical Layer Standards which are identified in this document.
This guide describes possible applications in order to facilitate understanding of the uses for the Flexible Function Block and the various methods required to create them. The applications describe analog, discrete and hybrid applications for Flexible Function Blocks. The specification consists of examples for the use of normative statements made in the FF-89x Function Block Application Process specifications. This guide is informative.
This guide provides the definition of the design, specification, installation, configuration, commissioning for a FOUNDATION fieldbus-based control systems. This guideline will only discuss the voltage mode (parallel coupling) medium attachment unit, as defined in ISA 50.02 and IEC 61158, operating at a signal speed of 31.25 k/bits per second (i.e., H1).
The purpose of this Technical Note is to describe the format of Device ID (DEV_ID) specified in FF-880 “System Management.” In order for each device to be unique in FOUNDATION fieldbus networks around the world, each FF device must be identified with a unique DEV_ID.
The purpose of this document is to define the rules and values for the Profile and Profile Revision header parameters.
The purpose of this document is to clarify the meaning of maximum FMS PDU length.
The purpose of this document is to clarify the intention of the Network Management Specification with regards to the prevention of additional NM VCRs being configured with FMS_WRITE enabled.
The purpose of this document is to clarify the write response to an unused VcrListControlVariable.
The purpose of the Units Codes index is to provide a standard set of globally defined code numbers to communicate scaling constants between Function Blocks and standard display strings for use in Device Descriptions.
This TechNote clarifies the behavior of a device when it is ready (after waiting for the inter-PDU delay) to issue the reply to a CD addressed to one of its DLCEPs and it detects either noise on the bus or the initial portion of another DLPDU on the bus.
The scope of this addendum includes data structure additions to the FOUNDATION™ Fieldbus architecture that are required to meet the uses of the modular architecture extensions such as the HSE remote input/output unit and the wireless gateway.
This document provides a conversion from HART engineering unit codes to FOUNDATION™ fieldbus engineering unit codes. Since some HART engineering units are not represented in FOUNDATION™ fieldbus, the conversion for those engineering units is blanks (no units). The table does not provide a reverse mapping from FOUNDATION™ fieldbus to HART since it is intended to permit only a HART configuration or maintenance tool to change the engineering units in the HART device. Therefore, the FOUNDATION™ fieldbus viewer has a read-only view of the engineering units converted into FOUNDATION™ fieldbus engineering units.
Additional description?
The technique for establishing multiple View 3’s and View 4’s in a device and its Object Dictionary is well known. This application note addresses how to write the Device Description (DD) for blocks that contain View 3’s and View 4’s objects with additional entries.
The function block specification requires that devices restore static and NV parameters after a power failure. This application note provides general guidelines on how often these parameters should be stored in non-volatile memory in order to support power failure recover.
The purpose of this document is to describe application guidelines for building devices and hosts and to identify specification enhancements which improve the user experience when replacing devices. It is also expected that less end-user’s knowledge about Foundation Fieldbus intricacies are required and that such replacement becomes faster and does not disturb the network. The intention is to simplify the functionality of reproducing a existing FF device configuration (all FBs and parameters) onto a new FF device to allow quick device replacement (FCG_AG30181).
The purpose of this document is to establish clear guidelines to orient Host systems and device vendors on how to implement suitable support to Block Instantiation and Capability Level so as to prevent system interoperability problems. It addresses different topics related to Block instantiation and Capability Levels together. In order to speed up adoption of the technology, some guidelines in this document recommend the removal of some of the more complex and error prone features related to Block Instantiation and Capability Levels, such as self-instantiation and combinable level.
The purpose of this application note is to illustrate how to recover the symbols.txt file used during tokenizing the DD files for a device if the symbols file is lost or no longer available and it is desirable to build on existing definitions without redefining the DD Member ID or the DD Item ID for customizations done on the standard library.
The main purpose of this document is to provide a common set of test cases to reduce multivendor interoperability issues in end user systems and assist in meeting end user expectations from multivendor solutions. These common tests will allow device and host developers an expectation of what areas may be tested with a host system with a particular device. These test cases will allow the developer to test their product in an
effort to progress development of their device before release or allow for expected standards for external testing with host systems. These test cases are to assist in identifying usability and interoperability issues in the integration of multivendor system solutions and are developed independent of any host system and any caveats of any particular system design. This document is an ongoing process and is expected to be updated with the latest functionalities within the Fieldbus specifications.
This document is to provide a guide on the proper use of the mode parameter within transducer blocks.
The purpose of this application note is to clarify how Integrated (also called Permanent) hosts and Visitor hosts can interoperate in order to allow a Visitor host to interact with field devices in the presence of an Integrated host.
The purpose of this application note is to provide a simple guide to understanding the functionality of Foundation Fieldbus Alarms. The communication between the device and the host, as well as device internal functionality is covered.
The purpose of this document is to provide guidelines for device vendors as they develop Device Description version 4 (DD4) files for support with legacy host systems. Device Description Services (DDS) version 4 has certain size-limitations with regards to the structure of the DD binary files. A device vendor must implement and test DD4 files—to be compatible with legacy host systems—in order to register their device. In a few cases, a device’s DDs may become large enough where the Tokenizer will give error when trying to build the binary file and the vendor will not be able to proceed with registering their DDs. This document will provide details on the problem that can be encountered as DDs grow in size during development and it will provide guidelines that can be followed to reduce the size of the DD sufficient to build the binary and support compatibility with legacy host systems.
The purpose of this application note is to illustrate how discrete variable values as defined by the DS-66 data type, are interpreted in conjunction with state tables. While this is fundamental to DO and DI blocks, it is not limited to those blocks, but will be used in conjunction with all DS-66 data types that have a unit relationship that is either a constant or defined by a unit relationship with a state variable.
FieldComm Group members get free electronic downloadable access (please contact support if you do not have an account). Specifications and documents ordered as a non-member will be provided as a hard copy only. All items are sold and shipped from our Austin, TX location. Shipping is included, but any customs fees assessed by different countries and locales are the responsibility of the ordering company and will not be paid by FieldComm Group.