1、Fieldbus Standard for Use inIndustrial Control Systems:User Layer Technical ReportApproved 01 January 2000ISATR50.02, Part 92000TECHNICAL REPORTISA The Instrumentation,Systems, andAutomation Society TMISA would like to thank the former Chairman of SP50 and current SP50.4 member Cullen Langford for h
2、is outstanding contribution in editing ISATR50.02, Part 9, User Layer Technical Report, and for his integral role in converting the text into a suitable electronic format.ISA-TR50.02, Part 9-2000, Fieldbus Standard for Use inIndustrial Control Systems: User Layer Technical ReportISBN: 1-55617-718-6C
3、opyright 2000 by the Instrument Society of America. Allrights reserved. Not for resale. Printed in the UnitedStates of America. No part of this publication may bereproduced, stored in a retrieval system, or transmitted inany form or by any means (electronic mechanical,photocopying, recording, or oth
4、erwise), without the priorwritten permission of the Publisher.ISA 67 Alexander Drive P. O. Box 12277Research Triangle Park, North Carolina 27709vPrefaceThis preface, as well as all footnotes and annexes, is included for information purposesand is not part of ISA-TR50.02, Part 9-2000.This document ha
5、s been prepared as part of the service of ISA, the international societyfor measurement and control, toward a goal of uniformity in the field of instrumentation.To be of real value, this document should not be static but should be subject to periodicreview. Toward this end, the Society welcomes all
6、comments and criticisms and asks thatthey be addressed to the Secretary, Standards and Practices Board; ISA; 67 AlexanderDrive; P. O. Box 12277; Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax(919) 549-8288; E-mail: standardsisa.org.The ISA Standards and Practices Department is aware
7、 of the growing need for attention tothe metric system of units in general, and the International System of Units (SI) inparticular, in the preparation of instrumentation standards. The Department is furtheraware of the benefits to USA users of ISA standards of incorporating suitable referencesto th
8、e SI (and the metric system) in their business and professional dealings with othercountries. Toward this end, this Department will endeavor to introduce SI-acceptablemetric units in all new and revised standards, recommended practices, and technicalreports to the greatest extent possible. Standard
9、for Use of the International System ofUnits (SI): The Modern Metric System, published by the American Society for Testing a transmitter or a valve positioner. Wedidnt expect these products so soon, but they are already for sale and wereexhibited at the 1990 ISA Conference and Exhibit.5SP-50 User Lay
10、er Technical Report PrefaceFigure 1: Preface, Figure 1, Protocol ModelsPROTOCOL MODELOSI-ISO ModelField Bus ModelUserSP-50UserLayerSP-50ULServicesOtherUserLayersApplicationPresentationSessionTransportNetworkData LinkPhysicalData LinkPhysicalPresentation7654321Application Programs (notPart of the OSI
11、 Model)Provides all services forApplication Programs.Restructures data to/fromFormat used in NetworkName/address translation Access securityand Synchronizes dataProvides transparent, re-liable transfer, end to end.Hardware interface - for- Mats and un-formats packets and controls link access.Handles
12、s the transmissionand reception of raw bits.Provides message routing For datatransfer between adjacent nodes.721Physical Link6SP-50 User Layer Technical Report PrefaceFigure 2: NodeI/OHardwareNODEField BusPhysical NodeName DescriptorBus Address etc.* *Logical Node 0Logical NodeName, Descriptoretc.*F
13、unction Block nFunction Block 0Logical Node n*Function Block nFunction Block 0Logical NodeName, Descriptoretc.7SP-50 User Layer Technical Report PrefaceSo far these products still depend upon the use of either Proprietary or limitedavailability bus technology working together with 4-20 ma transmissi
14、on, however,their control parameters are available on those vendors systems products forremote tuning and control mode selection.The ISA Field Bus User Layer is oriented about the process control problemassuming a complete distribution of the scan and control functions all withinField Bus devices. T
15、he capability is provided for measurement, controlcalculation and final actuation in the same or separate nodes on the Field Bus,as necessary. Rather than taking a generalized message passing structure, theUser Layer has used a complete distributed object-oriented approach modeled afterseveral exist
16、ing distributed control systems (DCS) and programmable logiccontrollers (PLC) in common use. The choice of this model was very pragmatic -the DCS architecture has evolved from centralized computer control withincreasing distribution of functions and has been field proven to work. A modelconstructed
17、using only message passing without a semantic message structure wouldrequire the invention of an unproven mechanism. The committee has chosen toadapt its semantic model from those in common use. In addition, the architecturefor communicating with PLCs has been included in this same model. Methods us
18、edto configure or program DCSs and PLCs are not in the scope of this model.USER LAYER DEFINITION:How can the User Layer semantic model be described? In other words, whatsyntactical format can be used to express the process control semantic model? Wehave settled upon a two level procedure to describe
19、 the Field Bus User Layer asfollows:1. A description of the User Layer Machine; a description of theimplementation of the User Layer on a hypothetical high level languagecomputer base.2. A document abstracting the User Layer Machine into a set of equivalentrequirements which contain all of the criti
20、cal elements of thereferenced machine, but without the specific design content.The first document is called the “User Layer Technical Report.“ It was writtenby a committee interested in preserving the design of distributed control systems(DCS) which have proven to be useful and sufficient for a wide
21、 variety of time-critical applications in data acquisition and process control. The format of thedocument is that of a software design specification or an implementationdescription, simply because it was easier for the committee to write. It readssimilar to system descriptions of distributed control
22、 systems since this is theprimary source material within the experience of the committee. Sinceconsiderable criticism has been offered about the “over-specification“ of theTechnical Report, the subcommittee has decided to prepare a separate standarddocument.The second document is the true standard f
23、or the User Layer. It is writtenin “requirements language“, but without an implied implementation. Where themethod(s) of implementation are important to achieve the objectives of thestandard, they are explicitly stated. This is the document which will besubmitted for ISA (and eventually IEC) approva
24、l, but it will be incompletewithout the Technical Report which provides examples and much of the rationale.The technical content of both documents are intended to be identical. TheTechnical Report will always be updated to reflect the current status of thestandard for the User Layer.DIFFERENCES BETW
25、EEN DCS AND FIELD BUS:The Field Bus Process Control User Layer provides an application environmentnot unlike that of a distributed control system (DCS). The intent was not to8SP-50 User Layer Technical Report Prefacereplace the DCS, but to define the architecture necessary for a DCS tocommunicate wi
26、th smart field devices when control actions occur in those devices.There are many differences between Field Bus User Layer functions and thosetypically performed by a DCS.It has always been expected that the Field Bus would remove the functions ofprocess variable processing from the DCS. Similarly,
27、processing of outputs toproportioning process control valves and other actuator mechanisms is alsoincluded. DCSs operating with Field Bus devices will acquire process variablesin engineering units form. Likewise they will send a desired valve output as apercentage.Inclusion of control objects within
28、 Field Bus devices changes DCSfunctionality more substantially. We expect that many smaller systems will notrequire the traditional DCS at all, but will only require DCS-like operatorconsole(s). Larger systems, which will require a DCS, will use it to provide theupper level cascade controls and feed
29、forward controls. While Field Bus UserLayer provides some capability to build complex cascades and feedforward loops,these are intended to provide the backup to more complex loops built in the DCS.In all cases, we attempted to keep the Field Bus simple. For example, thereis no “ramp and soak“ algori
30、thm, because the committee felt that any algorithm wecould design would be inadequate to fulfill the needs of true batch control.Yet, we decided to provide simple setpoint ramping, determining that this time-critical function was best administered at the Field Bus level. Only one PIDalgorithm was ch
31、osen, to keep it simple. Our guideline was always to include thetime-critical items at the User Layer, but to eliminate the supervisory and highlevel calculation functions.FUNCTION BLOCKS:The architectural base of Field Bus is the function block, which performs thework of data acquisition, control a
32、nd output. Every function block contains analgorithm, a formula or rule, and a data base that is used by the algorithm. Theparts of the data base that are permitted to be accessed through communicationsare called “attributes“ or parameters. Each function block has a user-definedname, called a block
33、tag, which must be unique. Function block data is addressedover field bus via TAG.PARAMETER.The User Layer Standard defines a “function block“ to be a process- relateddata structure with a “data part“ and a “rule part“, as described in thefollowing illustration:Function Block TypeA class of user ele
34、ments consisting of(1) The definition of a data structure partitioned intoinput, output, and internal variables, (data part,also called “data base“) AND(2) A set of operations to be performed upon the variablesof the data structure when the element is invoked (rulepart, also called “algorithm“).Func
35、tion BlockAn identifiable and distinct instance of a function block type.There are four classes of function blocks as follows:o Standard - the attributes and the algorithm are fully definedwithin the standard such that both the dynamic andstatic performance are known. Both the algorithm anddata base
36、 may be extended as long as the standardfunction remains.o Alternative - the attributes include those of a standard block, butthe algorithm may not provide the same static or dynamicperformance as the corresponding standard block.o Generic - the attributes are defined only in generic terms such9SP-5
37、0 User Layer Technical Report Prefacethat any system may access them through the use of theseattributes. The algorithm is not defined by thestandardo Open - the attributes and the algorithm are not defined withinthe standard.The intent of the function block structure is to allow devices to bedeliver
38、ed with pre-defined algorithms requiring only the data base to bedownloaded for configuration into a specific control application. These are theStandard and Alternative blocks. A vendor may also deliver a Generic or a uniqueOpen block complete with the algorithms pre-defined. In contrast, a vendor m
39、ayalso provide a start-up procedure, outside of the User Layer, to downloadalgorithms to any type of function block, although this model is intended for useonly with Generic and Open blocks.Standard function blocks, which have been included, also provideinterchangeability for the functions they defi
40、ne. The standard function blockdefinitions allow extensions (i.e., functionality and parameters beyond thosedefined in the standard) and alternate function blocks (which use a differentalgorithm but the same parameters as a standard block). Extensions and alternateblocks, of course, may not be inter
41、changeable. Generic and open function blocksaccommodate both vendor-proprietary functionality and new field-device functionswhich are not practical to implement using combinations of standard functionblocks. These classes of function blocks are not intended to be interchangeable.However, extensions
42、and function blocks of any class which follow the user layerrequirements for standard blocks, will be interoperable via field bus. The userlayer also includes features of extended tag addressing and auto-formatting,which facilitate interoperability of extensions and “non-standard“ blocks.The followi
43、ng diagram shows the equivalency between “function blocks andconventional process and instrumentation diagrams (P Hedw - LO4 Fail - Failure in Path to Proc.5 No-Path - No Path to Proc.6 ATW-h - Wound-up-High7 ATW-l - Wound-up-Low0123456718SP-50 User Layer Technical Report Data Owner Structure - Logi
44、cal NodesEnvironmentFigure 9: Block AlgorithmsBLOCK ALGORITHMS:Analog BlocksAnalog InputAnalog OutputCounterDynamic CompensationMathOn/Off ControlPIDProperty ConversionPulse Width ModulatedSignal CaptureSignal CharacterizerSignal SelectorSplitterTimerTotalizerTunerMemory I/F:Scalar (4)Register I/FDiscrete Blocks:Device ControlDiscrete InputDiscrete OutputDiscrete Reg. I/OHuman InterfaceLogicProgram ControlSpecial Blocks:Batch CollectorCompositionTank GaugingSerialSerial CommunicationsSerial In Conversion
