1、Fieldbus Standard for Use inIndustrial Control Systems,Parts 3 ISA; 67 Alexander Drive; 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 of the growing need for attention to th
2、e metricsystem of units in general, and the International System of Units (SI) in particular, in the preparation ofinstrumentation standards. The Department is further aware of the benefits to USA users of ISAstandards of incorporating suitable references to the SI (and the metric system) in their b
3、usiness andprofessional dealings with other countries. Toward this end, this Department will endeavor to introduceSI-acceptable metric units in all new and revised standards, recommended practices, and technicalreports to the greatest extent possible. Standard for Use of the International System of
4、Units (SI): TheModern Metric System, published by the American Society for Testing it led to real problems (and iteased many imagined ones) in mutual understanding.1.2 Features varietyDue to the differences between the existing fieldbus approaches, the technical and diplomatic need ofmerging them ha
5、s always been the key issue of all the ISA DLL efforts and has so increased the varietyof features and the complexity of the structure within such a document that tries to harmonize them all.1.3 Many updatesThen, the long path followed in order to chisel a proposal that could be really agreed by all
6、 the differentexisting approaches has caused the need to frequently update, partially re-write, or delete, or add manyparts of the ISA Fieldbus DLL drafts along several years.And this, of course, did not give the documents the same clear structure as an immediate paper wouldhave had.1.4 Effort to un
7、derstandFinally, we have to remind how only “if“ and “when“ we really want to implement something, then wemake the effort to understand it. When we already have an existing, even if not universal, alternative whyshould we make such an effort?2 Tutorial targetWell, as done in previous editions, this
8、tutorial aims to fill such need of explaining the “why“ and “how“relevant to “what“ has been included in the ISA Fieldbus DLL documents.Differently from the past, when the addressed audience was mainly made of the members themselves ofthe ISA committees (see last part of 1.1 above), this edition wou
9、ld also like to address the people who, sofar, have not had any contact with the ISA Fieldbus DLL documents. At the same time, we would like tosave all the detailed tutorial material prepared in the past. In the foreword below well see how this kind ofcompromise has been reached.This page intentiona
10、lly left blank. 11 ISATR50.02, Parts 3 that is also because Part B is a collection of alreadyexisting works done during the ISA committee activity. Still we decided to publish this tutorial even if PartB is incomplete, both for the reasons listed in its Introduction, which seem to urge its Part A an
11、d as aninvitation too for some other committee members to work on it in some future joint efforts.Whenever possible, all parts and subparts of the tutorial refer to the relevant ISA Fieldbus DLLdocuments clauses and subclauses to help in tracing each subject all along the standard documents.The foll
12、owing planning table, for each one of the above parts and relevant goals, relates the DLL mainfeatures, which are described in this tutorial, to the relevant clauses/subclauses of this document.NOTE By using such a table, the reader, only interested to an external viewpoint over this DLL, could go r
13、apidly through the“reasons why features exist,“ “examples/graphic representations“ and the “flavor“ of just those corner-stone features marked by “*“.As a general rule, we will use prefixes “A“ and “B“ to indicate a clause/subclause contained in the twoparts of this document while PIII and PIV will
14、refer to clauses/subclauses of, respectively, Part III (DLLServices) and Part IV (DLL Protocol) of the ISA Fieldbus Document (to be more precise, ofISA-S50.02, Part 3-1997 and ISA-S50.02, Part 4-1997).ISATR50.02, Parts 3 they were complementary, notalternative, and a complete fieldbus solution needs
15、 the two together.“How is this possible?Well try to show that need by using a silly (but suitable, we believe) analogy.A1.1.1 Cars vs. trains analogyWhen the first cars appeared at the end of the nineteenth century, after a short dismay it was easy toforesee the car itself as “the solution“ of any m
16、ans problem regarding short-medium range transportation.Of course people realized that some adaptations were needed by the existing roads (asphalt, signaling,widening), but at that time nobody thought a car transportation system would have ever collapsed.The problem was (and always is) that once the
17、 means to satisfy a need is provided then the needs sizeenlarges beyond any possible previous expectation.So it happened with cars. Soon they were used not just to satisfy the previously existing needs oftransportation, but they generated new requests by themselves. The fact they existed gave people
18、 newideas about what, when, where to transport! Now it was so easy, why not to use a car for it?!There the collapse originates from; no matter how many, large, modern facilities we build, peoplestransportation needs always rise (really pushed by the facilities themselves) to a point at which theysat
19、urate. Its just hopeless because its automatic; the freedom of access to such means brings itspotential demand out of any possible control. At the topic moment even the ambulance will have to followthe slow procession within the traffic jam.Thats why in the last years we have seen a strong recovery
20、of trains (or train-like means) on short-medium range transportation; they fulfill the need of commitment on a pre-established time-table(schedule).Do we need to be at work in the city center at eight oclock every morning, regardless of weather or trafficconditions? Do we need to reach Florence in t
21、wo hours from Rome, regardless of being on a summerholiday weekend?Lets plan a train journey then.But does this mean that we have to forget cars?Certainly not; trains are not the correct or best answer to many other not-scheduled transportation needs:would we like to wait for a train when we wish to
22、 pop over for visiting some friends, or to pay for a railwaythat could reach even our personally preferred pub?ISATR50.02, Parts 3 thefreedom of access to such a means brings its potential demand out of any possible control. At the topicmoment even the most urgent data may have to wait for the token
23、 to come back to it, and if theconnected equipments are not a few, if each one has something to transfer, if . . . , then the worst case ofthe response to such an urgent need cannot be kept as small as we would like.Thats where a scheduled access can instead fulfill the commitment. Do we need to upd
24、ate informationevery 10 msec, regardless of traffic conditions? Do we need to know about an event within 20 msec of ithappening, regardless of how much equipment is connected and of how much they have to transfer?Lets plan a scheduled access then.But does this mean that we have to forget tokenized a
25、ccess?Certainly not; scheduled access is not the correct or best answer to many other data transfer needs.Would we like to wait for a pre-scheduled access when we already have data to transfer and nobody elseis using the network, or to pay bandwidth for a periodic scheduled access when we have noncr
26、iticaland/or episodic data to be transferred just once?So, even if it doesnt seem to have been obvious, we need a good mix of circulated token and scheduledaccess, so well balanced as to not have to pay bandwidth for the scheduled access when it isnt reallyneeded, but always giving priority to sched
27、uled access over circulated token when a conflict arises.A1.1.3 ISA philosophyThats what the ISA Fieldbus DLL documents propose: an overall schedule able to guarantee the neededdata at the needed time but also allowing gaps within which a circulated token mechanism can take placewhile complying with
28、 a defined maximum rotation time.Going back to the previous analogy, ISA Fieldbus DLL documents propose a combined system of roadsand railways where, at each level-crossing, cars stop to let trains cope with their time table, but where it isalso possible to define the limit of the number of trains i
29、n order to guarantee a maximum waiting length forthe cars at the barrier. 15 ISATR50.02, Parts 3 its implementation cannot avoid nominating a kind of democratic “king“ who univocallyimposes the transmission of a defined data at a defined time by a defined people, when so required, butalso guarantees
30、 a defined minimum amount of free time to each one of its people for their chats. In fact on one side, a fair method to guarantee a pre-established transfer of a defined data at a defined timeis to have one and only one “decision maker,“ which compels all the others transmissions preventingthem from
31、 arguing about whos going to do what (see figure A1); and on the other side, a fair method to give everyone equal possibility to freely access the fieldbus is to leta token pass among all the nodes in a circular repetitive way: each node receives such token fromthe “preceding“ node, uses it for its
32、needs up to a limited amount of time and then passes the tokenitself to the “successive“ node (see figure A2).NOTE We take the liberty of using “node“ instead of the more appropriate and precise “Data Link Entity“ (DLE) because we thinkit helps a quicker (even if not so precise) understanding.So, ha
33、ving to keep an “arbitrator“ for the scheduled traffic, but wishing to freely circulate a token too, theonly way is to (see figure A3) circulate the token only when no scheduled traffic is needed; make the token return to the arbitrator instead of passing it onto a new node so that the arbitrator,de
34、pending on the time left, can decide whether to actually pass the token once more or to resume linkcontrol to manage the scheduled traffic; and pass the token for a limited amount of time that is always shorter than the interval left before the nextscheduled traffic.Such an arbitral node takes the n
35、ame of Link Active Scheduler (LAS, see A1.2.1) within the ISAFieldbus DLL documents. That is,“Link“ becausethe ISA fieldbus network can be made of several segments (links) interconnected by bridges (see clauseA9 for the reasoning behind much of the multilinks structure). Each link has its own Active
36、 Scheduler thatmanages the relevant traffic independently from that of the other links; a node (bridge), whichinterconnects different links, stores the messages, addressed to links that can be reached along thenetwork through it, and forwards them only when an opportunity is given on the addressed (
37、orintermediate) links. This does not preclude having scheduled traffic over a multilink structure, but, in thiscase, a schedule builder must coordinate the single schedules of the different LAS of all the links. Suchschedule builder could also run off-line and then download, through Fieldbus Managem
38、ent Services, theseveral pre-established schedules to each LAS.ISATR50.02, Parts 3 in fact, any one of the nodes belonging to the so called Link Master (LM) class can beelected as LAS (see A1.2.1.1) at the power up of the link, or when the current LAS fails, or when somenew nodes are added to the li
39、nk itself.That is the main difference between LM class and the other “Basic“ class, the possibility to become LAS.In the ISA Fieldbus DLL documents, belonging to the Basic Class does not mean not being able toreceive and hold the token, nor does it mean necessarily being a “slave“ of some “master“ t
40、o which wehave to reply; a Basic Class node just cannot become LAS, but it can instead make full and free use ofthe token for the duration the token itself is given to it (PIV-5.6).Of course, the possibility to have more than one potential LAS on each link is essential for fieldbus availability reas
41、ons, see A1.2.1.1 and A13 for details on the LAS back-up procedures. It is also possible that the several potential LAS have different levels of capability in managing and/orupdating their schedule (see A1.2.1.4). This could be used, for instance, to provide the essential part ofthe fieldbus traffic
42、 in front of failures (soft degradation).“Scheduler“ becausethe real activity of such an “arbitrator“ is to strictly follow a defined schedule in order to decide (seeA1.2.1.2) whether at that given time a scheduled action has to be triggered or whether there is a longenough gap, before the next sche
43、duled action, so that a token can be given to another node (for aconsequent maximum duration) or some link management activities (see A1.2.1.3) can be performed.With relevance to all these scheduling and tokens managed by the LAS, specific items such as DLL services (DLL actions aimed to satisfy the
44、 DL-user), which can or cannot be compelled; scheduled and free data traffic; sequences; and token types and policy.will be highlighted and described in the following subclauses.First, as anticipated in the foreword, after going through these descriptions, readers looking for furtherrefinements may
45、find a graphic representation of the relationship among these items and between themand the DLL frames useful (Data Link Protocol Data Units DLPDUs, see A5). Such graphicrepresentation is found in B2, together with the relevant queues and buffers resources (see A2).In any case we have to notice how,
46、 for the LAS to be able to precisely drive all the scheduled traffic, for the LAS and any other node to correctly handle the duration of the token use, to let any node ask the LAS for a defined action to be scheduled,a precise enough sense of time and a relevant fine synchronization mechanism among
47、all nodes areneeded and hence provided by the ISA Fieldbus DLL documents. 21 ISATR50.02, Parts 3 a fine DLL clock frequency alignment is needed by the LAS and by each node that receives the tokenin order that they can both measure the duration of the token use at the same rate; and a DLL time synchr
48、onization among all the nodes is needed so that any node can request the LAS fora scheduled action to be executed at a defined “time“ that represents the same absolute instant. Clause A6 describes each mechanism of time distribution and synchronization. Here we would only liketo highlight how all DL
49、L recovery timers (a kind of time-out), to simplify implementations, are based on thesame measurement unit called “slot-time“ (PIV-3.3.25).For each link, such slot-time is the measure (or safe estimation), maximized across all pairs of nodes onthat link, of the worst asynchronism within a node between the perceptions of a defined basic DLL eventand of its potential consequence generated by the other node (see B3 for details).The slot-time is then used as common measurement unit (or granularity) of the DLL recovery timers overall the nodes
