Foundation Fieldbus y su adaptación a la alta velocidad: HSE

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 Profibus, 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

4

2. Fieldbus Foundation y Foundation Fieldbus

7

2.1. ¿Quien es Fieldbus Foundation? . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2. ¿Qu´e es Foundation Fieldbus? . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3. Descripci´on de Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . . .

9

2.4. Est´andares definidos 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: Profinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

2

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. Beneficios 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. Especificaciones comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.1. Fieldbus Access Sublayer (FAS) . . . . . . . . . . . . . . . . . . . . 33 6.2.2. Fieldbus Message Specification (FMS) . . . . . . . . . . . . . . . . 34 6.3. HSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.1. Especificaciones 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

3

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 especificaciones [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´ıfica de las tareas a controlar exigi´o que se dise˜ nasen un gran n´ umero de instrumentos y m´etodos de control a medida para las diferentes aplicaciones [COU95]. Poco tard´o en producirse un 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 trabajo de estandarizaci´on [FEL02]. La idea b´asica detr´as del est´andar es que establece una especificaci´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 especificaciones 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 Profibus por parte de Alemania. Ambas fueron estandarizadas a sus respectivos niveles nacionales y finalmente propuestas a la IEC para su estandarizaci´on internacional. Desafortunadamente las filosof´ıas de los dos sistemas eran completamente diferente. Profibus 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 beneficios 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 modificar 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 Profibus con el modelo publicador-suscriptor [FEL02]; su intenci´on era crear un bus internacional para uso en entornos peligrosos. Para los a˜ nos 90 WorldFIP y Profibus PA se segu´ıan peleando en sus respectivos terrenos, y la IEC a´ un no hab´ıa conseguido ning´ un avance significativo. La u ´nica excepci´on fue la definici´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. Profibus PA (la organizaci´on de usuarios de Profibus) sigui´o persiguiendo el mismo objetivo por su cuenta. Mientras Profibus 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 especificaci´on de su bus de campo,

5

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 igualdetermines que Profibus detalles de la To especificaci´ n de ISP. Por este motivo “scheduler whichPA) station make the oCENELEC collection easier to el controls timingdel on bus the bus, with id´ theentico “delegated dise˜ nothef´ısico es casi en ambos handle, buses the de various campo.fieldbus La interfaz aplicaci´ on, 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 passedAfrom station to station busfalta access. Theest´ estas alturas, pesefor a la de un andar internacional,systems”, los diferentes buses de“High camcommunication EN 50254 problem these waselthat subsystems for small po yawith se hab´ ıanall-inclusive hecho unapproach hueco en mercado.efficiency Debido acommunication 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 andares EN 50170,process, EN 50254 have resulted in incompatible and not interoperableah´ı surgieron phases oflos theest´ European standardization 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

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

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

In 1995, after long years of struggles between the un European standards. a compilation Por parte, la FF, hab´ıathedecidido bus pr´ actico Tab. sin 2lashows exigencia de dar German andsu French experts to combine 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 noellonger watchen thedos endless mente dividieron trabajo secciones:should H1 que ser´ıathat una bus de campo baja be noted comparable, thoughdemuch discussions. With the end of the ISP project, they less disputed standardization processpor tookprimera place velocidad, y H2, que ser´ıa su equivalente de alta velocidad. En 1998 surge 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 especificaciones finales [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 finales, que repartidos por todo el mundo, revisan las actividades de la fundaci´on y se aseguran de que las especificaciones cumplan las necesidades del mercado.

7

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$%%

,QYHQV\V

0DJPHWHUV

3UHVVXUH7UDQVPLWWHU

3UHVVXUH7UDQVPLWWHU

7HPSHUDWXUH7UDQVPLWWHU

9RUWH[6ZLUO0HWHUV

9RUWH[)ORZPHWHU

0DVV)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

(PHUVRQ3URFHVV6ROXWLRQV

+RQH\ZHOO

'LJLWDO9DOYH&RQWUROOHU

3UHVVXUH7UDQVPLWWHU

)OR9XH)LQDO&RQWURO6\VWHP

7HPSHUDWXUH7UDQVPLWWHU

3UHVVXUH7UDQVPLWWHU

actually a very quick process. The original idea for using Ethernet in conjunction with Foundation Fieldbus to create a high-speed

7HPSHUDWXUH7UDQVPLWWHU


9DOYH3RVLWLRQHU

$QDO\WLFDO(TXLSPHQW

9RUWH[)ORZPHWHU

9DOYH3RVLWLRQHU

0DJPHWHUV

7HPSHUDWXUH7UDQVPLWWHU

$QDO\WLFDO(TXLSPHQW

9RUWH[)ORZPHWHU

&RULROLV)ORZPHWHU

3UHVVXUH7UDQVPLWWHU

control network was born in 1998. Final specifications for HSE FF were released in March of 2000, after months of intensive testing and validation.

0DMRU6XSSOLHUVDQGWKHLU)RXQGDWLRQ)LHOGEXV &RPSDWLEOH3URGXFWV

2.2.

In December of 2000, the FF released a test-

¿Qu´ e es Foundation Fieldbus?ing

kit for HSE linking devices (HTK).

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 definidas 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 Profibus PA: mientras que PA est´a mucho 1R6KRUWDJHRI3URGXFWV$YDLODEOH%XW&HUWLILHG))+RVW m´as extendido en Europa, H1 tiene su origen y su ´area de mayor distribuci´on en 6RIWZDUH,V6FDUFH 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 ken FF products have been certified andvelocidad tested by(como the Foundation. PLCs), redes H1, servidores de datos, y estaciones de trabajo. Other suppliers, such as Fisher-Rosemount, Yokogawa, Smar, and Endress+Hauser, offer complete suites of process instrumentation that are FF-

Est´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  a trav´es de los End User Councils, repartidos decisiones tomadas por sus propios usuarios 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”.

8

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).

Control System Network Controller

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

Control System Network

HSE

Input/Output AO Subsystem AI

Input/Output Subsystem H1

Traditional 4-20 mA One Variable One Direction

Linki Devi

Controller PID

Linking Device

4-20 mA

Traditional Control and I/O requires extra equipmnet

Fieldbus Multiple Variables Both Directions

Figure 6

Figure 4

Resumen de caracter´ısticas de Foundation Fieldbus: Apropiado para su uso en zonas de seguridad intr´ınseca (IS) Control System Network

Control System

Dispositivos deNetwork campo alimentados a trav´ es del bus HSE Controller Topolog´ ıa en bus o en ´arbol

Input/Output Subsystem

Remote Input/Output

Subsystem Permite comunicaci´ on multi-master

Comportamiento determinista

Linkin Devic

Controller

Linking Device

I.S.

I.S.

I.S.

I.S.

H1 4-20 mA

F

Transmisi´on de datos distribuida Traditional 4-20 mA Modelo de atbloques estandarizado paraFieldbus una interfaz uniforme View Stops I/O Subsystem View Extends into Instrument

Opciones de extensi´on flexibles 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 refiere a que los sensores y actuadores no s´olo act´ uan como tales, si no que pueden realizar funciones adicionales de comunicaci´on 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 define 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 fiabilidad 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 definen 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 configurar par´ametros que afectan al dispositivo en su conjunto. Bloques de transductor Permite configurar 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 configurados para realizar el proceso, es necesario configurar 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 2

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.

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 definen 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 definido 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 dePart control 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

OUT

BKCAL_OUT

CAS_IN

IN BKCAL_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 final pueda estar seguro de la interoperabilidad de un dispositivo, FF ofrece via the fieldbus. The configuration shown to thepuedan con- comprobar sus unatransmitted serie de programas de certificaci´ on, para que corresponds los fabricantes productos garantizar su calidad. trol loopyexample illustrated in Fig. 2. Todas las funciones realizables en un sistema FF son configuradas 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 config-

ures the individual loop execution rate. Based on this data and the wiring di-

rate

agram, the configuration tool generates the information needed to control the devices and the communication.

11

Finally, this data is entered into the individual field devices. During this pro-

configuration of LAS

cess, the LAS is configured and all Link Masters receive the current transmis-

and Link Masters

sion 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 configurar y comunicarse con un dispositivo.

2.4. 2.4.1.

Est´ andares definidos por FF H1

El protocolo H1 est´a basado en el est´andar IEC 61158-2 [SAM00]: Se transfiere la informaci´on utilizando codificaci´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 filtro 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

1 device per spur

2 devices per spur

3 devices per spur

4 devices per spur

25-32

1m

1m

1m

1m

19-24

Control Room 30 m Equipment

15-18

60 m

Trunk*

Junction Box

13-14

90 m

1-12

120 m

1m Devices ***

1 Spur Length**

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

1 metre 30 metres 60 metres 90 metres 120 metres

m m

90 m

m

1m

1m

1m

30 m

1m

60 m

30 m

Spurs

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

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

with junction boxes, also star, tree or a combination of topologies (Fig. 5).

s via T-connector

**

Single device per spur -- The spur length must be reduced by 30

The metres devices areadditional best connected via short spurs using tee connectors to enfor each device on a spur. able*** connection/disconnection the The number of devices possibleofon thedevices 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 Physical Layer Standard for details.

15 is limited to 120 meters and depends on the 4 The maximum length ofFigure aFigure spur 40

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

la calidad del cable. Sin repetidores y con el mejor cable contemplado4 , la longitud 4 Without the maximum length of segment can be as admite long m´aximarepeaters, de un segmento H1 puede serandeH1 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 9500 can be Theconectados short spursRate from the se field deviceato32 theenbus El n´ um mero de jumpered. dispositivos al bus reduce 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, twisted

multi-twisted

pair without

Size

0.8 mm2 (AWG 18)

Max. length

1900 m

0.32 mm2 (AWG 41 22) Figure 1200 m

without twisted

2-12pairs, without 1900shield m 120 m

0.13 mm2 (AWG 26)

1.25 mm2 (AWG 16)

400 m

200 m

incl. spursof devices possible on a fieldbus link depends on * The number 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

SAMSON AG ⋅ V74/ DKE

description

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

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

23

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

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, finalmente 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 fibra ´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 oficina). 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 especifica las capas m´as bajas de la pila de protocolos, queda mucho que desarrollar y especificar 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 Profibus, Foundation Fieldbus H1 o Controlnet. Profibus tiene una tasa de transferencia m´axima de 12Mbps; FF H1 trabaja a 31.25Kbps, y Controlnet a 5Mbps. Se acompa˜ na un gr´afico (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

Corporate Information Discrete

AS-i Seriplex Impacc CAN SensorPlex

Interbus-S PROFIBUS DP

ATM / FDDI

SDS DeviceNet PROFIBUS FMS ControlNet Modbus + / DH+ ECHELON PROFIBUS PA HART World FIP

Foundation Fieldbus HSE

Foundation Fieldbus H1

16

Process / Continuous

LONworks

Figure 1 Fieldbus Protocol Application Regime

Instrumentation Control Bit-Level Sensor

3.1.

Algunos buses de inter´ es

3.1.1.

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 significa Internet Protocol si no Industrial Protocol. Su pila se compone, por tanto, de Ethernet, IP, UDP o TCP, y CIP.

3.1.3.

Siemens: Profinet

Profibus (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 Profibus International hacia Ethernet est´a recopilada en el proyecto Profinet, que se divide en tres versiones (V1, V2 y V3) seg´ un las restricciones temporales de la aplicaci´on. Profinet V1 utiliza Ethernet de una forma transparente con Profibus 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 Profibus. 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 Profibus (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 Profinet V1, sigue dependiendo de H1 para las tareas de campo, conect´andose en general1 los dispositivos a la red HSE a trav´es de una red H1 y una pasarela [BRA03]. Acerca de los tiempos de respuesta, se habla de “algunos milisegundos” sin especificar 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

2.

Review of the Fundamentals

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 aispido los principales relacionados con the outset that the oOSI Modelr´ not de a protocol or set ofprotocolos 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).

4.1.

Capas OSI

The diagram below shows the seven layers of the OSI Model.

Full Architecture OSI Model El modelo OSI defineFigun1. contexto sobreofel 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 user’s 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.

ficando 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 define 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´a u ´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 significa 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 twinsifibre 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 notifica 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 Detection) which is why most industrial users were initially cautious about the use ofdetecta la colisi´ n,transfer en vez de dejarwas de transmitir inmediatamente, transmite una trama de una Ethernet as oall of data probabilistic and not guaranteed. cierta longitud para asegurarse de que todas las dem´as estaciones tambi´en detectan la In thecolisi´ idleostate, the node merely listens to the bus monitoring all traffic that passes. 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. se vuelve a transmitting colisionar, se having elegir´a recognised entre 8 valores, y se sigueof as´traffic. ı hasta Ifque tras the bus notSialso started the absence 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 eficiencia en caso de transmitting). Themanteniendo nodes will each a random before recommencing poco tr´afico, unawait cierta robusteztime en caso de un tr´afico elevado. Pese a ello, transmission. cuando hay varios usuarios intentando acceder a la red, la respuesta de CSMA/CD ante demandas de tr´afico que se acerquen a la capacidad nominal del canal es muy inestable MAC(empieza Frame Format a haber problemas de eficiencia 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 final que permite detectar errores en recepci´on. En caso de error, Ethernet no se encarga de retransmitir la trama This yfield consists ofla7 descarta. octets of the data pattern used simplemente 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 final 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 modificase 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 ) deonto 64 octetos a 512 octetos The OSI Network maps 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

APPLICATION

File Transfere

Electronic Mail

Terminal Emulation

PRESENTATION

File Transfer Protocol (FTP)

Simple Mail Transfer Protocol (SMTP)

TELNET Protocol

SESSION

MIL-STD 1780 RFC 959

MIL-STD 1781 RFC 821

MIL-STD 1782 RFC854

TRANSPORT

NETWORK

File Transfer

ARPA LAYER

Client/Server

Network Management

Sun Simple Network Trivial File Microsystems. Management Transfere Network file Protocol Protocol (TFTP) Systems (SNMP) Protocol (NFS)

RFC 783

RFC's 1014, 1057 & 1094

RFC 1157

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

Address Resolution ARP RFC 826 & RARP RFC 903

Internet Protocol (IP) MIL STD 1777 & RFC 791

PROCESS AND APPLICATION

RFC

Internet Control Message Protocol (ICMP) RFC 792

HOST TO HOST

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 the twoson models is depicted following figure. Los protocolosbetween de la pila TCP/IP los protocolos abiertosin m´athe 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 Figde6.paquete OSI vs.har´ ARPA Models Puede parecer que este tama˜ no m´ınimo a la red extremadamente ineficiente 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 TCP/IP, or rather- the TCP/IP Protocol Suite- is not limited to theMAC 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 fiable entre dos extremos, as´ı como control de flujo y de congesti´on. Se corresponde a la capa 4 (transporte) del modelo de referencia OSI. Para garantizar una transmisi´on fiable, 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 fiabilidad, control de flujo 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 predefinidos, como enteros, cadenas de caracteres, valores l´ogicos, etc., y hace posible definir tipos construidos como estructuras, listas, etc. Una de las principales razones del ´exito de ASN.12 es que su notaci´on est´a asociada con varios formatos de codificaci´on estandarizados. Estos formatos describen c´omo los valores definidos en ASN.1 deben ser codificados 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] 2

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 certificados digitales X.509, el protocolo IKE de intercambio de claves en IPsec, la informaci´ on de autentificaci´on de Kerberos, SNMP, UMTS, ZigBee, RDSI, sistemas RFID...

24

Cap´ıtulo 5 Introducci´ on a Foundation Fieldbus HSE FOUNDATION™ HSE for high availability at the host-level Plant Information Advanced Control Maintenance

Paper Scanner

Operation

Hub

Basic Control Safety Shutdown

Compressors Chromatograph

Figure 3 HSE integrates subsystems

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 an open standard. If not, special drivers are ultimately required to access the Elthat est´aisndar HSE es especialmente interesante para transmitir ficheros 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

5.1.

¿Por qu´ e Ethernet?

se dise˜ n´o el est´andar HSE se hizo un ´enfasis especial en utilizar componentes comerciales OSI Model standard off the shelf -, y en que se mantuviesen todas las funciones de H1. Concretamente, “User” HSEen HSE se siguen admitiendo transmisiones de dispositivo a dispositivo al igual que en H1, 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]. Network

UDP/IP

Al elegir componentes comerciales, podemos beneficiarnos de la econom´ıa de escala Data Link Ethernet

Physical

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

25

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

de este tipo de mercado: gracias a la masificaci´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´ıficamente 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 especificaciones 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´ıficamente para HSE. La capa de aplicaci´on de HSE contiene los protocolos DHCP (Dinamic Host Configuration 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 finalidad, se definen 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.

Beneficios de HSE

Adem´as de los mismos beneficios 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, identificaci´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 especificadas por HSE, por lo que funcionar´an de forma perfectamente integrada entre dispositivos de diferentes fabricantes. 1

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.

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 Off 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, fibra ´optica e inal´ambrico. Adem´as, en caso de ser necesaria una fiabilidad mayor que la conseguida mediante componentes comerciales est´andar (“de oficina”), 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´ıficas 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 Specification (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

smar

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

>

OSI MODEL*

FIELDBUS MODEL

USER APPLICATION

7

FIELDBUS ACCESS SUBLAYER

PRESENTATION LAYER

6

>

FIELDBUS MESSAGE SPECIFICATION

The Open System

SESSION LAYER

5

nect (OSI) layered

TRANSPORT LAYER

4

nications model.

NETWORK LAYER

3

>

APPLICATION LAYER

USER APPLICATION

DATA LINK LAYER

2

DATA LINK LAYER

PHYSICAL LAYER

1

PHYSICAL LAYER

COMMUNICATION “STACK”

PHYSICAL LAYER

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

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

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

cation Stack is6.1.1. comprised of layers 2 and 7 in the OSI model. Capa f´ısica

La capa f´ısica est´a definida en est´andares aprobados por la IEC (International Electrotechnical Commission) y la6.ISA Systems,(FAS) and Automation us does not use the OSI layers 3, 4, 5 and The (Instrumentation, Fieldbus Access Sublayer maps the Society, aunque se definen como International Society for Measurement and Control ). Las se˜ nales the DLL. H1 se codifican 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.

dispositivo transmisor env´ıa 10mA a 31.25kbps sobre una carga equivalente de 50Ω Application is notEldefined by the OSI model. The Fieldbus Foundation has specified a

para crear una tensi´on de 1Vpp modulada sobre la componente continua de alimentaci´on.

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

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´ ser´a lo of u ´nico porisel bus, y todos los r in the communication is caso, responsible for aonportion thetransmitido message that dispositivos necesitar´an una fuente de energ´ıa alternativa [MAC02].

ed on the fieldbus.

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 yofeleight dispositivo IS en used la zona H1tono est´a basado bers below show the approximate number bit “octets” forpeligrosa. each layer

he USER data. 30

USER APPLICATION

USER DATA

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

0 mA devices.

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 la capacidad bus,bus o apowered la potencia m´axima disponible para los s also supports safey (I.S.) fieldbusesdelwith devices. dispositivos.

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

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 reflexiones lo que se limita es la longitud total del cable.

r “spurs”. USER LAYER

COMMUNICATION “STACK”

> PHYSICAL LAYER

>> >

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

ption.

6.1.2.

Pila de comunicaciones

La capacidad que tienen los dispositivos FF de asumir funciones de control se basa en una comunicaci´on distribuida, que permite:

Ethernet

Cada dispositivo puede intercambiar datos directamente con otros dispositivos.

Todoskbit/s los dispositivos son make servidos a tiempo, de forma d to interconnect 31.25 fieldbuses and them accessible to a que los bucles de control tengan un rendimiento estable.

SE) backbone running at 100 Mbit/s or 1 Gbit/s. The I/O Subsystem Para que el comportamiento sea determinista, es necesario evitar las colisiones.

figure allows other networks such as DeviceNetâ and Profibusâ to be 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

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

Kbit/s fieldbus or1 HSE.

Fieldbus I.S. Concept, es un modelo de dise˜ no de buses de campo para zonas IS basado en reglas emp´ıricas.

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, configurando as´ı un sistema “plug and play”. Todas las tareas con dependencias temporales fuertes se realizan manteniendo una agenda estricta de transmisiones. Esta planificaci´on debe ser creada por el operador al configurar el sistema FF.

32

FF ofrece servicios de comunicaciones con transmisi´on de datos programada (planificada 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, configuraci´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 planificaciones 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 acceso al bus2 , ya que para asegurarse de que no haya colisiones, un dispositivo s´olo puede 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 final 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.

Especificaciones comunes

En la capa de Aplicaci´on de OSI, FF coloca dos de sus capas: la capa de especificaci´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 direc2

Es 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.

33

ci´on completa de una conexi´on, simplificando 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 significa 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 configuraci´on, asentimiento de alarmas, y transmisiones varias a los dispositivos. Report Distribution (Notificaci´on de eventos) Se utiliza para transmisiones encoladas, no programadas, de uno a muchos. Suele utilizarse para transmitir alarmas y notificaciones a las consolas de los operadores.

6.2.2.

Fieldbus Message Specification (FMS)

Los servicios de la capa de especificaci´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 definiciones de todos los formatos de mensaje est´andar, y tambi´en incluyen datos espec´ıficos de aplicaci´on. Para cada tipo de objeto hay servicios de comunicaciones predefinidos. Las descripciones de objeto se recopilan en un diccionario de objetos (Object Dictionary, OD). Se identifica 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 flotante, etc.). Las descripciones de objetos de las aplicaciones del usuario pueden empezar en cualquier ´ındice a partir del 255. 34

El FMS define 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 configurar 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 configurar 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 especificaciones 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 H1 HSE HSE Interface SMK LRE 1

NMA VFD OD HSE SMIB HSE NMIB

FBAP VFD H1 1 Interface N OD

FBAP VFD 1

D H C P

Field Device Access Agent

TCP

HSE Management Agent

OD

UDP

S N T P

S N M P HSE MIB

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 define una capa de usuario, donde se especifica la estructura y funcionamiento de los bloques funcionales, el modo de interconexi´on, etc.

6.3.1.

Especificaciones 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 especificaciones 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.

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.

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

3.6.1.4. Host Device (OPC DA server) Non-HSE devices capable of communicating with HSE devices. Examples include configurators and operator workstations.

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

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

24

FDA Agent - Agente FDA

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

Se define 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 Specification) 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 configurado 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]: Configurar 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 oficina, 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 especifican 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 especificar todas las capas necesarias, sea empleando est´andares ya existentes o proponiendo nuevos est´andares. Concretamente, es necesario especificar 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 especificaciones [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 ineficiente 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 modificarlo 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 el´ectricamente ruidosos [VER02]. Tambi´en existen hubs de categor´ıa industrial con fuentes de alimentaci´on redundantes, rangos de temperatura muy amplios, carcasas m´as robustas, etc [FF96]. Para aumentar la tolerancia al ruido el´ectrico y a diferencias de potencial entre las tierras, puede utilizarse fibra ´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´afico 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 especifica 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, notific´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 especifica 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 especifica c´omo se conmuta la funcionalidad, o c´omo se sincronizan los datos y la configuraci´on. Por supuesto, es imprescindible que en el momento de la conmutaci´on ambos dispositivos contuviesen la misma informaci´on y configuraci´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

Redundant single port Linking device

Single dual port Linking device

Secondary hub

Redundant dual port Linking device

Figure 10 Three types of redundancy

Por supuesto la mejor combinaci´on es la segunda, pero tambi´en es la m´as cara, y por The admite philosophy of thecombinaci´ HSE redundancy thatas, of en "operational transparency ello HSE cualquier on de ellas. isAdem´ 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. Every42 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

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 superficie 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´ on convencionales. ha demostrado ser realmente The specification of the FOUNDATION Fieldbus is not yet completed FISCO 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˜ nomany en papel Fieldbus model in aspects. [NEI02].

OUNDATION fieldbus

casospending se limita tambi´en la bycapacidad e sysinductancia TheEn IEC ambos fieldbus solves communication tasks using two bus

m´aximas del cable (y

por tanto suintrinsically longitudsafe m´aH1 xima). tems, the slow, bus and the fast, higher-level H2 bus with 1 to 2.5 MBit/s (see IEC fieldbus model /Lit. 4/).

Las redes Ethernet no fueron dise˜ nadas pensando en ninguna de estas normas, y por tanto no pueden ser adaptadas sin emplear The physical design of the H1 bus of the FOUNDATION dispositivos fieldbus compliesque no cumplan los requisitos de IEEE y por tanto no sean est´ andar, perdiendo as´ı las ventajas que ofrec´ıa exactly802.3u with the specifications of theque IEC fieldbus model. The specification of trabajar the H2 buscon is notEthernet. yet completed and the publication of the preliminary specification (PS) has been announced. However, it is certain that the High Speed

En 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 n

user 1

High Speed Ethernet (HSE)

switch

(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

Fig. 4: Structure of the FOUNDATION fieldbus

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

SAMSON AG ⋅ V74/ DKE

IEC 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 O’Neill, “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