DOC PREVIEW
UT EE 382C - An Extension to the Foundation Fieldbus Model for Specifying Process Control Strategies

This preview shows page 1-2-3 out of 10 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

An Extension to the Foundation FieldbusModel for Specifying Process Control StrategiesEE382C: Embedded Software Systems, Spring 1999Prof. Brian L. EvansDepartment of Electrical and Computer EngineeringThe University of Texas at AustinMichael SchaefferMay 8, 1999Abstract: As the process control community moves towards openstandards, efforts like the Fieldbus Foundation’s Foundation Fieldbus willplay an increasingly prominent role. This paper discusses an effort tointegrate an imperative programming language into the dataflowprogramming model specified by Fieldbus.Copyright 1999 by Michael Schaeffer page 1 of 10IntroductionAs society enters the 21st century, one of the more profound differences betweennow and the previous century is the important role of large scale chemical productionfacilities. These facilities are instrumental in making the refined chemicals needed forthe production and usage of manufactured goods. Everything from aspirin to motor oilare made in immense quantities by automated production lines, and as our society hasgrown, so too have our demands on these production facilities. To meet this demand, aprocess control industry has emerged to help automate and control the processes ofchemical refining and production.A typical process control application is controlling the level of fluid in a reactorvessel. The process control system is composed of some form of programmable logiccontroller (PLC) and a collection of I/O sensors that interface it to the outside world.For controlling the level of fluid in a tank, there will be a pressure sensor to measure thefluid level and a valve to control the rate at which fluid flows into the tank. Theindustrial computer will sample the level sensor periodically, compare the actual valueagainst the desired value, and calculate a new position for the valve, typically using thePID control algorithm. Currently, the control algorithm is usually implemented in oneof the five IEC1131 languages, sometimes BASIC, and resides entirely on the PLC. ThePLC monitors the level sensor and controls the valve using a pair of wires for eachdevice and monitoring or controlling the current in the wiring loop between the deviceand the PLC. Two of the main disadvantages to this approach are a high cost to thewiring between the PLC and the devices, and a closed product architecture. Typically,vendors develop a product architecture that strongly favors staying within a givenproduct lineup; this can lead to increased engineering costs for control solutions.Copyright 1999 by Michael Schaeffer page 2 of 10In an effort to solve some of the issues of process control, one of the more recentdevelopments in the process control field is Foundation Fieldbus. Foundation Fieldbusis a specification that combines a networking protocol and an application model. Thenetworking protocol defines a standard that allows intelligent devices to co-exist on onenetwork. By defining a class of periodically scheduled traffic, the Fieldbus networkingstandard allows devices to communicate with each other in a predictable fashion inwhich a basic level of functionality is guaranteed. In addition to the network standarddefined by Fieldbus, the Fieldbus specification defines an object oriented applicationmodel and a set of objects built using that model in which to build interoperable controlsystems. To provide a guarantee of interoperability, Fieldbus devices are formallytested against these specifications before they can be certified as an interoperabledevice.This paper will introduce the application model of Foundation Fieldbus anddiscuss the development of an extension to that model. The design choices involved inmaking the extension will be discussed, along with the effects of the extension on thecomputational capabilities of Fieldbus. Finally, a few alternatives for futureadvancement of control system specification in Fieldbus will be discussed.A Variant of Synchronous DataflowThe fundamental object in a Fieldbus control application is the function block.Analogous to stars in the Ptolemy dataflow toolset [2], a function block is an actor in adataflow network. Function blocks can contain input parameters that subscribe toinformation published by output parameters on other function blocks. The connectionsbetween input and output parameters are defined by another Fieldbus object– thelinkage object. [3] The linkage object contains the information used to bind twoCopyright 1999 by Michael Schaeffer page 3 of 10parameters together, including an optional network connection that can be used if thefunction blocks being linked exist on different devices.Once this dataflow graph has been created, the devices containing the objects it iscomposed of must be configured to run the graph. Like the Synchronous dataflowmodel (SDF) the dataflow graph can be synchronized statically. [12] However, in starkcontrast to the SDF model, for each execution, Fieldbus function blocks are constrainedto produce or consume one data value per I/O parameter. This trivializes thecomputation of the repetitions vector (each node runs once) and thus trivializescomputing a schedule to computing a topological sort of the dataflow graph.The other significant departures from the SDF model are the notions of executiontime and concurrency. One of the central tenets of deterministic control in Fieldbus isthat the control application should run with predictable and consistent time behavior.To achieve this, the Fieldbus model requires each function block to have a declaredmaximum run-time. When scheduling the function blocks, they are scheduled relativeto a time offset, rather than to an ordering. As an illustration, where an SDF schedulewould read “fire block A and then fire block B”, a Fieldbus schedule would read “fireblock A at offset 0ms, fire block B at an offset of 10ms and repeat this cycle every 25ms.”As with block execution, communications on the Fieldbus also have a ‘declared’upper bound on the time in which they will take. Because of the predictable nature ofscheduled traffic on the Fieldbus, examining the communications parameters of the busallows the calculation of an upper bound on the length of time it takes to transmit aparameter from one device to another. As a result of this, it becomes possible to takeinto effect communications between multiple devices as the schedule is calculated. Afunction block graph can then be scheduled on multiple devices, and the concurrencyallowed by


View Full Document

UT EE 382C - An Extension to the Foundation Fieldbus Model for Specifying Process Control Strategies

Documents in this Course
Load more
Download An Extension to the Foundation Fieldbus Model for Specifying Process Control Strategies
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view An Extension to the Foundation Fieldbus Model for Specifying Process Control Strategies and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view An Extension to the Foundation Fieldbus Model for Specifying Process Control Strategies 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?