Modeling and Control

As the Fieldbus Foundation (FF) function block specification was being developed, I became aware of the work by International Electrotechnical Commission, IEC, on function block modeling. The IEC TC65C/WG6 (now SC65B/WG15) committee had produced some draft documents that would eventually become the IEC61499 Function Block Standard. This standard defines abstract models that may be used by other IEC standard committees to write function block standards that are specific to industry segments. The WG6 committee’s work was of interest since these early drafts contained terminology and architectural concepts that may be used to precisely describe the distributed environment of fieldbus networks. Thus, in editing the function block specifications, we were able to adopt many of the WG6 definitions and architectural concepts into part 1 of Fieldbus Foundation (FF) Function Block speciation. This part of the specification describes the architecture and formal model of the function block application process. On several occasions, I met with Jim Christensen, Chairman of WG6, to discuss and review different aspects of the function block specification. Eventually, I joined WG6 as one of the US Experts and actively participated in the committee meeting for a few years. As a result of this cooperation, the terminology and even many of the architecture drawing included in the Fieldbus Foundation function block specifications are well aligned with those in the final IEC61499 standard.

Soon after the Fieldbus Foundation specifications were published, IEC formed the SC65C/WG7 (now SC65E/WG7) committee to standardize Function blocks (FB) for process control. I joined this committee as one of the US Experts and have actively contributed to this effort. The IEC61804 standard was produced by the WG7 committee. One of the primary tasks of the committee was to creating a function block standard that addresses the requirements of the process industry. The abstract model defined by the IEC 61499 preliminary standard and the work by ISO 15745-1 helped set a foundation for this work, as illustrated in the introduction of the IEC 61804 standard. Also, the function block specification work by the Fieldbus Foundation, Profibus International, and the Noah European project influenced the IEC 61804 standard. In particular, some key technical requirements addressed this standard are:

Deterministic block execution
Block types for resource management, measurement processing and function
block classes for measurement, calculation and control.
Mode parameter
Function block input/output parameter status
Contained parameters of a block for the support of configuration and plant operation
e.g. tuning parameters, setpoint, and mode.

In addition, the IEC 61804 standard addresses a means for a manufacturer to precisely describe the application within a field device through the use of an Electronic Device Description Language, EDDL. The constructs defined by this language allow the manufacturer define calculations and interactions needed to support device calibration and diagnostics. The EDDL defined in the IEC61804 standard is a superset of the device description language utilized by the Hart Communication Foundation, Fieldbus Foundation, and Profibus international. Thus, IEC 61804 is an important standard for the process industry. EDDL is utilized by handheld devices and engineering stations that support HART, Fieldbus Foundation and Profibus devices. The function block application process utilized by Foundation and Profibus fieldbus devices is consistent with the IEC 61804 standard.

The physical standard and technical report produced by ISA SP50 were used as a starting point for much of the work done by the Fieldbus Foundation. In particular, the Fieldbus Foundation function block specification team adopted some basic concepts such as the definition of mode and status with minor changes from the definitions contained in the SP50 User Layer technical report. However, as work progressed on the Fieldbus Foundation function block specification, we found it necessary to expand the block types that were documented in SP50 and to change the way blocks were structured, defined, and implemented. Much of this change was driven by input from control system and field device manufacturers.

The Foundation function block specification team initially collected information on measurement, calculation and control functions and associated parameters that were common to the major suppliers of process control system. Through an analysis of this capability, we were able to identify functionality and parameters that were common to these manufacturers. Based on this work, the specification was broken into two parts. Part one of the specification contains a description of the architecture and formal model of the Function Block application process. In this part of the specification we addressed the components that make up the function block application process. To provide precise definitions that are sufficient to support implementation, the model is based on an object oriented design. Part 2 of the specification contains a basic set of ten function blocks that utilize the model and architecture defined in part 1 of the specification. This initial set of blocks addresses a variety of common measurement and control applications.

The function blocks defined for measurement and actuation were base on the parameters found in major process control systems. However, a fieldbus device must also contain many other parameters to support measurement and actuator diagnostics and calibration. We initially pursued the concept of the manufactures adding parameters to the basic IO blocks for device diagnostics and calibration. However, it soon became clear that this would lead to IO function blocks that were specific to each manufacture. If we took this approach then it would be necessary to know upfront what devices would be used in a particular installation before it would be possible to do basic control configuration. Our goal was to allow measurement, calculation and control to be configured independent of the device manufacturer. Thus, the concept of a transducer block was introduced into the architecture and block model. The transducer block serves as a container of calibration and diagnostic parameters associated with IO processing. By taking this approach, it was possible to design the IO function blocks that are the same for all device manufacturers.

A third type of block, the resource block, was defined to contain parameters associated with the physical device or are global to all function blocks. Some example of these typed of parameter are the manufacturer identification number and selections to enable or disable write lock protection. The specification requires that all fieldbus device support a resource block. Part 2 of the specification defines the resource block’s parameters. Only one resource block may be defined in a fieldbus device.

The IEC61804 international standard, Function Block for Process Control, includes the three blocks types defined by the Fieldbus Foundation function block specification. The transducer block is referred to in the standard as a Technology block. Thus, because of this consistency in definition, Foundation fieldbus devices comply with this standard. If you have an interest in learning more about the Fieldbus Foundation’s function block specification or the IEC61804 standard, then copies of these documents may be purchased at the following sites:

Fieldbus Foundation Specification

IEC61804 Standard

With the introduction of digital field devices, manufactures of control systems and maintenance tools were faced with the challenge of how to access and display information in devices that were produced by different companies. Over the years, a number of approaches have been developed. However, the Electronic Device Description Language (EDDL) is the dominant technology used in the process industry to support interfacing to digital devices. There are more than 15 million installed devices that support access to diagnostic and calibration information through the use of EDDL. A device manufacture may use EDDL to fully describe the data that is accessible in a field device. Also, this language allows the manufacturer to define the user interface and operating procedures needed for calibration and diagnostics. Quite complex interfaces and interactions are fully supported since EDDL addresses such things as commands, menus and display formats. The latest version of EDDL fully supports the use of menus, windows, tabs and groups and graphic support for graphs, trends, charts and dial indicators. Device description files that are created using EDDL are known as Electronic Device Descriptions, EDD. An engineering station or handheld that is EDDL enabled is designed to use EDD files to support diagnostics and calibration of devices. New EDD’s for device updates or new devices introduced by a manufacture may be added to an EDDL enabled control system or maintenance tools without worrying about software viruses, revision levels, etc. This is because the EDDL file is simply interpreted by these systems and there is no requirement to load software components such as dll’s into these tools. This is the major advantage that EDDL has over competing technologies such as FDT/DTM that require executable software components to be incorporated into engineering systems and handheld device.

The EDDL capability that we have today is the results of a cooperation effort by Fieldbus Foundation, HART Communication Foundation, PROFIBUS Nutzerorganisation e.V., and the OPC Foundation. These organizations fully support the use of EDDL for device description. The latest version of EDD’s for any device certified by these organizations can be downloaded simply by going to their web site. For more information on the support that is provided for EDD’s, you can visit the Fieldbus Foundation, HART Communication Foundation, or Profibus International web sites. The Electronic Device Description Language is a recognized international standard, IEC61804. Even though IEC6180 is an international standard and is supported by most manufacturers, many end users are unaware of this technology or how it compares to competing technologies such as FDT/DTM. Thus, in late 2005 I submitted a proposal to ISA to adopt the IEC61804 standard as an ISA/ANSI standard. As explained in this proposal, the primary reason for establishing EDDL as an ISA/ANSI standard is to help raise awareness in the process industry of the important role that EDDL plays in the process industry today and to convey the advantages this technology has over competing technologies such as FDT/DTM.

In response to my proposal, ISA announced in early 2006 the formation of SP104. Since I submitted the proposal to create this committee and was the US expert on the IEC SC65E WG7 committee that wrote the IEC61804 standard, I was asked to be the committee chairman. The editor of the IEC61804 standard, Ludwig Winkel, Siemens, is the vice-char of SP104. There has been a great response within industry to the formation of the SP104 committee. The committee currently consists of 10 members from the US, China, Singapore, Germany and France. Each member brings a variety of experiences and knowledge of the process industry.

Since our first meeting in October, 2006, the SP104 committee has made significant progress. In our first meeting we agreed to adopt the IEC61804 standard and to distribute this document for vote. This document is currently in the stage of public review. In addition, key team lead positions within the committee have been filled:

 Marketing – Ed Ladd, HART Communication Foundation
 Education – Jonas Berge, Emerson
 Certification – Christian Diedrich, University of Magdeburg
 Liaison to IEC, ISO and Consortia groups – Ludwig Winkel, Siemens

Over the last few months, the SP104 committee has been working with ISA on the design of a web site. This web site will be dedicated to information and educational material on EDDL technology. Through this initiative, the SP104 committee will introduce a variety of new material on EDDL that may be easily accessed by anyone from industry. This site should be on-line by early spring. Also, the committee plans to sponsor sessions and workshops on EDDL at some of the major trade conferences scheduled for later this year. Thus, you should be hearing more about EDDL over the next few months.