You are on page 1of 46

Foundation Fieldbus y su adaptaci on a la alta velocidad: HSE

Jose Juan Fern andez de Dios Curso 2004-2005

Resumen Este documento fue escrito como trabajo de investigaci on para la asignatura Instrumentaci on de la ETSI de Telecomunicaciones de Vigo. Los buses de campo, como Probus, DeviceNet, o Foundation Fieldbus. son aplicables en una gran cantidad de escenarios muy diferentes entre s . Pese a que en general las medidas de un n umero reducido de sensores (o los comandos enviados a cada actuador) necesitan muy poco ancho de banda, al introducir sistemas de adquisici on de alta velocidad o al integrar un n umero elevado de sistemas las necesidades de ancho de banda se multiplican. Por ese motivo se han elaborado variantes de alta velocidad para casi todos los buses de campo. Uno de los m as interesantes es el Foundation Fieldbus, ya que a pesar de plantear una serie de conceptos muy interesantes es casi un desconocido en Europa. En este documento se va a analizar brevemente el contexto hist orico y tecnol ogico en el que se encuentra FF, para describirlo despu es centr andose especialmente en la variante de alta velocidad: High Speed Ethernet.

Indice general
1. Rese na hist orica 2. Fieldbus Foundation y Foundation Fieldbus 2.1. Quien es Fieldbus Foundation? . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Qu e es Foundation Fieldbus? . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Descripci on de Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . . . 4 7 7 8 9

2.4. Est andares denidos por FF . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. H1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2. H2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.3. HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Contexto de buses 15

3.1. Algunos buses de inter es . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1. Schneider Electric: Modbus . . . . . . . . . . . . . . . . . . . . . . 17 3.1.2. Rockwell: EtherNet/IP . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.3. Siemens: Pronet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.4. Fieldbus Foundation: HSE . . . . . . . . . . . . . . . . . . . . . . . 18 4. Breve descripci on de otros est andares relacionados 19

4.1. Capas OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.1. CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Protocolo MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. TCP/IP y UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5. Introducci on a Foundation Fieldbus HSE

25

5.1. Por qu e Ethernet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. H1+HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. Tipos de dispositivos HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Benecios de HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4.1. Alto rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4.2. Interoperabilidad de subsistemas . . . . . . . . . . . . . . . . . . . 27 5.4.3. Bloques funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.4. Red troncal de control . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.5. Ethernet est andar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Descripci on de los protocolos de H1 y HSE 29

6.1. H1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.1. Capa f sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.2. Pila de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2. Especicaciones comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.1. Fieldbus Access Sublayer (FAS) . . . . . . . . . . . . . . . . . . . . 33 6.2.2. Fieldbus Message Specication (FMS) . . . . . . . . . . . . . . . . 34 6.3. HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.1. Especicaciones de HSE . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Limitaciones 39

7.1. Limitaciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Robustez f sica y cableado . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.3. Falta de determinismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.4. Redundancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.5. I.S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Bibliograf a 44

Cap tulo 1 Rese na hist orica


Hablando de la historia de los buses de campo, podr amos remontarnos quiz a a los a nos 40, cuando para la instrumentaci on de procesos empez o a emplear se nales de presi on neum atica de entre 3 y 15psi para la monitorizaci on y control de dispositivos. A pesar de la existencia de este est andar, a menudo era necesario emplear varios niveles de se nal para adaptarse a los numerosos instrumentos que no estaban dise nados para seguir esas especicaciones [COU95]. La situaci on fue evolucionando progresivamente, hasta que el desarrollo de los procesadores digitales en los a nos 70 introdujo el uso de computadores para monitorizar y controlar los sistemas de instrumentaci on desde un punto central. La naturaleza espec ca de las tareas a controlar exigi o que se dise nasen un gran n umero de instrumentos y m etodos o en producirse un de control a medida para las diferentes aplicaciones [COU95]. Poco tard aut entico boom, cuando comenz o a utilizarse el sistema de 4 a 20mA que comenzar a una aut entica estandarizaci on sobre la interconexi on de los dispositivos de campo, y que m as tarde acabar a siendo reemplazado por los buses de campo. Estos u ltimos presentaban varias ventajas que propiciaron su gran despliegue: gracias a comunicarse digitalmente permiten una comunicaci on bidireccional y redundante, evitan los problemas inherentes a una transmisi on anal ogica (distorsi on, ruido, etc.), y sobre todo, permiten conectar varios dispositivos a un mismo cable reduciendo as los costes de instalaci on y mantenimiento. Los primeros buses de campo empezaron a verse ya desde los primeros a nos de la d ecada, pero habr a que esperar hasta mediados los a nos 80 para que empezase el aut entico asica detr as del est andar es que establece trabajo de estandarizaci on [FEL02]. La idea b una especicaci on formal que por una parte impide los cambios r apidos, dando una cierta estabilidad al usuario e incluso a los fabricantes, y por otra parte permite que varios proveedores fabriquen productos interconectables, lo que proporciona al usuario una mayor libertad y variedad a la hora de elegir productos. Sin embargo, es otra caracter stica de los est andares la que origin o una aut entica guerra de buses que comenz o a partir de estos a nos: en muchos pa ses los est andares tienen valor legal, de forma que si el gobierno acepta un est andar en una aplicaci on, es obligatorio utilizarlo. As un sistema estandarizado consigue una ventaja competitiva sobre los rivales no estandarizados [FEL02]. 4

Conseguir que unas especicaciones fuesen aprobadas a nivel nacional no era demasiado complicado ya que hay mucha menos competencia dentro de un u nico pa s, y la mayor a de los buses de campo m as relevantes pronto se convirtieron en est andares nacionales. Los problemas empezaron cuando se empezaron a buscar soluciones internacionales. En la segunda mitad de los 80, el esfuerzo de desarrollar buses de campo lo realizaba principalmente Europa, movida por proyectos de investigaci on que a un ten an un contexto muy acad emico, as como por muchos desarrollos propietarios. Los dos resultados m as prometedores fueron FIP por la parte francesa y Probus por parte de Alemania. Ambas fueron estandarizadas a sus respectivos niveles nacionales y nalmente propuestas a la IEC para su estandarizaci on internacional. Desafortunadamente las losof as de los dos sistemas eran completamente diferente. Probus estaba basada en una idea de control distribuido y en su forma original soportaba una comunicaci on vertical orientada a objetos, de acuerdo con un modelo cliente servidor similar al de MAP/MMS. FIP, por su parte estaba dise nado con un control centralizado pero capaz de implementar esquemas de control estrictamente de tiempo real, empleando una comunicaci on horizontal seg un el modelo productor-consumidor o publicador-suscriptor. Siendo tan diferentes, los dos sistemas eran apropiados para areas de aplicaci on complementarias. Evidentemente, un bus universal necesitaba combinar los benecios de ambos. En 1992 surgieron dos grupos, cada uno compuesto por muchas compa n as del sector de alrededor del mundo, para ofrecer una soluci on al mercado de los buses de campo. La ISP (Interoperable Systems Project ) y WorldFIP (fundaci on creada alrededor de FIP), que pese a que ten an distintos puntos de vista de la implementaci on de los buses de campo ofrecieron modicar sus productos para dar cabida a las prestaciones del otro [COU95]. En una extensi on de FIP (WorldFIP), se le a nadi o la funcionalidad del modelo clienteservidor. Por su parte, la ISP intent o demostrar que se pod a mejorar Probus con el on era crear un bus internacional para modelo publicador-suscriptor [FEL02]; su intenci uso en entornos peligrosos. Para los a nos 90 WorldFIP y Probus PA se segu an peleando en sus respectivos terrenos, y la IEC a un no hab a conseguido ning un avance signicativo. La u nica excepci on fue la denici on de la capa f sica, que se adopt o como el est andar IEC 61158-2 ya en 1993, y que fue muy utilizada desde entonces sobre todo en el area de la automatizaci on. Sobre la capa f sica, sin embargo, los borradores se volvieron m as y m as comprehensivos, intentando dar cabida a todos los sistemas [FEL02]. As que en Septiembre de 1994, tras varios a nos de luchas, WorldFIP y la ISP se unieron para convertirse en la Fieldbus Foundation. El objetivo de la Fieldbus Foundation era crear un u nico bus de campo internacional para entornos peligrosos. Probus PA (la organizaci on de usuarios de Probus) sigui o persiguiendo el mismo objetivo por su cuenta. Mientras Probus PA tiene sus ra ces y su mayor comunidad de usuarios en Europa, los fabricantes y usuarios de Foundation Fieldbus est an concentrados en Am erica y Asia [SAM00]. La FF utilz o algunos elementos de FIP para la especicaci on de su bus de campo,

impossible to start from scratch and create a unified which was adopted as IEC 61158-2 standard but new standard which was incompatible to the already in 1993. This part is the one that has since existing national ones. Within CENELEC, the been used very successfully mainly in the process national committees found after lengthy discussions automation area. On top of the physical layer, a remarkable and unprecedented compromise: All however, the standardization drafts became more national standards under consideration were simply and more comprehensive and overloaded with all compiled as is to European standards [9]. Every kinds of communication and control principles part of such a multi-part standard is a copy of the imported from the different systems. In the Data respective national standard, which means that Link Layer specification, for example, three every part is a fully functioning system. different types of tokens were introduced: The as como token (al igual que Probus PA) detalles de la To especicaci n de ISP. Por este motivo scheduler determines which station make the oCENELEC collection easier to el controls the timing on bus the bus, with id the delegated dise no f sico del es casi entico en ambos handle, buses the de various campo. La interfaz aplicaci on, fieldbus systemsde were bundled token another station can temporarily gain control according to their primary application areas. EN basada en bloques funcionales, tambi en tiene muchas caracter sticas similares [SAM00]. over the bus, and the circulated token is being 50170 contains General purpose field passedA from station to station bus access. Theest estas alturas, pesefor a la falta de un andar internacional, los diferentes buses de camcommunication systems, EN 50254 High problem these all-inclusive was that communication subsystems for small po yawith se hab an hecho unapproach hueco en el mercado.efficiency Debido a ello, la CENELEC tom o una dea full implementation of the standard was too data packages, and EN 50325 comprises different cisi on salom onica queimplementation ser a repetida posteriormente por otras agencias de estandarizaci on: expensive, whereas a partial would solution based on the CAN technology. In the later aceptar todos los buses de campo. De ah surgieron los est a ndares EN 50170, EN 50254 have resulted in incompatible and not interoperable phases of the European standardization process, the devices. y EN 50325 en 1996, 1998 y 2000. British national committee played the part of an CENELEC standards part EN 50170-1 (Jul. 1996) EN 50170-2 (Jul. 1996) EN 50170-3 (Jul. 1996) EN 50170-A1 (Apr. 2000) EN 50170-A2 (Apr. 2000) EN 50170-A3 (Aug. 2000) EN 50254-2 (Oct. 1998) EN 50254-3 (Oct. 1998) EN 50254-4 (Oct. 1998) EN 50325-2 (Jan. 2000) EN 50325-3 (Apr. 2000) EN 50325-4 (under vote) EN 50295-2 (Dec. 1998) Contained in IEC standard IS 61158 Type 4 IS 61158 Type 1/3/10 IS 61158 Type 1/7 IS 61158 Type 1/9 IS 61158 Type 1/3 IS 61158 Type 2 IS 61158 Type 8 (IS 61158 Type 3) (IS 61158 Type 7) IS 62026-3 (2000) IS 62026-5 (2000) IS 62026-2 (2000) Brand name P-Net PROFIBUS WorldFIP Foundation Fieldbus PROFIBUS-PA ControlNet INTERBUS PROFIBUS-DP (Monomaster) WorldFIP (FIPIO) DeviceNet SDS CANOpen AS-Interface

En 1999 el IEC realiza una tarea similar: Technical crea un Board est andar en el que incorporaba ratification by the CENELEC todos los buses, pero con la diferencia de que los divid a en partes: la capa f sica, capa de advocate of the American companies and submitted 3 aplicaci The international fieldbus war on, etc. [FEL02] also FF, DeviceNet, and ControlNet for inclusion in

Tab. 2: Contents of the CENELEC fieldbus standards. The dates given in brackets are the dates of

In 1995, after long years of struggles between the un European standards. a compilation Por parte, la FF, hab a decidido bus pr actico Tab. sin 2 lashows exigencia de dar German andsu French experts to combine the FIP and realizar of all these standards, as well as their relation to the cabida aapproaches, todos los several sistemas previos, para conseguir resultados m as r apidamente. InicialPROFIBUS mainly American new IEC standard. For the sake of completeness, it companies decided to noel longer watchen thedos endless mente dividieron trabajo secciones:should H1 que ser a un bus de campo de baja be noted that a comparable, though much discussions. With the end of the ISP project, they less disputed standardization processpor took place velocidad, y H2, que ser a su equivalente de alta velocidad. En 1998 surge primera began the definition of a new fieldbus optimized for also for bus systems used para in machine construction vez la posibilidad de combinar Ethernet con Foundation Fieldbus crear una red de the process industry: the Foundation Fieldbus (FF).

control de alta velocidad, y se menciona por primera vez HSE (High Speed Ethernet ). El proceso de desarrollo tambi en fue muy r apido, y en Marzo de 2000 se publicaron las especicaciones nales [ARC01].

Bibliograf a de este cap tulo: [FEL02] [SAM00] [ARC01] [COU95] 6

Cap tulo 2 Fieldbus Foundation y Foundation Fieldbus


2.1. Quien es Fieldbus Foundation?

La Fieldbus Foundation fue creada como una organizaci on independiente y sin animo de lucro para desarrollar un u nico bus de campo internacional, abierto e interoperable. [FF96]. La organizaci on se basa en los siguientes principios: La tecnolog a de FF ha de ser abierta y cualquier compa n a ha de poder disponer de ella. La tecnolog a de FF ha de estar basada en el trabajo del IEC (International Electrotechnical Commission ) y de ISA (International Standarization Association ). Los miembros de la Fieldbus Foundation apoyan a los comit es de estandarizaci on nacionales e internacionales y trabajan con ellos. Ya en 1996, la FF contaba con 185 compa n as asociadas de entre las m as importantes a nivel global (representaban el 90 % de la fabricaci on mundial de productos de instrumentaci on y control). Uno de los principales m etodos de organizaci on y decisi on son los consejos de usuarios nales, que repartidos por todo el mundo, revisan las actividades de la fundaci on y se aseguran de que las especicaciones cumplan las necesidades del mercado.

access make it the leading candidate for plant-wide integration in the process industries. In the year 2001, ARC expects most PAS suppliers to offer Foundation Fieldbus HSE as their control level network, bridging directly across multiple Foundation Fieldbus H1 bus segments. ARC also expects to see some direct HSE connections to a few high performance sensors and actuators. HSE, the high-speed Ethernet-based con$%%
0DJPHWHUV 3UHVVXUH7UDQVPLWWHU 9RUWH[6ZLUO0HWHUV 0DVV)ORZPHWHU

,QYHQV\V
3UHVVXUH7UDQVPLWWHU 7HPSHUDWXUH7UDQVPLWWHU 9RUWH[)ORZPHWHU

trol network for Foundation Fieldbus, was the missing piece in the total Foundation fieldbus puzzle. The conception and eventual release of HSE specifications was actually a very quick process. The original idea for using Ethernet in conjunction with Foundation Fieldbus to create a high-speed control network was born in 1998. Final specifications for HSE FF were released in March of 2000, after months of intensive testing and validation.

(PHUVRQ3URFHVV6ROXWLRQV
'LJLWDO9DOYH&RQWUROOHU )OR9XH)LQDO&RQWURO6\VWHP 3UHVVXUH7UDQVPLWWHU 7HPSHUDWXUH7UDQVPLWWHU 9DOYH3RVLWLRQHU 9RUWH[)ORZPHWHU 0DJPHWHUV $QDO\WLFDO(TXLSPHQW &RULROLV)ORZPHWHU

+RQH\ZHOO
3UHVVXUH7UDQVPLWWHU 7HPSHUDWXUH7UDQVPLWWHU

<RNRJDZD
$QDO\WLFDO(TXLSPHQW 9DOYH3RVLWLRQHU 7HPSHUDWXUH7UDQVPLWWHU 9RUWH[)ORZPHWHU 3UHVVXUH7UDQVPLWWHU

0DMRU 6XSSOLHUV DQG WKHLU )RXQGDWLRQ )LHOGEXV &RPSDWLEOH 3URGXFWV

In December of 2000, the FF released a testkit for HSE linking devices (HTK).

2.2.

Qu e es Foundation Fieldbus?ing

With the introduction of the test kit, the FF expects to be registering HSE soon. Many FF members have already developed El Foundation Fieldbus 1 linking es unadevices arquitectura abierta para la integraci on total de la alpha linking devices along with the release of the HTK. These companies will use the informaci on. to test these devices as part of an alpha/beta validation program. Some Se trata de un sistema deHTK comunicaciones completamente digital, serie y bidireccional. suppliers are already Actualmente est an denidas dos versiones [FF96]:offering HSE as part of new control system order specifications.

H1 (31.25Kbps) interconecta equipamiento de campo, como sensores, actuadores y I/O. En el mercado ocupa un nicho similar al de Probus PA: mientras que PA est a mucho 1R 6KRUWDJH RI 3URGXFWV $YDLODEOH %XW &HUWLILHG )) +RVW m as extendido en Europa, H1 tiene su origen y su area de mayor distribuci on en 6RIWZDUH ,V 6FDUFH Am erica y Asia.
Most of the major process automation suppliers offer at least a couple of to-

HSE (100Mbps/1Gbps) provee integraci on that de controladores de alta velocidad ken FF products have been certified and tested by(como the Foundation. PLCs), redes H1, servidores de datos, y estaciones de trabajo. Other suppliers, such as Fisher-Rosemount, Yokogawa, Smar, and EnEst a dise nado para aplicaciones cr ticas, donde la transferencia correcta de los datos es esencial. Adem as, al ser abierto, no es propiedad de ninguna compa n a ni est a controlado por el cuerpo regulador de ninguna naci on, si no que depende directamente de las $5&ZHEFRP&RS\ULJKW$5&$GYLVRU\*URXS decisiones tomadas por sus propios usuarios a trav es de los End User Councils, repartidos alrededor del mundo.
1 S , juegan con el juego de palabras entre la fundaci on de los buses de campo y el bus de campo de la fundaci on.

dress+Hauser, offer complete suites of process instrumentation that are FF-

Upon detection of abnormal conditions or the need for preventive maintenance, plant operations and maintenance personnel can be notified. This allows corrective action to be initiated quickly and safely (Figure 5).

Distribution of control into the fie reduce the amount of I/O and con needed, including card files, cabin supplies.

Control System Network Controller Input/Output Subsystem Linking Device

HSE
Controller PID

Control System Network

Linki Devi

Input/Output AO Subsystem AI

H1

4-20 mA

Traditional 4-20 mA One Variable One Direction

Fieldbus Multiple Variables Both Directions

Traditional Control and I/O requires extra equipmnet


Figure 6

Figure 4

Resumen de caracter sticas de Foundation Fieldbus : Apropiado para su uso en zonas de seguridad intr nseca (IS) Dispositivos deNetwork campo alimentados a trav es del bus HSE
Controller Topolog a en bus o en arbol Remote Input/Output Linking Device Controller Input/Output Subsystem I.S. H1
4-20 mA

Control System

Control System Network

Linkin Devic I.S.

Subsystem Permite comunicaci on multi-master

I.S.

I.S.

Comportamiento determinista Transmisi on de datos distribuida

Traditional 4-20 mA Fieldbus Modelo de at bloques estandarizado para una interfaz uniforme View Stops I/O Subsystem View Extends into Instrument

Opciones de extensi on exibles on de Figure 5 basadas en la descripci

One I Traditional 4-20 mA Wiring a los dispositivos One I.S. Barrier, One Wire for los dispositivos Each Device Figure 7

La transmisi on de datos distribuida se reere a que los sensores y actuadores no s olo act uan como tales, si no que pueden realizar funciones adicionales de comunicaci o n o 2 control. 1996 (Rev.1998, 2003) Fieldbus Foundation, Austin, Texas. All rights reserv

2.3.

Descripci on de Foundation Fieldbus

FF se diferencia de cualquier otro protocolo de comunicaciones, porque en vez de estar pensado simplemente como un medio de transmisi on de datos, est a dise nado para resolver aplicaciones de control de procesos. La caracter stica m as novedosa e interesante de FF , es que la estrategia de control se dene mediante bloques funcionales est andar -de una forma similar a como se programa en LabView o VEE - pero con la diferencia de que dichos bloques funcionales tienen una representaci on directa en el hardware del sistema: muchas de las funciones del sistema, como las entradas y salidas salidas anal ogicas (AI y AO ), o bloques PID 9

(Proporcional/Integrador/Derivador) pueden ser realizadas por el propio dispositivo de campo. De esa manera, la estrategia de control puede estar distribuida a trav es de los dispositivos de campo, gracias a que adem as de implementar bloques funcionales en sus microprocesadores, tambi en tienen la capacidad de comunicarse de forma directa con cualquier otro dispositivo a trav es del bus. La distribuci on del control en los dispositivos de campo puede reducir las necesidades de equipo de control y de entrada/salida. Adem as, aumenta la abilidad del sistema, ya que aunque los sistemas centrales sufran una aver a, mientras el bus est e alimentado el control puede continuar. En un sistema peque no, por ejemplo, puede llegar a ser prescindible un sistema de control central, realizando todas las tareas de c alculo y control los propios dispositivos [SMA01]. Se denen tres tipos de bloques [PIN01]: Bloques de recursos Cada dispositivo contiene un bloque de recursos (Resource Block ) que describe las caracter sticas de ese dispositivo, como el nombre, fabricante, o n umero de serie. Tambi en sirve para congurar par ametros que afectan al dispositivo en su conjunto. Bloques de transductor Permite congurar los sistemas de entrada/salida de cada dispositivo. Contienen informaci on como la calibraci on o el tipo de sensor. Bloques funcionales 2 Los bloques funcionales (Function Blocks ) son los que establecen la estrategia de control. Realizan todas las operaciones del sistema: los c alculos num ericos, todo el procesamiento de control necesario para el sistema, e incluso la acci on en s de adquirir un valor o accionar un actuador. Con los bloques congurados para realizar el proceso, es necesario congurar el bucle de control, creando enlaces entre los par ametros de entrada y salida de los bloques funcionales. Los enlaces pueden ser locales (si los bloques unidos est an en el mismo dispositivo) o remotos (si cada bloque est a en un dispositivo distinto). En caso de que el enlace sea remoto, toda la informaci on comunicada a trav es de ese enlace viajar a por el bus desde un dispositivo al otro. Ejemplos de bloques funcionales son [SAM00]: AI analog input AO analog output 3
No es raro que se hable de los bloques en general denomin andolos bloques funcionales. Aqu se describen los bloques funcionales sensu stricto. 3 Por entradas y salidas anal ogicas a menudo se entiende directamente un sensor o un actuador. As , una entrada anal ogica podr an ser tanto un sensor de temperatura como un conversor ADC, y una salida anal ogica podr a ser la posici on de una v alvula o la potencia entregada a un horno.
2

10

B bias CS control selector DI discrete input DO discrete output ML manual loader PD proportional/derivative PID proportional/integral/derivative RA ratio Tambi en se denen otros bloques funcionales, de los que el m as interesante de mencionar quiz a sea el FFB (Flexible Function Block ): se trata de un bloque denido por el usuario, con lo que permite a un fabricante o usuario implementar un algoritmo propio que interaccione con bloques funcionales est andar (por ejemplo un sistema de control Part 4 L454EN matricial). Por ejemplo, un sensor de temperatura simple podr a contener u nicamente un AI, mientras que una electrov alvula podr a contener un AO acompa nado de un bloque PID.
control valve with Link Master function

sensor

AO AI PID
OUT IN
BKCAL_IN

BKCAL_OUT

OUT

CAS_IN

Ya que FF es un protocolo abierto, cualquier fabricante puede ofrecer dispositivos Fig. 22: Connection of function blocks for cascade control (via software) compatibles que funcionar an perfectamente con los dispositivos de otros fabricantes. Para que el cliente nal pueda estar seguro de la interoperabilidad de un dispositivo, FF ofrece transmitted via the fieldbus. The configuration shown to the con- comprobar sus una serie de programas de certicaci on, para que corresponds los fabricantes puedan productos garantizar su calidad. trol loopy example illustrated in Fig. 2. Todas las funciones realizables en un sistema FF son conguradas y programadas control loop execution mediante los bloques funcionales, por lo que el dise no de todo el sistema es homog eneo
Besides connecting the function blocks, the network configurator also configagram, the configuration tool generates the information needed to control the devices and the communication. ures the individual loop execution rate. Based on this data and the wiring dirate

11
configuration of LAS and Link Masters

Finally, this data is entered into the individual field devices. During this process, the LAS is configured and all Link Masters receive the current transmission list for scheduled data transmission.

[PIN01]. Los bloques funcionales de FF tienen un dise no consistente, orientado a bloques, que permite la distribuci on de las funciones a trav es de dispositivos de m ultiples fabricantes de una forma perfectamente integrada [SMA01]. Todos los dispositivos FF comparten un sentido del tiempo com un. As , independientemente de los retardos por las interconexiones, la ejecuci on de cada bloque funcional se realiza de forma perfectamente sincronizada a la de los dem as. Para asegurarse de que las herramientas de dise no puedan ser gen ericas y para permitir su adaptaci on a los nuevos dispositivos seg un vayan saliendo al mercado, cada dispositivo se suministra con su descripci on completa en dos tipos de archivos [FF96]: Capability File El CF describe al sistema de control con qu e recursos cuenta el dispositivo, como el n umero de bloques funcionales y sus tipos, etc. Device Description File El DD describe las entradas, salidas y funciones de cada bloque funcional contenido en el dispositivo. Con esta informaci on, cualquier sistema de control o herramienta de dise no est andar puede congurar y comunicarse con un dispositivo.

2.4.
2.4.1.

Est andares denidos por FF


H1

El protocolo H1 est a basado en el est andar IEC 61158-2 [SAM00]: Se transere la informaci on utilizando codicaci on Manchester a una velocidad de 31.25Kbps. La tensi on m nima aceptable en el bus para que los dispositivos alimentados a trav es del mismo puedan funcionar correctamente es de 9V . La fuente de alimentaci on se conecta al bus en paralelo, igual que cualquier otro dispositivo. Por supuesto, para no interferir las se nales de datos enviadas, debe contener un ltro que bloquee la frecuencia de 31.25Kbps y sus arm onicos. No solo admite la cl asica topolog a lineal, si no que mediante cajas de uniones se pueden conseguir otras topolog as como arboles, estrellas o combinaciones. Se establece una longitud total para el cable sumando todos los segmentos, y se recomienda conectar los dispositivos al bus mediante segmentos cortos y conectores en T.

12

f the epa-

Figure 41 gives a summary of examples of options available in the Physical Layer standard.
No. of devices 25-32 19-24 15-18
Trunk*

1 device per spur 1m


Control Room 30 m Equipment

2 devices per spur 1m 1m Devices ***


25-32 30 19-24 15-18 13-14 60 1-12

3 devices per spur 1m 1 Spur Length**


1 metre 30 metres 60 metres 90 metres 120 metres

4 devices per spur 1m 1m 1m 1m 30 m

60 m 90 m
Junction Box

m m

1m 30 m 60 m

13-14 1-12

120 m
Spurs

90 m

Fig. 5: Length of spurs


Cable Length = Trunk Length + All Spur Lengths Maximum Length = 1900 metres with Type A Cable

4 Network
**

topologies used are usually line topology or, when equipped

s via T-connector

with junction boxes, also star, tree or a combination of topologies (Fig. 5). The metres devices areadditional best connected via short spurs using tee connectors to enfor each device on a spur. able*** connection/disconnection ofon the devices The number of devices possible the fieldbus without will vary interrupting commudepending on factors such as the power consumption of each nication. device, the type of cable used, use of repeaters, etc. Consult the 15 is limited to 120 meters and depends on the 4 The maximum length ofFigure aFigure spur 40 Physical Layer Standard for details. Single device per spur -- The spur length must be reduced by 30

* A terminator is installed at each end of the main trunk cable.

la calidad del cable. Sin repetidores y con el mejor cable contemplado4 , la longitud 4 Without the maximum length of an H1 segment can be as admite long m aximarepeaters, de un segmento H1 puede ser de hasta 1900m, y se un m aximo de 4 repetidores, con los que se pueden alcanzar 9500m de cable en un u nico segmento. as 1900 meters. By using up to four repeaters, a maximum of 5*1900 m = Characteristics Data Rate 9500 can be Theconectados short spurs from the se field deviceato the bus El n um mero de jumpered. dispositivos al bus reduce 32 en zonas IS. En zonas 31.25 kbit/s 31.25 kbit/s 31.25 kbit/s are included in this total length calculation. con riesgo de explosi on (Ex ) el n umero se reduce a s olo unos pocos dispositivos por Type linea debido a las Voltage Voltage on. limitaciones Voltage en la fuente de alimentaci Topology Bus/tree Bus/tree Bus/tree Bus Power none DC Type A Type B Type C DC Type D Classification Intrinsically Cable shielded single or Safe multi-twisted multi-core,
description twisted multi-twisted pair without without twisted

Se admiten varios tipos de as cable, dependiendo la longitud m axima number of spurs used as well the number of devices per spur (Fig. 6). del segmento de

Number of Devices* pair 2-32 pair with 2-6 an shield Cable Length 1900 m overall shield 1900 m Spur Length 120 m 120 m
Size 0.8 mm2 (AWG 18) 1900 m 0.32 mm2 (AWG 41 22) Figure 1200 m

0.13 mm2 (AWG 26) 400 m

2-12pairs, without shield 1900 m 120 m


1.25 mm2 (AWG 16) 200 m
SAMSON AG V74/ DKE

Max. length

incl. spurs * The number of devices possible on a fieldbus link depends on factors such as the power consumption of each device, the type of cable used, use of repeaters, etc. Consult the Physical Layer Standard The types number of network available for Fig. for 6: details. Fieldbus cable and maximum bus addresses lengths each link is 240. 2.4.2. H2

En las primeras fases del desarrollo del FF se consider o el desarrollo de una versi on ligada a un al campo pero de una velocidad intermedia entre H1 y HSE. Dicha versi on
4

Par trenzado apantallado, de una secci on AWG 18 (0,8mm2 ).

23

13

s Foundation, Austin, Texas. All rights reserved.

se denominar a H2, y tendr a una velocidad de entre 1Mbps y 2.5Mbps. Sin embargo, debido a la gran popularidad que consiguieron las soluciones basadas en Ethernet de cara a aplicaciones industriales, nalmente se opt o por desechar H2, siendo absorbida por HSE. A un pueden encontrarse referencias a H2 en una buena parte de la documentaci on disponible acerca de Foundation Fieldbus. Actualmente, H2 y HSE se consideran sin onimos.

2.4.3.

HSE

HSE est a basado en tecnolog a Ethernet; hay versiones de HSE a 100Mbps y a 1Gbps, y tanto por par trenzado como por bra optica. Los componentes necesarios son de uso com un y por tanto est an disponibles a un muy bajo coste, por lo que para la construcci on de la red en s , pueden utilizarse dispositivos comerciales (como hubs o switches de ocina). En una topolog a t pica, la red HSE interconectar a los diferentes segmentos H1 de una planta, posiblemente junto con uno o m as dispositivos de alta velocidad, e incluso otras redes de campo de terceros. La estructura l ogica de una red HSE est a pensada para ser combinada sin soluci on de continuidad con redes H1, y por tanto los protocolos involucrados y los m etodos de funcionamiento son muy similares en ambas. De hecho, varias de las capas OSI son id enticas en ambos sistemas.

Bibliograf a de este cap tulo: [SMA01] [PIN01] [FF96] [SAM00] [LUC01] 14

Cap tulo 3 Contexto de buses


Uno de los mayores problemas que podr an retrasar la implantaci on masiva de las redes Ethernet de alta velocidad en aplicaciones industriales y de instrumentaci on, es la falta de un est andar global y homog eneo. Desgraciadamente, no parece que las respectivas asociaciones hayan aprendido de la vez anterior, y cada cu al est a promocionando su propio est andar para las redes de alta velocidad, por lo que probablemente acabar a surgiendo una nueva guerra de buses similar a la ocurrida en lo referente a los buses de campo tradicionales. La mayor parte de estas redes est an basadas en Ethernet, pero dado que el est andar IEEE 802.3 s olo especica las capas m as bajas de la pila de protocolos, queda mucho que desarrollar y especicar a los distintos fabricantes, y en general para las capas altas cada uno emplea los mismos protocolos que en el bus de campo correspondiente [VER02]. La falta de compatibilidad parece asegurada. La velocidad y tasa de transferencia de la Ethernet supera c omodamente las de la mayor a de buses de campo tradicionales, como Probus, Foundation Fieldbus H1 o Controlnet. Probus tiene una tasa de transferencia m axima de 12Mbps; FF H1 trabaja a 31.25Kbps, y Controlnet a 5Mbps. Se acompa na un gr aco (extra do de [VER02]) donde se resume el posicionamiento de algunos est andares relacionados. A continuaci on se comentar an brevemente los m as importantes.

15

Figure 1 Fieldbus Protocol Application Regime

Instrumentation Control Bit-Level Sensor AS-i Seriplex Impacc CAN


SensorPlex

Corporate Information Discrete

Interbus-S PROFIBUS DP SDS DeviceNet PROFIBUS FMS ControlNet Modbus + / DH+ ECHELON PROFIBUS PA HART World FIP Process / Continuous LONworks Foundation Fieldbus HSE

Foundation Fieldbus H1

16

ATM / FDDI

3.1.
3.1.1.

Algunos buses de inter es


Schneider Electric: Modbus

Desde Schneider Electric abogan por una evoluci on del bus de campo de IDA (Interface for Distributed Automation ): Modbus. Schneider es el principal promotor de dicho est andar, si no quiz a el u nico fabricante [BRA03]. Una de las ventajas de la propuesta de Schneider es que se trata tambi en de un est andar abierto. Se utiliza Ethernet, IP, UDP, NDDS, y por supuesto Modbus y el modelo de datos de IDA. Pero tambi en tiene un gran problema: Modbus es un protocolo algo antiguo, que no estaba orientado a objetos. Esto se resuelve (al menos en parte) mediante el protocolo NDDS. NDDS, de la Real Time Innovations (RTI), tiene un funcionamiento basado en t ecnicas publicador/suscriptor, mucho m as evolucionadas que las de maestro/esclavo utilizadas en Modbus.

3.1.2.

Rockwell: EtherNet/IP

De una forma similar a Schneider, Rockwell eligi o el protocolo previo, que en este caso era CIP (Control and Information Protocol, renombrado recientemente a Common Industrial Protocol ) para ser adaptado y transmitido sobre Ethernet. CIP es un protocolo de la misma familia que las redes de campo previas ControlNet y DeviceNet. De hecho, donde se necesiten tiempos de respuesta inferiores a 2ms, Rockwell sigue recomendando el uso de ControlNet [BRA03]. Es interesante resaltar que el IP de Ethernet/IP no signica Internet Protocol si no Industrial Protocol. Su pila se compone, por tanto, de Ethernet, IP, UDP o TCP, y CIP.

3.1.3.

Siemens: Pronet

Probus (en sus distintas variantes) es probablemente el bus de campo con una mayor distribuci on alrededor de todo el mundo. Su actuaci on est a centrada especialmente en Europa, de donde es oriunda, pero cuenta con una base de dispositivos instalados total de m as de 2 millones de dispositivos. La estrategia de Siemens y Probus International hacia Ethernet est a recopilada en el proyecto Pronet, que se divide en tres versiones (V1, V2 y V3) seg un las restricciones temporales de la aplicaci on. Pronet V1 utiliza Ethernet de una forma transparente con Probus gracias a la tecnolog a DCOM (Distributed Component Object Model) de Microsoft, y el uso de pasarelas entre las dos redes. En la red V1, las comunicaciones en tiempo real no las realiza la Ethernet, si no una red Probus. Seg un los responsables, decidieron hacerlo as porque las 17

diferentes implementaciones de la pila TCP/IP introducen retardos muy superiores a los introducidos por Ethernet, llegando (seg un ellos) a 100ms en algunas implementaciones. Por ese motivo, en las versiones V2 y V3, hay un canal sustituyendo la pila TCP/IP a intervalos regulares a lo largo del tiempo. En la versi on R2, el canal de tiempo real, bautizado SRT (Soft Real Time ) se implementa de forma l ogica y alcanza tiempos de respuesta entre 5ms y 10ms sobre dispositivos Ethernet est andar. En la versi on V3, el canal de tiempo real, denominado IRT (Isochron Realtime Ethernet ), se realiza utilizando switches dotados de ASICs especializados. Seg un los responsables, mediante este sistema se permite sincronizar en menos de 1ms, y con un deslizamiento (skew ) inferior a un microsegundo [BRA03], pero con la gran desventaja de que el hardware ya no es Ethernet est andar.

3.1.4.

Fieldbus Foundation: HSE

La distribuci on del Foundation Fieldbus no es tan grande como la de Probus (que cuenta con una historia mucho mayor), pero ya en el 2001 (7 a nos despu es de la creaci on de la fundaci on) contaba con aproximadamente 1800 instalaciones [ARC01]. Igual que el resto, en la FF, decidieron basar la capa de aplicaci on de su High Speed Ethernet en la de su bus de campo previo, H1. As , volvemos a encontrar las principales caracter sticas de H1 en HSE: un modelo productor/consumidor, la implementaci on de una tecnolog a orientada a objetos (con el concepto de bloques funcionales para la medida, control, regulaci on, y diagn ostico), y la gesti on de redundancia. No est a claro si HSE se puede considerar realmente un bus de campo, ya que al igual que Pronet V1, sigue dependiendo de H1 para las tareas de campo, conect andose en 1 es de una red H1 y una pasarela [BRA03]. general los dispositivos a la red HSE a trav Acerca de los tiempos de respuesta, se habla de algunos milisegundos sin especicar m as. Sin embargo, hacen hincapi e en que m as importante que el tiempo de respuesta en s mismo es el hecho de que los distintos dispositivos act uan de forma perfectamente sincronizada.

Bibliograf a de este cap tulo: [ARC01] [VER02] [BRA03] [HUL02] [FEL02]


1

La cantidad de dispositivos de campo con puerto HSE es bastante reducida.

18

Cap tulo 4

Breve descripci on de otros Tying Ethernet & TCP/IP to the Foundation Fieldbus HSE Standard est andares relacionados
Review of the Fundamentals

2.

The OSI Model is briefly revisited here to ensure that Ethernet, TCP/IP and Foundation Fieldbus HSE are placed in the correct context. It should be realized at A continuaci n seReference hace un repaso a pido los principales protocolos relacionados con the outset that the o OSI Modelr is not de a protocol or set of rules for how a Foundation Fieldbus HSE. protocol should be written but rather an overall framework in which to define protocols. The OSI Model framework specifically and clearly defines the functions or services that have to be provided at each of the seven layers (or levels). The diagram below shows the seven layers of the OSI Model.

4.1.

Capas OSI

Fig 1. contexto Full Architecture of el OSI Model El modelo OSI dene un sobre que se puede describir un protocolo, especi-

A brief summary of the seven layers is as follows:

19

Application - the provision of network services to the users application programs. Note: the actual application programs do NOT reside here. Presentation primarily takes care of data representation (including encryption). Session - control of the communications (sessions) between the users.

cando c omo dividir y denominar las tareas que deben ser realizadas. Propone 7 capas: 1: Capa f sica compuesta por el medio de transmisi on y las normas el ectricas y mec anicas. 2: Capa de enlace responsable de ensamblar y enviar una trama de datos de un sistema hasta otro. 3: Capa de red encargada del enrutamiento de mensajes. 4: Capa de transporte realiza la gesti on de las comuncaciones entre dos sistemas. 5: Capa de sesi on controla las comunicaciones entre usuarios. 6: Capa de presentaci on se encarga de la representaci on de los datos (incluyendo la encriptaci on) 7: Capa de aplicaci on ofrece los servicios completos a los programas del usuario. Foundation Fieldbus dene una capa que no es descrita en el modelo OSI: la capa de usuario, que describe las estructuras de datos (como los bloques funcionales, por ejemplo) y el funcionamiento de los sistemas por encima de la capa de aplicaci on.

4.2.

Ethernet

Ethernet naci o en 1972 ideada por Roberto Metralfe y otros investigadores de Xerox, en Palo Alto, California Research Center. Ethernet - al que tambi en se le conoce como Ethernet II o IEEE 802.3, es el est andar m as popular para las LAN que se usa actualmente. El est andar 802.3 emplea una topolog a l ogica de bus y una topolog a f sica de estrella o de bus. Pese a que admite una topolog a en estrella o lineal, inicialmente el medio de transmisi on es compartido entre todos los dispositivos conectados a el (un bus). En una topolog a en estrella, en caso de emplear concentradores de tipo almacenamiento-retransmisi on, desde un punto de vista estricto cada segmento contendr au nicamente dos dispositivos, por lo que a pesar de que conceptualmente el medio sigue siendo compartido, en la pr actica se comportar a de una forma m as parecida a un enlace punto a punto. Para la transmisi on sobre el medio se emplea c odigo Manchester, lo que permite la recuperaci on de la se nal de reloj en recepci on sin necesidad de un par de hilos adicional. La estrategia de acceso al medio es CSMA/CD, es decir, no se utilizan testigos si no que cada estaci on decide de forma individual cu ando transmitir.

4.2.1.

CSMA/CD

CSMA/CD signica Carrier Sense Multiple Access with Carrier Detection. La traducci on del propio nombre nos explica que antes de empezar a transmitir, los dispositivos 20

The 802.3 standard defines a range of cable types that can be used for a network based on this standard. They include coaxial cable, twisted pair cable and fibre optic cable. The IEEE 802.3 standard defines the following: 10Base2 10Mbps with 185 m maximum length coaxial cable bus segment 10Base5 10MBps with 500 m maximum length coaxial cable bus segment 10BaseT 10MBps with 100 m twin cable to a central hub 10BaseF with twinsi fibre busalguien up to 2000 m escuchan10MBps para comprobar ya hay transmitiendo, y en caso de ser as , esperan and of course, the Fast Ethernet standards discussed later. a que acabe. En caso de que no haya nadie transmitiendo, lo hacen directamente, pero
comprobando si hubo una colisi on (es decir, que otra estaci on empez o a transmitir en el 4.3 mismo Medium Access Control (MAC) instante), y en ese caso se notica y se vuelve a intentar enviar el paquete m as tarde. Essentially the method used for accessing the cable (or medium) is one of En (or caso de colisi on, las dos (o m as)Carrier estaciones que Multiple intentaron transmitir deben darse contention CSMA/CD which stands for Sense Access /Collision cuenta de que la transmisi o n no tuvo e xito, para ello cuando una de esas estaciones detecta Detection) which is why most industrial users were initially cautious about the use of la colisi n,transfer en vez de dejarwas de transmitir inmediatamente, transmite una trama de una Ethernet as o all of data probabilistic and not guaranteed. cierta longitud para asegurarse de que todas las dem as estaciones tambi en detectan la In the idleostate, the node merely listens to the bus monitoring all traffic that passes. colisi n. If a node wishes to transmit information, it will defer while there is any activity on the Tras ello han de volver a transmitir esa trama, y para intentar evitar una nueva colisi on bus, since this is the carrier sense component of the architecture. At some stage, the esperar an antes de empezar un tiempo aleatorio. En el primer intento, dicho tiempo es the bus will become silent, and the node sensing this, will then commence its muy corto y var a entre 2 valores posibles. Si tras el se vuelve a colisionar, en el segundo transmission. It is now in transmit mode, and will both transmit and listen at the same elegir a aleatoriamente entre losthat dos another retardos node anteriores y otros dospoint m as, on mayores time.intento This isse because there is no guarantee at some other quehas estos. Si se vuelve a transmitting colisionar, se having elegir a recognised entre 8 valores, y se sigueof as hasta If que tras the bus not also started the absence traffic. 16 intentos de transmisi o n se deduce que la red no funciona correctamente y se descarta two nodes happen to transmit at the same time, there will be a collision of signals. el paquete. The nodes transceivers will both quickly detect this collision and will stop transmitting (after sending a brief jam signal son to ensure thatde allmejorar nodes stop Las esperas progresivamente mayores un intento la eciencia en caso de transmitting). Themanteniendo nodes will each a random before recommencing poco tr aco, unawait cierta robusteztime en caso de un tr aco elevado. Pese a ello, transmission. cuando hay varios usuarios intentando acceder a la red, la respuesta de CSMA/CD ante demandas de tr aco que se acerquen a la capacidad nominal del canal es muy inestable MAC(empieza Frame Format a haber problemas de eciencia entre el 60 % y el 80 %, y la red completa puede colapsarse a partir del 90 %). The basic frame for an 802.3 network is shown below. There are eight fields in each frame, as discussed below.

4.2.2.

Protocolo MAC

El protocolo de acceso al medio de Ethernet (MAC, Medium Access Control ) est a basaFig 3. MAC Frame Format. do en CSMA/CD, y transmite unas tramas con una estructura muy sencilla. Adem as de un pre ambulo que permite sincronizar los relojes, y de las dos direcciones Preamble f sicas del emisor y receptor, contiene los datos y un CRC al nal que permite detectar errores en recepci on. En caso de error, Ethernet no se encarga de retransmitir la trama This y field consists of 7 octets of the data pattern used simplemente la descarta. La retransmisi on1010101010, ser a tarea deThe los preamble protocolosisde las capas by the receiver to synchronise its clock to the transmitter. superiores, caso de ser necesaria. Debido a la velocidad de propagaci on de la se nal en el cable, si el paquete no tiene una longitud m nima podr a suceder que en caso de ocurrir una colisi on no todas las estaciones se enterasen de ella. Para evitarlo, si se intenta transmitir un paquete demasiado peque no 21

(menos de 64 octetos) es necesario aumentarlo rellenando con octetos sin informaci on al nal el mismo. Se denomina dominio de colisi on aquella longitud de cable en la que se garantiza la detecci on de las colisiones. Para un tama no del paquete dado en octetos, el dominio de colisi on ser a inversamente proporcional a la velocidad de transmisi on. As , si a 10Mbps el dominio de colisi on de Ethernet es de 2500m, a 100Mbps es de 250m. Si no se modicase el protocolo, a 1Gbps ser a tan solo de 25m, y por ese motivo en las normas a 1Gbps se 1 . Layer. aumenta el tama no de Layer relleno ( Pad ) de 64 octetos a 512 octetos The OSI Network maps onto the ARPA Internet

The OSI Physical and Data Link Layers map onto the ARPA Network Interface Layer.

4.3.

TCP/IP y UDP

OSI LAYER

PROTOCOL IMPLEMENTATION

ARPA LAYER

APPLICATION

File Transfere

Electronic Mail

Terminal Emulation

File Transfer

Client/Server

Network Management

PRESENTATION

File Transfer Protocol (FTP)

Simple Mail Transfer Protocol (SMTP)

TELNET Protocol

Sun Simple Network Trivial File Microsystems. Management Transfere Network file Protocol Protocol (TFTP) Systems (SNMP) Protocol (NFS) RFC's 1014, 1057 & 1094

PROCESS AND APPLICATION

SESSION

MIL-STD 1780 RFC 959

MIL-STD 1781 RFC 821

MIL-STD 1782 RFC854

RFC 783

RFC 1157

TRANSPORT

Transmission Control Protocol (TCP) User Datagram Protocol (UDP) MIL-STD 1778 RFC 793 768

RFC

HOST TO HOST

NETWORK

Address Resolution ARP RFC 826 & RARP RFC 903

Internet Protocol (IP) MIL STD 1777 & RFC 791

Internet Control Message Protocol (ICMP) RFC 792

INTERNET

DATA LINK

Network Interface Cards: Ethernet, Token-Ring, ARCNET, MAN and WAN. RFC 894, 1042, 1201 and others

NETWORK

PHYSICAL

Transmission Media: Twisted pair cable, Coaxial Cable, Fiber Optics, Wirless Media etc. etc.

INTERFACE

The relationship between the two models is depicted the following figure. Los protocolos de la pila TCP/IP son los protocolos abiertosin m a s populares del mundo
gracias al auge sufrido por Internet, porque permiten comunicarse a trav es de cualquier conjunto de redes interconectadas, y porque se adaptan tanto para comunicaciones LAN como WAN. 1 Fig 6.paquete OSI vs. ARPA Models Puede parecer que este tama no m nimo de har a la red extremadamente ineciente para un
sistema de control, que tiende a enviar un gran n umero de paquetes de peque no tama no. Sin embargo, existen mecanismos para paliar este efecto, como por ejemplo, el empaquetamiento de varias tramas MAC TCP/IP, or rather- the TCP/IP Protocol Suite- is not limited to the TCP en uno s olo de estos bloques de 512 octetos o m as (1536 como m aximo).

and IP protocols, but consist of a multitude of interrelated protocols that occupy the upper three layers of the ARPA model. TCP/IP does NOT include the bottom Network Interface Layer (typically Ethernet defines this), but depends on it for access to the 22 medium. 5.2 The Internet Layer

Su desarrollo comenz o en los a nos 70, cuando la DARPA (Defense Advanced Research Projects Agency ) se interes o en establecer una red de conmutaci on de paquetes que facilitase las comunicaciones entre los sistemas heterog eneos de sus instalaciones de investigaci on. La tabla muestra el formato de la cabecera de un paquete IP.

Sobre los servicios ofrecidos por IP (en la capa de red), se implementan otros protocolos como son TCP, UDP, ICMP e IGMP. TCP es un protocolo orientado a conexi on, que ofrece una comunicaci on able entre dos extremos, as como control de ujo y de congesti on. Se corresponde a la capa 4 (transporte) del modelo de referencia OSI. Para garantizar una transmisi on able, los extremos de una comunicaci on TCP deben empezar por establecer la conexi on. Cada paquete TCP incluye un n umero de serie correlativo, mediante el que se detectar a la la p erdida de paquetes o la llegada desordenada, o por duplicado. Todos los paquetes perdidos son retransmitidos sobre la red y, aunque ya se haya recibido alg un paquete posterior a uno perdido, a la capa de aplicaci on no se le puede dar esa informaci on para garantizar la secuencialidad de los datos. Esta caracter stica puede ser desastrosa para un sistema de comunicaciones de tiempo real.

23

Una alternativa que permite evitar este problema es el uso de UDP. El UDP es un protocolo no orientado a conexi on, es decir, cada paquete es manejado de forma completamente independiente. Por este motivo, UDP no ofrece abilidad, control de ujo ni recuperaci on de errores, cuesti on que puede ser favorable para un sistema de tiempo real. Otros protocolos de la pila TCP/IP son ICMP, destinado a tareas de gesti on de red, o IGMP, equivalente a ICMP pero para comunicaciones multipunto.

4.4.

ASN.1

ASN.1 es una notaci on formal usada para describir los datos transmitidos por protocolos de telecomunicaciones, independientemente del lenguaje en que se implementen o de la representaci on f sica de estos datos. Fue propuesto como est andar internacional en 1984, estando descrito por los est andares ISO 8824 y ITU-T X.680 a 683. La notaci on ofrece un cierto n umero de tipos b asicos predenidos, como enteros, cadenas de caracteres, valores l ogicos, etc., y hace posible denir tipos construidos como estructuras, listas, etc. on est a asociada con Una de las principales razones del exito de ASN.12 es que su notaci varios formatos de codicaci on estandarizados. Estos formatos describen c omo los valores denidos en ASN.1 deben ser codicados para transmisi on, de forma independiente de la m aquina, lenguaje de programaci on, etc. Habiendo varios de estos formatos, siempre es posible encontrar uno que se adapte a cada aplicaci on, y concretamente los formatos m as ligeros proporcionan una comunicaci on muy ligera en lo referente al ancho de banda necesario.

Bibliograf a de este cap tulo: [MAC02] [CHA02] [BRA03] [VER02] [SAM00]


Pese a que se oye poco hablar acerca de ASN.1, es empleado por numerosos protocolos y estructuras de datos, como el directorio X.500, los certicados digitales X.509, el protocolo IKE de intercambio de claves en IPsec, la informaci on de autenticaci on de Kerberos, SNMP, UMTS, ZigBee, RDSI, sistemas RFID...
2

24

Cap tulo 5 Introducci on a Foundation Fieldbus HSE


FOUNDATION HSE for high availability at the host-level
Plant Information Advanced Control Maintenance Operation Paper Scanner

Hub

Basic Control Safety Shutdown Chromatograph Compressors

Figure 3 HSE integrates subsystems

5.1.

Contrary to popular belief Ethernet alone does not make a device interoperable. That is because neither Ethernet nor TCP/IP make up a complete protocol stack (figure 4). Most networks based on Ethernet are in fact proprietary. A network technology therefore is also required to have an application layer and preferably a user layer is an open standard. If not, special drivers are ultimately required to access the Elthat est a ndar HSE es especialmente interesante para transmitir cheros grandes y para data. The HSE standard includes these layers thereby making it a completely open transferencias protocol. de datos de alta velocidad como por ejemplo entre PLCs y RTUs. Cuando

Por qu e Ethernet?

se dise n o el est andar HSE se hizo un enfasis especial en utilizar componentes comerciales OSI Model standard o the shelf -, y en que se mantuviesen todas las funciones de H1. Concretamente, User HSE al igual que en H1 , en HSE se siguen admitiendo transmisiones de dispositivo a dispositivo addition Application (incluso entre dispositivos H1 y HSE o entre dispositivos de segmentos H1 diferentes), por . siendo posible realizar un sistema de control sin que un controlador principal lo que sigue forme parte del bucle Transport TCP/IP de control [VER02]. Al elegir componentes comerciales, podemos beneciarnos de la econom a de escala Data Link
Ethernet Physical Network UDP/IP

Figure 4 Most Ethernet based protocols are not fully open because part of the "stack" is proprietary.

The lack of higher-level standards has prevented easy integration of other subsystems of the plant. With H1 users got the freedom to select any field device from any manufacturer. HSE does the same thing at the host-level. Users will because of this standard be able to mix and match subsystems for basic control, emergency shutdown, paper

25

de este tipo de mercado: gracias a la masicaci on en la producci on, los costes disminuyen espectacularmente, y hay mucha m as variedad de fabricantes que utilizando dispositivos y componentes dise nados espec camente para un bus de campo. Adem as, gracias a que toda la parte f sica (y las capas m as inferiores de los protocolos) ya est an desarrolladas, probadas y establecidas, el esfuerzo de ingenier a se puede centrar en las capas m as altas de la pila OSI. Igual que H1, HSE es un est andar abierto, lo que implica que cualquier fabricante puede disponer de las especicaciones para fabricar dispositivos compatibles. Ninguna de las capas est a ocupada por un protocolo propietario. Las capas inferiores de HSE se detallan en la norma IEEE 802.3u; utiliza Fast Ethernet para transmitir los servicios de H1, as como mensajes creados espec camente para HSE. La capa de aplicaci on de HSE contiene los protocolos DHCP (Dinamic Host Conguration Protocol ), SNTP (Simple Network Time Protocol ) y SNMP (Simple Network Management Protocol ). En la capa de usuario est a el agente de gesti on HSE y los bloques de funci on [MAC02].

5.2.

H1+HSE

Foundation Fieldbus HSE no est a pensado para sustituir a H1, si no para ser utilizado en combinaci on con este. Dado que las tecnolog as a nivel de campo y a nivel de control forman parte de una misma familia de protocolos, se consigue una gran integraci on, y el sistema sigue siendo abierto e interoperable sin perder funcionalidad por culpa elementos propietarios. H1 y HSE son esencialmente los mismos protocolos viajando por medios diferentes. En la arquitectura del sistema de control propuesto por Fieldbus Foundation, H1 se utiliza a nivel de campo para interconectar transmisores, posicionadores, etc., mientras que HSE se emplea en en un nivel superior, conectando los segmentos H1 y otros dispositivos de alta velocidad con las estaciones de trabajo. Cada uno tiene unas propiedades diferentes que lo hacen adecuado para su campo [BER02]. Por otra parte, pese a que Foundation Fieldbus fue desarrollado unilateralmente, se ide o como un bus que integrase las tecnolog as anteriores m as representativas, y como tal es muy gen erico, admitiendo m ultiples m etodos de comunicaci on y tipos de servicios. Esto permite a HSE interconectar no s olo dispositivos HSE y redes H1, si no tambi en redes de otros sistemas sin perder nada (o casi nada) de funcionalidad. Sin embargo, el control ya no ser a nativo, y aunque en la bibliograf a no se encuentran referencias a qu e soporte dar an los programas de dise no y gesti on de FF, no cuesta deducir que ser a necesario recurrir a otros programas de terceros con los que habr a que interactuar.

26

5.3.

Tipos de dispositivos HSE

En funci on de su nalidad, se denen cuatro tipos de dispositivos HSE [HUA01]: Linking device (LD) Provee acceso a dispositivos H1. Tambi en realiza puentes (bridging ) a nivel H1 entre las redes H1 conectadas al mismo dispositivo, o incluso a trav es de la red HSE hasta otros LD, u otros dispositivos HSE. Gateway device (GD) Da conectividad a otras redes no-FF . Los servicios ofrecidos depender an de las capacidades de la red en cuesti on. Ethernet device (ED) Es el equivalente a un dispositivo de campo H1, pero con una conexi on directa a red HSE. Host device (HD) Es un dispositivo no HSE que puede comunicarse con dispositivos HSE, como la estaci on de trabajo de un operador, o un servidor OPC1 .

5.4.

Benecios de HSE

Adem as de los mismos benecios del ciclo de vida de H1, HSE proporciona una espina dorsal para integrar todos los sistemas de la planta [FF96]:

5.4.1.

Alto rendimiento

Permite funciones de gesti on activa como diagn osticos, calibraci on, identicaci on, etc. para analizar la informaci on masiva -data mining - enviada por todos los dispositivos en tiempo real. La gesti on activa permite a los usuarios realizar acciones de mantenimiento preventivo.

5.4.2.

Interoperabilidad de subsistemas

Las plantas suelen estar compuestas por un cierto n umero de subsistemas independientes. Con HSE los subsistemas de cromatograf a de gases, esc aners de papel, sistemas de apagado de emergencia, etc. pueden ser integrados c omodamente gracias al protocolo abierto. Los usuarios pueden mezclar y combinar subsistemas para realizar tareas de control de todo tipo. Usando HSE puede accederse a la informaci on sin necesidad de programaci on a medida. Adem as, numerosas caracter sticas del sistema como la integridad de datos, diagn osticos, y redundancia son especicadas por HSE, por lo que funcionar an de forma perfectamente integrada entre dispositivos de diferentes fabricantes.
OPC es un sistema homog eneo de acceso a dispositivos de automatizaci on equivalente a lo que el servidor de impresi on de Windows lo es a las impresoras.
1

27

5.4.3.

Bloques funcionales

Los mismos bloques funcionales que se empleaban en H1 pueden utilizarse en sistemas HSE, por lo que sigue sin ser necesario el uso de lenguajes propietarios. Puede utilizarse el mismo lenguaje de programaci on de estrategias de control a lo largo de todo el sistema.

5.4.4.

Red troncal de control

HSE ofrece capacidades de comunicaci on de igual a igual -peer to peer -. Los dispositivos pueden comunicarse unos con otros sin necesidad de pasar por un ordenador central. Esto hace posible realizar estrategias de control avanzadas empleando variables de toda la planta sin el riesgo de un fallo del ordenador central.

5.4.5.

Ethernet est andar

La comunicaci on entre dispositivos HSE se realiza mediante cable Ethernet est andar; no hacen falta habilidades o herramientas especializadas para su instalaci on, por lo que esta es r apida y sencilla. Los componentes est andar Ethernet (COTS - Commercial O the Shelf ) se fabrican de forma masiva, gracias a lo que el cable, las tarjetas de interfaz y el resto del hardware de red tiene un coste extremadamente bajo en comparaci on con las redes propietarias. Las opciones Ethernet para el medio f sico incluyen par trenzado, bra optica e inal ambrico. Adem as, en caso de ser necesaria una abilidad mayor que la conseguida mediante componentes comerciales est andar (de ocina), todo el hardware de Ethernet puede conseguirse tambi en en categor a industrial de numerosos fabricantes.

Bibliograf a de este cap tulo: [BER02] [SAM00] [VER02] [HUA01] [SMA01] [FF96] 28

Cap tulo 6 Descripci on de los protocolos de H1 y HSE


Tal como ya se adelant o, HSE no s olo es un nuevo medio f sico sobre el que reenviar los paquetes de servicios H1, si no que tiene un funcionamiento ligeramente diferente en algunos aspectos, adem as de implementar ciertos servicios que H1 no ofrec a. Como HSE se desarroll o intentando mantener una integraci on total con H1, a continuaci on se comentan brevemente las caracter sticas t ecnicas de H1, para pasar a describir los aspectos comunes entre H1 y HSE, y terminar exponiendo las caracter sticas espec cas de HSE.

6.1.

H1

La tecnolog a de Foundation Fieldbus H1 se puede descomponer en tres partes [SMA01]: 1. La capa f sica 2. La pila de comunicaciones 3. La aplicaci on de usuario Seg un el modelo OSI, la capa f sica se corresponder a directamente con la capa 1. La pila de comunicaciones de H1 no necesita ser muy complicada, ya que no son necesarias tareas de enrutado, establecimiento de conexiones, etc., y por tanto, est a contenida completamente en las capas OSI 2 (capa de enlace de datos) y 7 (capa de aplicaci on). Las capas descritas por FF son: Fieldbus Message Specication (FMS), correspondiente a la capa 7 de OSI Fieldbus Access Sublayer (FAS), correspondiente tambi en a la capa 7 de OSI, por debajo de FMS. 29

Data Link Layer (DLL), correspondiente a la capa 2 de OSI.

=H

OSI MODEL*

>

FIELDBUS MODEL USER APPLICATION

USER APPLICATION
FIELDBUS MESSAGE SPECIFICATION

APPLICATION LAYER

7 6 5 4 3 2 1

FIELDBUS ACCESS SUBLAYER

PRESENTATION LAYER SESSION LAYER TRANSPORT LAYER NETWORK LAYER DATA LINK LAYER PHYSICAL LAYER

>

The Open System

COMMUNICATION STACK

nect (OSI) layered

nications model.

DATA LINK LAYER PHYSICAL LAYER PHYSICAL LAYER

Adem as H1 describe una u ltima capa que no est a denida por OSI; se colocar a inmediatamente por encima de la capa 7 y la denominan capa de usuario. En ella se especica el modelo de aplicaci on de usuario, describiendo, por ejemplo, la estructura y cal Layer is OSI layer 1. The Data Link funcionamiento de los bloques funcionales.

* The user aplication is not defined by de the OSI Model.

L) is OSI layer 2. The Fieldbus Message Specification (FMS) is OSI layer 7. The

cation Stack is comprised of layers 2 and 7 in the OSI model. 6.1.1. Capa f sica

La capa f sica est a denida en est andares aprobados por la IEC (International Electrotechnical Commission ) y la ISA ( Instrumentation, Systems,(FAS) and Automation us does not use the OSI layers 3, 4, 5 and 6. The Fieldbus Access Sublayer maps the Society, aunque se denen como International Society for Measurement and Control ). Las se nales the DLL. H1 se codican usando la t ecnica Manchester Bifase-L, por lo que se puede considerar serie s ncrono pese a no incluir una se nal de reloj independiente. para crear una tensi on de 1Vpp modulada sobre la componente continua de alimentaci on.

El dispositivo transmisor env 10mA a 31.25kbps sobre una carga equivalente de 50 Application is not defined by the OSI model.a The Fieldbus Foundation has specified a

ication model. Las especicaciones del bus admiten tensiones de alimentaci on entre 9V y 32V, pero para

H1 tambi en soporta buses de campo intr nsecamente seguros (IS) con dispositivos alimentados por bus. Para permitirlo, se introduce una barrera IS entre la fuente de alimentaci on en el area segura y dispositivo IS en used la zona H1 no est a basado bers below show the approximate number ofel eight bit octets forpeligrosa. each layer to

ed on the fieldbus.

aplicaciones IS el rango de tensiones admitidas depender a del grado de la barrera. Si ning un dispositivo lo necesita, tambi en se admite que el bus no transporte la tensi on de alimentaci osystem n. En ese la informaci on ser a lo of u nico poris el bus, y todos los r in the communication is caso, responsible for a portion thetransmitido message that dispositivos necesitar an una fuente de energ a alternativa [MAC02].

>

he USER data.
30

USER APPLICATION

USER DATA

be powered directly from the fieldbus and can operate on wiring that was

0 mA devices.

S. barrier is placed between the power supply in the safe area and the I.S. area.

en FISCO 1 , y por tanto el instalador deber a cerciorarse de que se cumplen las normas y todos los valores est an dentro de los valores admisibles, como por ejemplo en lo referente a intrinsically la inductancia y (I.S.) la capacidad del bus, o a la potencia m axima disponible para los s also supports safe fieldbuses with bus powered devices. dispositivos. La topolog a del bus no est a restringida a ser en arbol o completamente lineal, como en otros buses de campo, si no que se admiten topolog as h bridas, utilizando cajas de conexiones que permiten la incorporaci on de derivaciones. Para evitar problemas con las reexiones lo que se limita es la longitud total del cable.
USER LAYER

r spurs .

COMMUNICATION STACK

>
PHYSICAL LAYER

us is determined by the communication rate, cable type, wire size, bus

ption.

6.1.2.

Pila de comunicaciones

-JDAH AJ

La capacidad que tienen los dispositivos FF de asumir funciones de control se basa en una comunicaci on distribuida, que permite: Cada dispositivo puede intercambiar datos directamente con otros dispositivos. tengan un rendimiento estable.

Todos los dispositivos son make servidos a tiempo , de forma d to interconnect 31.25 kbit/s fieldbuses and them accessible to a que los bucles de control Para que el comportamiento sea determinista, es necesario evitar las colisiones. Para garantizar estas premisas, H1 utiliza un sistema por paso de testigo con un controlador principal, el LAS (Link Active Scheduler ). La funci on de LAS puede ser asumida
Fieldbus I.S. Concept, es un modelo de dise no de buses de campo para zonas IS basado en reglas emp ricas.

SE) backbone running at 100 Mbit/s or 1 Gbit/s. The I/O Subsystem

figure allows other networks such as DeviceNet and Profibus to be

FOUDATIONTMFieldbus function blocks. The I/O Subsystem Interface can be

Kbit/s fieldbus or 1 HSE.

>>
>
31

por un dispositivo de campo normal, o por un dispositivo especializado. Un dispositivo con capacidad para convertirse en un LAS se denomina Link Master, mientras que los que no tienen esa capacidad se llaman Basic Devices. De esta manera, en un bus pueden estar presentes varios Link Masters, para que en caso de fallar el LAS activo otro pueda reemplazarlo. El LAS controla y temporiza las comunicaciones en el bus, utilizando varios testigos y comandos que env a de forma rotativa a todos los dispositivos. Tambi en se encarga de autodetectar los dispositivos reci en conectados o los que est an fallando, congurando as un sistema plug and play. Todas las tareas con dependencias temporales fuertes se realizan manteniendo una agenda estricta de transmisiones. Esta planicaci on debe ser creada por el operador al congurar el sistema FF.

32

FF ofrece servicios de comunicaciones con transmisi on de datos programada (planicada de antemano de forma peri odica) y no programada (as ncrona, transmitida bajo demanda). Las tareas con una fuerte dependencia del tiempo y peri odicas, como la comunicaci on de una variable para un bucle de control, se realizan de forma programada, mientras que las transmisiones de diagn ostico, conguraci on, etc. se realizan de forma no programada. El LAS transmite peri odicamente un paquete de sincronizaci on (TD: Time Distribution ), para que todos los dispositivos tengan exactamente la misma hora. As en una transmisi on programada, el instante en que se inicia y la duraci on de la misma est an preestablecidos de forma precisa. Estas planicaciones se repiten c clicamente en lo que se denominan macrociclos. Cada tarea peri odica (no s olo las transmisiones, si no tambi en el momento de ejecuci on de cada bloque funcional) estar a programada para un instante concreto dentro del macrociclo, pero teniendo en cuenta que no puede haber m as de una simult aneamente que implique 2 olo puede acceso al bus , ya que para asegurarse de que no haya colisiones, un dispositivo s transmitir cuando el LAS le cede el control del bus mediante un paquete testigo. El LAS se asegura de que el testigo pase por todos los dispositivos de la lista de dispositivos vivos. Durante todo el tiempo en que el bus est a desocupado, bien porque los dispositivos est an en espera o porque est an realizando otras tareas, el LAS permite y arbitra el uso del bus para transmisiones no programadas. Al nal de cada transmisi on, comprueba si queda tiempo para hacer algo antes de la siguiente transmisi on programada, y en caso de que sea as , elige entre ceder el testigo a alguien para comprobar si tiene informaci on no programada por transmitir, o entre enviar un paquete de sincronizaci on, etc.

6.2.

Especicaciones comunes

En la capa de Aplicaci on de OSI, FF coloca dos de sus capas: la capa de especicaci on de mensajes (FMS) y la subcapa de acceso al bus (FAS).

6.2.1.

Fieldbus Access Sublayer (FAS)

La FAS proporciona una interfaz entre FMS y la capa de enlace (DLL) [SAM00], ofreciendo servicios de control y manejo de relaciones virtuales. Las Virtual Communication Relationships (VCR) describen diferentes tipos de procesos de comunicaci on, y permiten que las operaciones asociadas sean procesadas m as r apidamente. B asicamente, lo que hacen es asignar un c odigo de conexi on corto a la direcEs decir, as como se puede programar la ejecuci on de varios bloques funcionales independientes para 3ms despues de comenzar el macrociclo, no podemos hacer lo mismo con varias transferencias de informaci on a trav es de un mismo segmento H1 ya que provocar amos una colisi on.
2

33

ci on completa de una conexi on, simplicando el funcionamiento de las capas superiores y reduciendo la cantidad de informaci on a transmitir por el bus, adem as de controlar el funcionamiento de dicha relaci on virtual y gestionar parte del comportamiento redundante de la red. La capa de acceso al bus (FAS) soporta tres tipos de VCRs [FF96]: Publisher/Subscriber (Publicador/Suscriptor) Se utiliza para transmisiones de uno a muchos de datos que var an con el tiempo, de modo que cada dato transmitido sustituye el anterior. Pueden ser comunicaciones peri odicas o no programadas. Generalmente los dispositivos de campo utilizan este tipo para transmitir (publicador) o recibir (suscriptor) los par ametros de entrada/salida de sus bloques funcionales. Client/Server (Cliente/Servidor) Se emplea para transmisiones encoladas, no programadas, de uno a uno. Encolados signica que se env an todos los datos en el orden en que fueron solicitando su emisi on (en el tipo Publisher/Subscriber cada dato nuevo dejaba obsoleto al anterior, por lo que este era eliminado). El modo cliente/servidor suele ser utilizado por el operador para tareas de conguraci on, asentimiento de alarmas, y transmisiones varias a los dispositivos. Report Distribution (Noticaci on de eventos) Se utiliza para transmisiones encoladas, no programadas, de uno a muchos. Suele utilizarse para transmitir alarmas y noticaciones a las consolas de los operadores.

6.2.2.

Fieldbus Message Specication (FMS)

Los servicios de la capa de especicaci on de mensajes (FMS) permiten a las aplicaciones de usuario y a los dispositivos enviar mensajes a trav es del bus de campo utilizando un conjunto de formatos de mensajes est andar. Los tipos de datos que pueden ser comunicados sobre el bus de campo se asignan a ciertos servicios de comunicaciones. Para una asignaci on uniforme, se emplean descripciones de objeto (object descriptions ). Las descripciones de objeto contienen deniciones de todos los formatos de mensaje est andar, y tambi en incluyen datos espec cos de aplicaci on. Para cada tipo de objeto hay servicios de comunicaciones predenidos. Las descripciones de objeto se recopilan en un diccionario de objetos (Object Dictionary, OD). Se identica entonces la descripci on de cada objeto por su ndice dentro del diccionario [SAM00]: El ndice 0 describe la estructura del propio diccionario. Los ndices entre 1 y 255 describen tipos de datos b asicos (entero, cadena, punto otante, etc.). Las descripciones de objetos de las aplicaciones del usuario pueden empezar en cualquier ndice a partir del 255. 34

El FMS dene los Virtual Field Devices (VFD), dispositivos de campo virtuales que permiten utilizar remotamente los datos locales de cualquier dispositivo descritos en el diccionario de objetos. Un dispositivo t pico tendr a al menos dos VFDs [FF96]: Network Management (Gesti on de red) Permite congurar la pila de comunicaciones del dispositivo. Da acceso a la base de informaci on de gesti on de red (NMIB, Network Management Information Base ), y tambi en a la base de informaci on de gesti on del sistema (SMIB, System Management Information Base ). La NMIB incluye las VCR del dispositivo, variables din amicas, estad sticas, y la programaci on del LAS si el dispositivo es un Link Master. Los datos de la SMIB incluyen la etiqueta y la direcci on del dispositivo, y las programaciones horarias de ejecuci on de sus bloques funcionales. User Application (Aplicaci on de usuario) Da acceso a todas las funciones del dispositivo, como sus sensores, actuadores, etc. Tambi en permite congurar el funcionamiento del hardware, cargar informaci on de calibraci on, etc. La sintaxis exacta de los paquetes FMS est a descrita por el est andar ASN.1 de CCITT (ahora ITU-T).

6.3.

HSE

Las capas f sica y de enlace empleadas por HSE son las correspondientes a Ethernet. Las capas de red y transporte, son manejadas por UDP, TCP e IP. Las capas de sesi on y transporte no se utilizan, y en la capa de aplicaci on aparecen un gran n umero de protocolos: SNMP, DHCP, BOOTP, SNTP, as como ciertas especicaciones propias de HSE: FDA, FMS o SM [FF96]. Puede observarse que efectivamente basaron el trabajo en los est andares previos internacionales (tal como se declar o en los objetivos de la fundaci on), ya que la mayor parte del sistema est a descrito por protocolos bien conocidos.

35

Bridge NMA VFD OD HSE SMIB HSE NMIB H1 HSE HSE Interface SMK LRE 1

FBAP VFD H1 1 Interface N OD

FBAP VFD 1 OD

HSE Management Agent

Field Device Access Agent

D H C P UDP

S N T P

S N M P HSE MIB

TCP IP

IEEE 802.3 MAC and PHY Layers


Figure 2 Fieldbus HSE Profile Functional Areas

De forma equivalente a H1, por encima de la capa de aplicaci on se dene una capa de usuario, donde se especica la estructura y funcionamiento de los bloques funcionales, el modo de interconexi on, etc.

6.3.1.

Especicaciones de HSE

Presencia Ethernet Se denomina Presencia Ethernet (Ethernet Presence ) al m odulo que ofrece los servicios de inicializaci on de las pilas Ethernet, comunicaci on de prop osito general a trav es de los medios Ethernet, sincronizaci on, y la gesti on referente a Ethernet [FF96]. Las especicaciones de HSE intentan abarcar todos los medios f sicos y modos de se nalizaci on descritos en IEEE 802.3 y 802.3u. La gesti on de la Presencia HSE utiliza una versi on aumentada de SNMP para soportar los par ametros de la pila Ethernet u nicos en FF. El juego de protocolos a incluir en la implementaci on de una Presencia Ethernet se resumen en la tabla.

36

to the HSE network. An Ethernet Device (ED) may execute function blocks and may have some conventional I/O. A Gateway Device (GD) interfaces other network protocols such as Modbus, DeviceNet or Profibus. A Host Device (HD) is an operator workstation or an OPC server.
H1 and HSE Benefits H1 HSE List of Required Internet Protocols TABLE A Internet RFC 768 791 792 793 826 1112 1122 1155 1157 1213 1533 1541 1643 2030 User Datagram Protocol (UDP) Internet Protocol (IP) Internet Control Message Protocol (ICMP) Transmission Control Protocol (TCP) Optional) Ethernet Address Resolution Protocol (ARP) Internet Group Management Protocol (IGMP) Requirements for Internet Hosts Communication Layers Structure and Identification of Management Information Simple Network Management Protocol (SNMP) Management Information Base-II DHCP Options and BOOTP Vendor Extensions Dynamic Host Configuration Protocol Definitions of Managed Objects for the Ethernet-like Interface Types Simple Network Time Protocol

Part 4 The I/O gateway is an HSE device that is similar to the linking device, but it connects the HSE to one or more I/O devices or buses. The MIO blocks are ideal to gateway remote-I/O protocols such as Modbus and Profibus-DP that contain mainly process input and output information into the fieldbus environment. 3.6.1.4. Host Device (OPC DA server) Non-HSE devices capable of communicating with HSE devices. Examples include configurators and operator workstations. 3.6.2. Ethernet Presence 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. Management

FDA Agent - Agente FDA

24

1996 (Rev.1998, 2003) Fieldbus Foundation, Austin, Texas. All rights reserved.

Se dene tambi en el Agente FDA (Field Device Access, acceso al dispositivo de campo), con los siguientes objetivos [FF96]: Transportar servicios de gesti on (SM, System Management ) a trav es de UDP, y servicios FMS (Fieldbus Message Specication ) a trav es de TCP/UDP. Esto permite conectar dispositivos de campo HSE y H1, dispositivos convencionales de I/O, y dispositivos de entrada-salida no-FF a una red HSE a trav es de un Linking Device o un Gateway Device. Republicar datos H1 de Linking Devices que no permitan realizar puentes H1-HSE. Esto permite construir los dispositivos de enlace a partir de m ultiples interfaces H1 en vez de usar un puente H1. Enviar y recibir mensajes de redundancia de red para soportar la redundancia de las interfaces de los dispositivos HSE. El agente FDA permite que los sistemas de control operen sobre HSE y/o a trav es de Linking Devices, y permite que aplicaciones remotas accedan a los dispositivos de campo de cualquier tipo a trav es de TCP/UDP utilizando una u nica interfaz.

37

HSE System Management (SM) - Gesti on del Sistema HSE La gesti on del sistema es la actividad que integra los dispositivos de una red HSE en un sistema de comunicaciones coherente. Se soportan las siguientes funciones [FF96]: Cada dispositivo tiene una identidad u nica y permanente, as como un nombre congurado para un sistema concreto. Los dispositivos mantienen informaci on de control de versiones. Los dispositivos responden a peticiones para localizar objetos, incluyendo al dispositivo mismo. La hora se distribuye a todos los dispositivos de la red. Se utilizan las programaciones horarias de bloques funcionales para asegurar que cada bloque se inicia en su momento. Puede a nadirse o retirarse un dispositivo a la red sin afectar a otros dispositivos. HSE Network Management (NM) - Gesti on de la Red HSE La gesti on de red permite a los hosts HSE transmitir las operaciones de gesti on a trav es de la red HSE. Se ofrecen las siguientes capacidades [FF96]: Congurar el puente H1, que permite reenviar y republicar informaci on entre interfaces H1. Cargar conexiones est aticas entre dos o m as dispositivos HSE individualmente o desde una lista. Cargar VCRs individualmente o desde una lsita. Las VCR en HSE son las relaciones de comunicaciones que permiten acceder a un dispositivo de campo a trav es de HSE, pasando si es necesario por una subred H1. Monitorizar el rendimiento a trav es de la recolecci on de estad sticas para las conexiones est aticas, VCRs, y puentes H1. Monitorizar la detecci on de fallos.

Bibliograf a de este cap tulo: [SAM00] [SMA01] [FF96] [MAC02] [HON01] [VER02] [HUA01] 38

Cap tulo 7 Limitaciones


7.1. Limitaciones generales

HSE est a desarrollado a partir de Ethernet, una tecnolog a pensada originalmente para el entorno de la ocina, y por tanto es necesario adaptarla al entorno industrial. Hay que proporcionarle robustez industrial. La red de control es la que une todos los subsistemas, por lo que la visibilidad de cientos o quiz a incluso miles de bucles depender an de la integridad de la red de control. Un fallo completo puede representar p erdidas enormes [FF96]. Entre los problemas que se pueden encontrar al intentar emplear una Ethernet para tareas industriales est an [MAC02]: Falta de determinismo No se puede alimentar los dispositivos a trav es del bus (exige un cable adicional para el transporte de potencia) Las tarjetas de interfaz tienen consumos altos No es intr nsecamente segura Los protocolos est andar no se adaptan a tareas de control (sobran muchos campos, y hay unas taras (overhead ) por paquete demasiado elevadas) La longitud del cable est a limitada a unos 100m Necesita hubs y cable multin ucleo Para empeorar las cosas, al contrario de lo que pudiera parecer, el empleo de Ethernet no garantiza la interoperabilidad de los sistemas, debido a que ni Ethernet ni TCP/IP especican una pila de protocolos completa. De hecho, la mayor parte de las redes basadas 39

en Ethernet son propietarias. Para asegurar la interoperabilidad, es imprescindible especicar todas las capas necesarias, sea empleando est andares ya existentes o proponiendo nuevos est andares. Concretamente, es necesario especicar una capa de aplicaci on y preferentemente tambi en una capa de usuario que sean est andares abiertos. Por supuesto, HSE incluye estas capas en las especicaciones [BER02].

7.2.

Robustez f sica y cableado

Las formas modernas de Ethernet utilizan cable UTP (Unshielded Twisted Pair ) de pares trenzados usando una topolog a en estrella basada en hubs en la que hay un u nico dispositivo por segmento. Esta topolog a tiene la ventaja de que la conexi on o desconexi on de un dispositivo, o su mal funcionamiento, no afectar a al funcionamiento de ning un otro segmento, pero es muy ineciente en comparaci on con la topolog a lineal t pica de un bus de campo porque exige una longitud total de cable desplegado mucho mayor, con el coste que ello implica [FF96]. La propia robustez del sistema es mucho menor que la exigida en un ambito industrial: es necesario modicarlo para adaptarlo a situaciones de humedad, polvo, vibraci on, golpes, calor o fr o. Esto incluye no s olo los dispositivos de proceso, si no tambi en el cable y los conectores. Actualmente hay un n umero creciente de fabricantes que ya ofrecen conectores y dispositivos de categor a industrial. Los conectores Ethernet de categor a industrial est an sellados contra contaminantes del entorno, tienen una mayor protecci on frente a la vibraci on, son mucho m as robustos, y se comportan muy bien en entornos en existen hubs de categor a industrial con fuentes el ectricamente ruidosos [VER02]. Tambi de alimentaci on redundantes, rangos de temperatura muy amplios, carcasas m as robustas, ectrico y a diferencias de potencial entre etc [FF96]. Para aumentar la tolerancia al ruido el las tierras, puede utilizarse bra optica. En todos estos casos, se sigue manteniendo una total compatibilidad con otros dispositivos Ethernet, por lo que una empresa puede decidir emplear hubs de categor a industrial en las zonas agresivas, pero manteniendo hubs normales en las zonas con ambientes m as tranquilos.

7.3.

Falta de determinismo

En general, la informaci on transmitida por una red industrial puede ser de tiempo real o puede no serlo. La informaci on que no es de tiempo real no tiene l mites temporales estrictos en los retardos sufridos durante el intercambio de datos. En contraste, la informaci on de tiempo real tiene unos l mites muy estrictos y el valor de cada dato disminuye conforme aumenta el retardo en la entrega. En ciertos casos, puede ser peor una entrega fuera de un lapso de tiempo aceptable que la p erdida de ese paquete. La informaci on de tiempo real se puede dividir a su vez en peri odica y as ncrona dependiendo de la natu40

raleza de la generaci on de los datos. En la mayor a de los casos, toda esta informaci on se transmite por la misma red a pesar de que exigen caracter sticas muy diferentes a la comunicaci on. Ethernet utiliza un m etodo de acceso al medio de tipo CSMA/CD. CSMA/CD permite trabajar con retardos peque nos si la carga es peque na, pero el retardo aumenta de forma aleatoria seg un aumenta la carga, hasta el extremo en que el sistema puede fallar completamente si la carga es demasiado elevada. Este fue uno de los motivos fundamentales que frenaron la entrada de Ethernet en la industria: la falta de determinismo (no se puede predecir cu anto tiempo tardar a en enviarse un paquete concreto), y la falta de robustez (bajo condiciones de mucha carga, un paquete puede llegar a perderse por culpa del protocolo MAC, ya que tras 16 colisiones el paquete se descarta directamente) [MAC02]. Sin embargo, desde no hace mucho tiempo se ha popularizado la Ethernet conmutada. Un hub compartido es un repetidor multipuerto que une varios segmentos en una u nica red. Un hub conmutado (habitualmente denominado switch ) es un puente de varios puertos que une varias redes. Los hubs conmutados (o switches) emplean t ecnicas de tipo almacenaje y retransmisi on. Gracias a que en una topolog a en estrella cada segmento une s olo un dispositivo al switch, si dos dispositivos de la red deciden transmitir al mismo tiempo, ser a el switch quien almacene temporalmente uno de los paquetes para retransmitirlo despu es, evitando as la colisi on [CHA02]. En una red conectada enteramente mediante dispositivos de alacenamiento y retransmisi on los retardos medios se minimizan, haci endose casi independientes de la cantidad de tr aco ofrecido a la red, y reduci endose dr asticamente en caso de cargas elevadas. La red deja adem as de ser inestable, ya que no se va a descartar ning un paquete en el nivel de red.

7.4.

Redundancia

En el nivel de campo, la redundancia se suele buscar distribuyendo tareas, de forma que un fallo afecte s olo a un peque no sector. En el nivel de control, la red y los dispositivos se comparten entre muchos bucles de control, haciendo que estos componentes sean cr ticos para la operaci on de la planta. El este nivel el proceso est a m as centralizado, y por tanto la estrategia empleada generalmente es la redundancia. HSE soporta una redundancia completa en dispositivos y medios de transmisi on. La parte del protocolo HSE que se encuentra en cada dispositivo relativa a diagn osticos de comprobaci on de integridad y gesti on de redundancia, permite el uso de dos redes completamente independientes, puertos de comunicaci on redundantes, y tambi en pares de dispositivos redundantes. El cambio de un dispositivo o medio estropeado al de respaldo es inmediato y transparente. Gracias a los mecanismos del protocolo, una aplicaci on de control ve u nicamente un dispositivo Ethernet: o el primario o el secundario. En caso de fallo, el propio protocolo 41

HSE realiza la conmutaci on de forma completamente transparente. Todos los dispositivos mantienen de forma independiente informaci on acerca del funcionamiento de la red, y dado que HSE especica tambi en la capa de aplicaci on, todos los dispositivos intercambian peri odicamente esa informaci on. Gracias a ello se detecta inmediatamente cualquier fallo, no s olo los producidos en el dispositivo activo, si no tambi en en el de respaldo, notic andolo al operador con un retardo m nimo. La redundancia de dispositivos se implementa usando dos dispositivos id enticos, uno primario y el otro secundario. El protocolo HSE especica c omo se comunican estos dispositivos con el resto de la red, y c omo la comunicaci on se conmuta de uno a otro en caso de fallos. Sin embargo no especica c omo se conmuta la funcionalidad, o c omo se sincronizan los datos y la conguraci on. Por supuesto, es imprescindible que en el momento de la conmutaci on ambos dispositivos contuviesen la misma informaci on y conguraci on, pero queda a elecci on del fabricante decidir c omo llevarlo a cabo. Esto obliga a que los dos dispositivos de cada par redundante sean del mismo fabricante. HSE admite las siguientes combinaciones topol ogicas: 1. Dispositivos de interfaz u nica en una u nica red. 2. Dispositivos de dos interfaces en dos redes. 3. Dispositivos de dos interfaces en una u nica red.
FOUNDATION HSE for high availability at the host-level
Workstations with Dual NIC

Primary hub

Secondary hub

Redundant single port Linking device

Single dual port Linking device

Redundant dual port Linking device

Por supuesto la mejor combinaci on es la segunda, pero tambi en es la m as cara, y por The philosophy of the HSE redundancy is that of "operational transparency ello HSE admite cualquier combinaci on de ellas. Adem as, en caso de utilizar dos redes and diagnostic no visibility". This means the control application independientes, es imprescindible que that sus topolog as sean id enticas. only sees either the primary or the secondary Ethernet device depending on which one is active, whereas the system diagnostics sees both. Thus the diagnostics can make sure that even the inactive devices are fully functional and ready to take over at any moment. A wide diagnostic coverage is an integral part of the HSE protocol going far beyond mere hardware duplication. Every 42 HSE device, including the host or any "redundancy manager", independently keeps track of the status of the networks and all the devices on it. Because HSE is not only Ethernet media but also has a standard application layer, devices from different manufacturers periodically exchange their view of the network with each other using diagnostic messages through all ports on both networks which also serve as sign of life indication. Every

Figure 10 Three types of redundancy

7.5.

I.S.

La t ecnica m as popular para la protecci on de sistemas de instrumentaci on es la seguridad intr nseca (IS). En principio, los dise nos IS aseguran la seguridad limitando la energ a disponible en la zona peligrosa a niveles por debajo del punto en que se podr a iniciar una explosi on, por chispa o supercie caliente, durante condiciones normales o de fallo.
Communication FOUNDATION Fieldbus

Esta t ecnica se viene utilizando con exito a lo largo del mundo desde hace d ecadas, y la mayor a de los est andares mundiales coinciden de forma muy aproximada en los l mites seguros y en las curvas de ignici on basadas en tensiones en circuito abierto y corrientes de cortocircuito. Estas limitaciones obligan a conectar un n umero muy reducido Physical layer de dispositivos a cada segmento del bus (generalmente menos de cuatro). La otra gran opci on es FISCO (Fieldbus Intrinsically-Safe Concept ), que intenta estirar la capacidad del dise no IS bas andose en pruebas emp ricas para admitir m as corriente de la permitida por las curvas de ignici o n convencionales. FISCO ha demostrado ser realmente The specification of the FOUNDATION Fieldbus is not yet completed at this seguro, pero esa debe ser demostrada mediante on pr acticas, stage. However, it is seguridad certain that the topology of a FF system complies with pruebas de explosi y the noIEC mediante dise no en papel Fieldbus model in many aspects. [NEI02].
IEC fieldbus

En casos se limita tambi en la by capacidad e sysinductancia The IEC ambos fieldbus solves pending communication tasks using two bus por tanto suintrinsically longitudsafe m a xima). tems, the slow, H1 bus and the fast, higher-level H2 bus with
1 to 2.5 MBit/s (see IEC fieldbus model /Lit. 4/).

m aximas del cable (y

OUNDATION fieldbus

Las redes Ethernet no fueron dise nadas pensando en ninguna de estas normas, y por tanto no pueden ser adaptadas sin emplear que no cumplan los requisitos de The physical design of the H1 bus of the FOUNDATION dispositivos fieldbus complies IEEE y por tanto que no sean est andar, perdiendo as las ventajas que ofrec a exactly802.3u with the specifications of the IEC fieldbus model. The specification of trabajar con Ethernet. the H2 bus is not yet completed and the publication of the preliminary speciEn una red FF, la u nica alternativa para las comunicaciones en zonas peligrosas es la Ethernet (HSE) will be used (Fig. 4). utilizaci on de buses H1, obligando a colocar los Linking Devices, hubs, y dem as elementos de las redes HSE en zonas seguras.
user 2 user 1 switch user n

fication (PS) has been announced. However, it is certain that the High Speed

High Speed Ethernet (HSE)


(100 MBit/s, LWL)

bridge intrinsically safe area R user 1 1 Teilnehmer

H1bus (31.25 kBit/s, IEC 61158-2)

R user m

user 2

43

SAMSON AG V74/ DKE

Bibliograf a de este cap tulo: [BER02] [VER02] [MAC02] [HON01] [CHA02] [FF96] [NEI02]

Fig. 4: Structure of the FOUNDATION fieldbus

Bibliograf a
[ARC01] Fieldbus Success Stories and Strategies, ARC Advisory Group, Jul. 2001 [BER02] Jonas Berge, Foundation HSE for high availability at host-level, Smar Singapore Pte Ltd., 2002 [BRA03] Bertrand Braux, Ethernet industriel: o` u en est-on?, Mesures, vol 757, pp: 60-63, 2003 [BRO03] Fieldbus Solutions Overview, Broadley James Corporation 2003 [CHA02] Kyung Chang Lee, Suk Lee, Performance evaluation of Switched Ethernet for Networked Control Systems, School of Mechanical Engineering, Pusan National University, 2002 [COM03] Communication Networks, 2004 [COU95] Jason Coutinho, Stephen Martin, Gary Samata, Steve Tapley, Daniel Wilkin, Fieldbus Tutorial, Curtin University of Technology, 1995 http://kernow.curtin.edu.au/www/Fieldbus/fieldbus.htm [FEL02] Max Felser, The Fieldbus Standards: History and structures, University of Applied Science Berne 2002 [FF96] Foundation Fieldbus Technical Overview, Fieldbus Foundation 1996 [HON01] Seung Ho Hong, Byung Don Jang Time-Critical Data Transmission in the Foundation Fieldbus, School of Electrical Engineering and Computer Science, Hanyang University 2001 [HUA01] Yang R. Huan, Pee S. Hong, Jonas Berge, Barnaby Sim, Foundation Fieldbus High Speed Ethernet (HSE) Implementaci on, Proceedings of the 2002 IEEE International Symposium on Intelligent Control, 2001 [HUL02] R.A. Hulsebos, Bus Comparison Matrix, 2002 [LUC01] Luciano Liboni, Evaluating a Foundation Fieldbus System - 20 Questions & Answers, System 302 enterprise automation, Sep. 2001 [MAC02] Steve Mackay, Foundation Fieldbus High Speed Ethernet (HSE) and TCP/IP, IDC Technologies, 2002 [NEI02] Mike ONeill, Practical Aspects of Fieldbus Installation, Hawke International Fieldbus Division, 2002 [PIN01] Mario Pinotti Jr., Dennis Brand ao Projecting and Integrating Fieldbus Foundation Function Blocks, Departamento de Engenharia Mec anica, Escola de Engenharia de S ao Carlos 2001 44

[SAM00] Foundation Fieldbus Communication, Samson AG, 2000 [SMA01] Fieldbus Tutorial, A Foundation Fieldbus Technology Overview, Smar, 2001 [VER02] Ian Verhappen, High Speed Ethernet - The Enterprise Integration Enabler, 2002

45

You might also like