ethernet industrial. protocolos e implementaciones de mercado

UNED. Escuela Técnica Superior de Ingenieros Industriales

Departamento de Ingeniería Eléctrica, Electrónica y de Control

Curso de Doctorado: Investigación en Tecnología Electrónica

Profesor del curso: Antonio Nevado Reviriego / Juan Manuel Martín Sánchez

Alumno: Ángel Paiz Farré, [email protected]

Curso: 2010 / 2011

Fecha: Septiembre de 2011

Revisión: 1

Informe sobre el estado de la técnica. ETHERNET INDUSTRIAL. PROTOCOLOS E

IMPLEMENTACIONES DE MERCADO Resumen – A pesar de su naturaleza no determinista, Ethernet está cada vez más presente en los sistemas de comunicaciones industriales, un ámbito reservado hasta hace pocos años a los tradicionales buses de campo. En este estudio, se profundizó en los fundamentos de Ethernet así como en las características adicionales de Ethernet Industrial, tanto desde el punto de vista teórico como de las implementaciones de mercado. Se realizó un análisis sistemático de la literatura académica, en primer lugar, y de la información técnica y comercial disponible en Internet, posteriormente. Los resultados constatan que no existe una única Ethernet Industrial, sino múltiples variantes incompatibles entre sí y con diferentes niveles de prestaciones respecto al comportamiento en tiempo real. Las variantes que introducen cambios más drásticos sobre Ethernet original son las que presentan mejor comportamiento en tiempo real. Palabras clave – Ethernet Industrial, Ethernet en Tiempo Real, Modbus TCP, Ethernet/IP, PROFINET, Ethernet Powerlink

Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.

2 de 143 Rev. 1

ÍNDICE: 1 Introducción................................................................................................................... 4

1.1 Objetivos................................................................................................................. 4 1.1.1 Objetivo académico ......................................................................................... 4 1.1.2 Objetivo técnico............................................................................................... 5

1.2 Abreviaturas ........................................................................................................... 8 2 Método......................................................................................................................... 10

2.1 Identificación de fuentes documentales en ingeniería.......................................... 10 2.2 Búsqueda y selección de artículos ........................................................................ 12

2.2.1 Selección de las fuentes documentales a consultar ....................................... 12 2.2.2 Búsqueda de artículos de revista académica.................................................. 13

a) Identificación de los elementos de búsqueda ............................................. 14 b) Definición del criterio de la búsqueda........................................................ 15 c) Ejecución de la búsqueda automática......................................................... 15 d) Exportación de los resultados al gestor de referencias bibliográficas ........ 18

2.2.3 Selección de artículos de revista académica.................................................. 18 a) Primera preselección................................................................................... 19 b) Segunda preselección ................................................................................. 20 c) Selección final ............................................................................................ 21

2.2.4 Actas de conferencia. Complemento a las revistas académicas .................... 21 2.3 Estudio de los artículos seleccionados.................................................................. 22 2.4 Búsqueda y selección de sitios Web y documentos on-line ................................. 22

2.4.1 Selección de las fuentes documentales a consultar ....................................... 22 2.4.2 Búsqueda de sitios Web y documentos on-line ............................................. 23 2.4.3 Selección de sitios Web y documentos on-line ............................................. 23

2.5 Estudio de los sitios Web y documentos on-line seleccionados........................... 24 3 Resultados.................................................................................................................... 25

3.1 Visión general....................................................................................................... 25 3.2 Ethernet Industrial ................................................................................................ 26

3.2.1 Background.................................................................................................... 26 a) Modelos de referencia ................................................................................ 26 b) Ethernet (IEEE 802.3) ................................................................................ 35 c) Switched Ethernet (IEEE 802.1) ................................................................ 47 d) LLC (IEEE 802.2) y la Subcapa Ethernet alternativa. ............................... 62 e) Protocolo IP y extensiones ......................................................................... 63 f) Protocolos TCP y UDP............................................................................... 65 g) Protocolos de aplicación TCP/IP................................................................ 66 h) Hardware .................................................................................................... 69

3.2.2 Salto evolutivo............................................................................................... 74 a) Introducción................................................................................................ 74 b) Modbus TCP............................................................................................... 77 c) EtherNet/IP ................................................................................................. 80 d) PROFINET CBA........................................................................................ 86

3.2.3 Productos de mercado.................................................................................... 88 3.3 Ethernet en Tiempo Real (RTE)........................................................................... 92

3.3.1 Background.................................................................................................... 93 a) Sincronización ............................................................................................ 93


3 de 143 Rev. 1

3.3.2 Salto evolutivo............................................................................................. 104 a) Introducción.............................................................................................. 104 b) Ethernet/IP con CIP Sync y CIP Motion.................................................. 106 c) PROFINET IO.......................................................................................... 107 d) EtherCAT ................................................................................................. 116 e) Ethernet Powerlink ................................................................................... 128

3.3.3 Productos de mercado.................................................................................. 131 4 Conclusiones.............................................................................................................. 134

4.1 Conclusiones de carácter académico .................................................................. 134 4.2 Conclusiones de carácter técnico........................................................................ 135

5 Referencias ................................................................................................................ 137 6 Anexos ....................................................................................................................... 143

6.1 Anexo I. Guía de fuentes documentales para la ingeniería ................................ 143 6.2 Anexo II. Búsqueda y selección de artículos...................................................... 143 6.3 Anexo III. Sitios Web analizados ....................................................................... 143


4 de 143 Rev. 1

1 Introducción El presente informe sobre el estado de la técnica forma parte de los trabajos llevados a

cabo por el autor en el marco del programa de doctorado denominado Sistemas de

Ingeniería Eléctrica, Electrónica y de Control, impartido por la UNED. Concretamente,

este informe se presenta con la pretensión de superar los créditos del Periodo de

Investigación correspondientes a dicho programa.

1.1 Objetivos

Dada la naturaleza de este documento, su finalidad tiene una doble vertiente, esto es:

académica, además de técnica. A continuación, se exponen ambas.

1.1.1 Objetivo académico

En la vertiente académica, el objetivo fundamental de este documento consiste en

acreditar la adquisición de las habilidades relacionadas con la elaboración de un

estudio sobre el estado de la técnica.

Un estudio sobre el estado de la técnica se puede entender de dos maneras distintas:

• Por un lado, puede formar parte de un proyecto más amplio, esto es, un trabajo

de investigación científica / técnica (I+D+i). En este caso, el estudio sobre el

estado de la técnica constituye la primera fase -de investigación secundaria1- que

establece los límites del conocimiento actual y sirve de base para una fase

posterior -de investigación primaria2- que pretende sobrepasar esos límites.

• Por otro lado, puede considerarse como una entidad en sí misma, es decir, un

trabajo que se limita a aplicar las técnicas de investigación secundaria con la

finalidad de obtener un informe sobre el estado de avance del conocimiento

científico / técnico actual en una determinada cuestión. En este caso, el estudio

puede tener otras motivaciones, como por ejemplo, evaluar la patentabilidad de

1 La investigación secundaria es aquella en la que los medios para acceder al conocimiento sobre una determinada realidad se limitan a la consulta de documentos ya elaborados por otros autores. Debido a la actual explosión en el volumen de la publicación científico-técnica, la investigación secundaria concede cada vez mayor importancia a las habilidades de Búsqueda Bibliográfica y Gestión del Conocimiento. 2 En la investigación primaria, el autor accede al conocimiento sobre una determinada realidad directamente, mediante la interacción / experimentación con dicha realidad, y no a través de los documentos de otros autores.


5 de 143 Rev. 1

un desarrollo ya realizado o tomar decisiones estratégicas sobre las líneas de

investigación a tomar en un determinado campo.

En cualquier caso, un estudio sobre el estado de la técnica es, básicamente, un ejercicio

de investigación secundaria. Es por ello que, en el estudio aquí expuesto, se estableció

como objetivo asimilar y aplicar los conceptos y las técnicas propios de la investigación

secundaria [1], [2], [3]. Así mismo, se pretendió poner en práctica las recomendaciones

de la literatura sobre redacción de informes de investigación [4]. Por último, a la hora de

generar y depurar las referencias bibliográficas se siguieron los criterios establecidos en

el manual de estilo editorial de IEEE [5].

1.1.2 Objetivo técnico

Dejando a un lado la dimensión académica, el objetivo principal de este estudio fue

profundizar en el conocimiento de una determinada cuestión técnica, como es

Ethernet Industrial. En el resto de este subapartado, se contextualizará dicha cuestión

técnica dentro de su área de conocimiento y se formulará qué lugar pretende ocupar en

ella el presente informe.

La Automatización Industrial se ha encargado durante décadas, mediante una

sucesión de mejoras incrementales, de aumentar la capacidad de producción de los

procesos industriales -tanto continuos como discretos- y de reducir los costes de

implementación de los sistemas de control que hacían posible dicha automatización.

Dentro de esta sucesión de mejoras incrementales, algunos de los hitos más importantes

han sido la introducción en la década de 1970 de los Controladores Lógicos

Programables (Programmable Logic Controller, PLC) -que sustituyeron los rígidos y

simples automatismos implementados mediante maniobras de relés por flexibles y

sofisticados automatismos programados- y la generalización en la década de 1990 de las

redes de comunicación digital –que sustituyeron cientos de cables de señal por unos

pocos cables de comunicaciones, mejorando al mismo tiempo las capacidades de

monitorización y autodiagnóstico del propio sistema de control (dispositivos de campo

inteligentes).


6 de 143 Rev. 1

La implementación de redes de comunicación digital en el ámbito de la

automatización industrial tuvo que realizarse teniendo en cuenta los requisitos

específicos del sector, que a menudo incluían comportamiento en tiempo real y

resistencia a un ambiente agresivo. Estas redes de comunicación digital específicas para

entornos industriales recibieron la denominación de buses de campo y han ido

evolucionando tecnológicamente hasta llegar a un estadio de madurez.

La tecnología de comunicación digital en el mundo de la ofimática ha seguido una

evolución paralela y separada a la de los buses de campo. Ethernet fue originalmente

diseñado en la década de 1980 con el objetivo concreto de comunicar un ordenador

personal con un nuevo modelo de impresora. Desde entonces, este protocolo ha ido

evolucionando en varios aspectos (tasa de transmisión, topología, medio físico) a

medida que la tecnología avanzaba y su uso se ha ido popularizando en el entorno para

el que fue diseñado. En esta evolución, Ethernet ha ido de la mano con otros protocolos

de nivel superior (IP y otros, en la capa de red; TCP y UDP, en la capa de transporte;

FTP, HTTP, SMTP, SNMP, etc., en la capa de aplicación) y juntos han constituido toda

una arquitectura (conocida como arquitectura TCP/IP) que se ha establecido como un

estándar de facto en el entorno ofimático.

Durante años, las empresas industriales han presenciado cómo coexistían ambos

mundos de una manera separada: Los profesionales de las Tecnologías de la

Información (TI) se encargaban de las redes ofimáticas y los sistemas ERP en las

oficinas, mientras que los ingenieros de control se encargaban de los buses de campo y

los sistemas de automatización en las plantas de producción.

Posteriormente, a principios de la década de 2000, los fabricantes líderes en el sector de

la Automatización Industrial lanzaron las primeras propuestas para introducir Ethernet y

la arquitectura TCP/IP también en las plantas de producción. Los argumentos utilizados

para justificar esta nueva generación de protocolos denominada Industrial Ethernet

eran la expectativa de una reducción de costes al aprovechar la producción masiva de

los controladores Ethernet estándar y la posibilidad de integrar de manera transparente

los niveles de campo de la planta industrial con los niveles superiores de las oficinas e

incluso con Internet.


7 de 143 Rev. 1

Sin embargo, en este sentido Ethernet presenta un problema: Una de sus características

esenciales –su mecanismo de control de acceso al medio, CSMA/CD- lo hace

claramente no determinista, de modo que es difícil justificar su idoneidad para

aplicaciones industriales, que habitualmente requieren comportamiento en tiempo real

[6]. Aun así, el interés técnico –o comercial– de hacer posible la utilización de Ethernet

en aplicaciones industriales con requerimientos de tiempo real suscitó una importante

actividad investigadora entorno al concepto de Real-Time Ethernet (RTE).

Bajo estas denominaciones –Industrial Ethernet y Real-Time Ethernet– han aparecido

múltiples propuestas de sistemas de comunicación industriales, que se basan en

Ethernet, para aprovechar sus puntos fuertes, e incorporan mecanismos adicionales, para

evitar en lo posible sus puntos débiles. La literatura técnica ofrece varios estudios

comparativos de dichas propuestas, centrados básicamente en las técnicas utilizadas

para conseguir el comportamiento en tiempo real [7]-[11]. También existen estudios

centrados en otros aspectos igualmente importantes para las aplicaciones industriales,

como son las técnicas de redundancia en infraestructuras de switched Ethernet [12]. Por

otra parte, los sitios Web de los fabricantes del sector de la Automatización Industrial

[13]-[25] ofrecen abundante información comercial y técnica sobre los productos

disponibles en el mercado.

Sin embargo, los estudios comparativos procedentes de la literatura con vocación de

imparcialidad (revistas académicas) a menudo se quedan en el terreno teórico y apenas

aportan información práctica sobre la disponibilidad de productos de mercado. Por otra

parte, la información proporcionada por los fabricantes tiende a ser sesgada y no facilita

la comparación objetiva de las prestaciones ofrecidas por los diferentes productos en

competencia.

El propósito del presente estudio fue obtener una visión panorámica de las variantes

de Ethernet Industrial más representativas, combinando al mismo tiempo información

sobre sus fundamentos teóricos (que permita juzgar sus capacidades de tiempo real) e

información práctica sobre los fabricantes que las soportan y las gamas de productos en

que se concretan. Los resultados de este estudio deberían ser útiles para aquellos

responsables que deban tomar decisiones sobre la tecnología de automatización a


8 de 143 Rev. 1

utilizar en una aplicación industrial, ya sea de proceso discreto (manufactura) o de

proceso continuo (química, farmacéutica, etc.).

1.2 Abreviaturas

ASIC (Application Specific Integrated Circuit) BPDU (Bridged Protocol Data Unit) CBA (Component Based Automation) CLRPC (Connectionless Remote Procedure Call) COTS (Commercial Of-The-Shelf) CSMA/CD (Carrier Sense Multiple Access / Collision Detection) DCE (Data Communication Equipment) DCOM (Distributed Component Object Model) DHCP (Dynamic Host Configuration Protocol) DTE (Data Terminal Equipment) EMI (Electromagnetic Interferences) FCS (Frame Check Sequence) FIFO (First In First Out) FMMU (Fieldbus Memory Management Unit) FPGA (Field Programmable Gate Array) FTP (File Transfer Protocol) HMI (Human Machine Interface) HTTP (Hipertext Transfer Protocol) I/O (Input / Output) LAN (Local Area Network) LLDP (Link Layer Discovery Protocol) MAN (Metropolitan Area Network) MIB (Management Information Base) MII (Media Independent Interface) MRP (Media Redundancy Protocol) MTU (Maximum Transfer Unit) NRT (Non-Real Time) NTP (Network Time Protocol) OUI (Organizationally Unique Identifier) PAN (Personal Area Network) PD (Powered Device) PDI (Process Data Interface) PDU (Protocol Data Unit) PLC (Programmable Logic Controllers) PoE (Power over Ethernet) PSE (Power Sourcing Equipment)


9 de 143 Rev. 1

PTP (Precision Time Protocol) RMII (Reduced Media Independent Interface) RPC (Remote Procedure Call) RSTP (Rapid Spanning Tree Protocol) RT (Real Time) SAI (Sistema de Alimentación Ininterrumpida) SAP (Service Access Point) SCADA (Supervisory Control And Data Acquisition) SDU (Service Data Unit) SMII (Serial Media Independent Interface) SNMP (Simple Network Management Protocol) SNTP (Simple Network Time Protocol) SoC (System-on-Chip) STP (Spanning Tree Protocol) TFTP (Trivial File Transfer Protocol) TTL (Time to Live) UTC (Universal Time Coordinated) VID (VLAN Identifier) VLAN (Virtual LAN)


10 de 143 Rev. 1

2 Método En condiciones habituales, un informe sobre el estado de la técnica se concentra

básicamente en exponer los resultados y conclusiones del trabajo de investigación

secundaria realizado sobre la cuestión técnica de interés, otorgando menor

protagonismo al método. Es evidente, sin embargo, que el método seguido durante la

investigación puede afectar a la calidad y validez de los resultados y las conclusiones.

De hecho, cuando se trata de informes sobre estudios experimentales (investigación

primaria) la ortodoxia académica [4] impone la necesidad de explicar minuciosamente

el método, para que otros investigadores puedan juzgar por sí mismos la validez de las

conclusiones e incluso, dado el caso, replicar la experimentación.

Es cierto que el presente informe no expone una investigación experimental sino

bibliográfica. Sin embargo, de acuerdo con el objetivo académico expuesto en el

subapartado 1.1.1, se consideró oportuno concebir, aplicar y documentar en esta sección

un cierto método a la hora de abordar la enorme cantidad de información disponible

sobre esta –y cualquier otra- cuestión técnica. Es de esperar que esta inversión en fijar

una metodología se pueda rentabilizar aplicándola también a otros trabajos de

investigación en el futuro.

2.1 Identificación de fuentes documentales en ingeniería

A la hora de captar el estado de la técnica sobre una determinada cuestión, existen

multitud de fuentes de información (documentos) a las que se puede recurrir. [1] las

clasifica en los siguientes tipos:

• Tratados / Manuales

• Monografías y compilaciones

• Normas

• Directorios

• Revistas académicas (journals)

• Actas de conferencia (conference proceedings)

• Tesis (doctoral dissertations y master thesis)


11 de 143 Rev. 1

• Patentes

Cada tipo de fuente de información tiene características diferenciales que conviene

conocer a la hora de seleccionarlo para realizar un estudio sobre el estado de la técnica.

Por ejemplo, para introducirse en un campo relativamente desconocido, es conveniente

comenzar estudiando los tratados o manuales, que contienen la información y la

terminología consolidada y están dirigidos a lectores no expertos. En cambio, para

analizar las fronteras del conocimiento en una cuestión concreta, son más adecuados

artículos publicados en revistas académicas (journals) de reconocido prestigio o en las

actas de conferencia (conference proceedings). Por otra parte, las patentes pueden

proporcionar información valiosa sobre el know-how de las empresas y sus decisiones

estratégicas en cuanto a su política de I+D+i.

Sin embargo, en la actualidad, el enorme volumen de información científica y técnica

generada hace inviable su lectura completa, incluso para una cuestión muy concreta [3].

En su lugar, es necesario acceder a dicha información de manera selectiva, apoyándose

en las fuentes documentales, que actualmente están informatizadas y son accesibles vía

Internet. Las fuentes documentales son instrumentos al servicio de la comunidad

científica que se alimentan de las fuentes de información (documentos publicados) y

generan una metainformación (información documental) con la intención de facilitar el

acceso selectivo a las fuentes de información relevantes.

A su vez, existen multitud de fuentes documentales, cada una de ellas con sus

características específicas. Los principales rasgos que las distinguen son:

• Las áreas de conocimiento que abarcan (química, medicina, ingeniería,

informática, etc.).

• Los tipos de fuentes de información que documentan (artículos, tesis, sitios

Web, patentes, etc.).

• El tipo de fuente documental (bibliografía, catálogo, índice analítico, índice de

citas, etc.), que viene dado por la naturaleza de la metainformación que

proporcionan (véase [1] para una clasificación detallada).


12 de 143 Rev. 1

• En el caso de los índices analíticos, son importantes las funcionalidades extra

que ofrecen, a parte de la búsqueda asistida mediante palabras clave y

operadores lógicos. Por ejemplo:

o Acceso a resúmenes (abstracts) de los documentos.

o Acceso al texto completo (full text) de los documentos.

o Capacidad de hacer un seguimiento de las citas, aguas arriba

(documentos anteriores citados por el documento en cuestión) y / o aguas

abajo (documentos posteriores que citan el documento en cuestión).

o Capacidad para guardar el criterio de búsqueda y eventualmente enviar

alertas por e-mail cuando se incorpora a la fuente documental un nueva

entrada que cumple con el criterio de búsqueda.

En el presente estudio, se estableció como paso previo el objetivo de familiarizarse con

las principales fuentes documentales en ingeniería. Así pues, se identificaron en [1], [3]

y [26] todas las referencias a fuentes documentales que pudieran tener relación con la

ingeniería y se visitaron los sitios Web correspondientes para averiguar las

características de cada una de ellas. Con la información recopilada, se confeccionó una

Guía de Fuentes Documentales en Ingeniería (véase Anexo I), con la pretensión de que

fuera útil no sólo para el presente estudio sino también para otros futuros, en cualquier

ámbito de la ingeniería.

2.2 Búsqueda y selección de artículos3

2.2.1 Selección de las fuentes documentales a consultar

En base al conocimiento adquirido durante la elaboración de la Guía de Fuentes

Documentales, se estableció una selección de las fuentes documentales que se

consideraron ideales para realizar la búsqueda de artículos sobre la cuestión técnica

objeto del estudio. Esta selección ideal estaba compuesta por:

• IEEE Xplore Digital Library [27].

• INSPEC [28]. 3 En el presente informe, se utiliza el término “artículo” como traducción del término “paper”, en inglés, y se entiende que engloba tanto los artículos de revistas académicas (journals) como los artículos de actas de conferencias (conference proceedings).


13 de 143 Rev. 1

• Current Contents Connect [29].

Sin embargo, existían ciertos condicionamientos prácticos que dificultaban la

utilización de las dos últimas fuentes documentales. Estos condicionamientos eran los

siguientes:

• No era posible acceder a ellas a través del acceso remoto de CiberUNED.

• Entre los servicios que prestaban, no estaba incluido el acceso al texto completo

de los documentos. Así pues, en caso de considerarse relevante para el estudio

una cierta referencia bibliográfica, sería necesario hacer la petición de una copia

del documento correspondiente en un centro de documentación y esperar la

recepción del mismo.

En consecuencia, se decidió establecer esta otra selección, que no presentaba ninguna de

las dificultades mencionadas:

• IEEE Xplore Digital Library

• ACM Digital Library [30].

• ScienceDirect [31].

A pesar de este cambio, la selección final se consideró suficientemente representativa,

debido a que las publicaciones englobadas por IEEExplore constituyen la fuente más

importante de información, por calidad y cantidad, en el área de conocimiento de la

ingeniería eléctrica, electrónica y de control.

2.2.2 Búsqueda de artículos de revista académica

Las fuentes documentales seleccionadas según se explica en el subapartado anterior son

índices analíticos. Esto significa que todas sus referencias bibliográficas están

indexadas, de manera que permiten la búsqueda automática en base a criterios

establecidos por el usuario sobre uno o más de los campos que las componen (título,

autor, palabras clave, etc.).


14 de 143 Rev. 1

Aunque esto supone una facilidad evidente para el proceso de investigación, la enorme

cantidad de información existente en cualquier ámbito científico / técnico hace que el

resultado de la búsqueda pueda diferir sensiblemente en función de cómo se realice

ésta. A continuación se expone el proceso seguido en el presente estudio para los

artículos de revista académica.

a) Identificación de los elementos de búsqueda

En primer lugar, se identificaron los elementos de búsqueda que se utilizarían al

ejecutar la búsqueda en las fuentes documentales seleccionadas. Los elementos de

búsqueda son términos (formados por una o más palabras) definidos por el usuario cuya

existencia en alguno de los campos de una referencia bibliográfica es tenida en cuenta a

la hora de decidir si esa referencia formará parte de los resultados de la búsqueda o no.

En general, se pueden utilizar como elementos de búsqueda:

• Autores.

• Organizaciones (centros de investigación, empresas,...).

• Publicaciones.

• Palabras clave.

• Etc.

Sin embargo, los tres primeros tipos de elementos de búsqueda requieren de un

conocimiento previo de cierta profundidad sobre la cuestión técnica, que en el presente

estudio no se quiso dar por supuesto. Así pues, la búsqueda se basó exclusivamente en

las palabras clave que se exponen a continuación.

Para delimitar el ámbito de búsqueda entorno al tecnología Ethernet, se utilizaron las

siguientes palabras clave:

• Ethernet.

• IEEE 802.34.

4 El protocolo Ethernet original, desarrollado por Xerox, es casi idéntico al reconocido en el estándar IEEE 802.3, de modo que pueden coexistir en el mismo medio. Así pues, en la práctica ambos términos se consideran como sinónimos.


15 de 143 Rev. 1

Para reducir el ámbito de búsqueda a las aplicaciones industriales y / o a las

aplicaciones en tiempo real, se utilizaron las siguientes palabras clave:

• Real-time

• Realtime

• Real time

• Industrial

b) Definición del criterio de la búsqueda

Básicamente, la definición del criterio de búsqueda consiste en combinar los elementos

de búsqueda mediante los operadores lógicos adecuados. En el presente estudio se

estableció un criterio de búsqueda basado en la siguiente combinación lógica:

("realtime" OR "real time" OR "real-time" OR "industrial")

AND

("ethernet" OR "IEEE 802.3")

Además, se enriqueció el criterio añadiendo una restricción para limitar los resultados a

los artículos de revista académica (journals), excluyendo los artículos de actas de

conferencias (conference proceedings), libros y otros.

c) Ejecución de la búsqueda automática

Aunque el criterio de búsqueda se puede establecer de manera general, a la hora de

ejecutar la búsqueda, se deben tener en cuenta las particularidades de cada fuente

documental. A continuación, se expone cómo se realizó la búsqueda en cada una de las

fuentes documentales seleccionadas, para conseguir resultados homogéneos.

En la IEEE Xplore Digital Library, se aplicaron los siguientes comandos de búsqueda

sobre la información bibliográfica (metadatos), no sobre el texto completo:


16 de 143 Rev. 1


AND


Mediante un refinamiento posterior, se seleccionaron sólo los documentos de tipo

journal. Realmente, IEEE Xplore incluye bajo este subapartado tanto documentos de

tipo journal propiamente dicho como de tipo transaction y magazine. IEEE Xplore no

permite discriminar entre ellos, al menos automáticamente. En definitiva, el total de

documentos encontrados en la IEEE Xplore Digital Library fue de 156 artículos.

En la ACM Digital Library, en un principio, se utilizaron los siguientes comandos de

búsqueda:


AND


AND

(PublishedAs:journal OR PublishedAs:transaction OR PublishedAs:magazine).

Como se puede observar, existe un tercer término que delimita el tipo de documento a

buscar. ACM Digital Library permite discriminar entre documentos de tipo journal,

transaction y magazine. Para tratar de que la búsqueda fuera equivalente a la de IEEE

Xplore Digital Library, se incluyeron todos ellos.

El resultado de esta búsqueda fue de 757 documentos. Sin embargo, al analizar la

información bibliográfica de las primeras referencias (título, resumen, etc.) se observó

que no eran relevantes para la búsqueda en cuestión. De hecho, las palabras clave no

aparecían en la información bibliográfica (metadatos). Para paliar esta disfunción, se

modificaron los comandos de búsqueda de la siguiente manera:

(Abstract:"realtime" OR Abstract:"real time" OR Abstract:"real-time" OR

Abstract:"industrial")

AND

(Abstract:"ethernet" OR Abstract:"IEEE 802.3")


17 de 143 Rev. 1

AND

(PublishedAs:journal OR PublishedAs:transaction OR PublishedAs:magazine)

Como se puede observar, las palabras claves se buscaron sólo en el campo Abstract y no

en el resto de la información bibliográfica. En teoría, esta modificación debería haber

reducido sólo levemente el número de resultados de la búsqueda, puesto que el Abstract

es el campo que tiene mayor extensión y suele repetir las palabras del título. En cambio,

lo que ocurrió en la práctica fue que disminuyó drásticamente a cuatro artículos, pero

esta vez sí eran relevantes.

Por último, en Science Direct, se aplicaron los siguientes comandos de búsqueda sobre

los campos Title, Abstract y Keywords:

(TITLE-ABSTR-KEY("realtime") OR TITLE-ABSTR-KEY("real time") OR TITLE-

ABSTR-KEY("real-time") OR TITLE-ABSTR-KEY("industrial"))

AND

(TITLE-ABSTR-KEY("ethernet") OR TITLE-ABSTR-KEY("IEEE 802.3"))

Además se impusieron los siguientes condicionantes:

• Tipo de fuente journal pero no book.

• Áreas de conocimiento Computer Science y Engineering.

• Tipo de documento Article y Review Article

Como resultado de la búsqueda, se obtuvieron como resultado 85 artículos.

En resumen, contabilizando las tres fuentes documentales, se encontraron un total de

245 artículos de revista académica. El hecho de que quede documentado exactamente

con qué comandos de búsqueda y con qué condicionantes extra se obtuvieron estos

resultados debe permitir la repetición de la búsqueda en el futuro y la detección de

nuevos artículos que eventualmente se publiquen sobre la cuestión. En el caso de IEEE

Xplore Digital Library, se guardó la búsqueda ejecutada y se activó una alerta

automática asociada a ella, de modo que automáticamente se generará un aviso por e-


18 de 143 Rev. 1

mail cuando se den de alta en su base de datos nuevas entradas que satisfagan la

búsqueda.

d) Exportación de los resultados al gestor de referencias bibliográficas

Los resultados de las búsquedas anteriores requerían un trabajo de análisis y selección

que, en principio, se podía hacer por separado, en las interfaces de usuario de cada una

de las tres fuentes documentales. Sin embargo, se consideró que era conveniente dar un

tratamiento uniforme a todas las referencias bibliográficas desde la fase más temprana

posible. Así pues, se exportaron los resultados de las tres búsquedas al gestor de

referencias bibliográficas RefWorks. Para ello se utilizaron formatos intermedios que

eran soportados, a la vez, por las funcionalidades de exportación de las fuentes

documentales y por las de importación de RefWorks. Concretamente, los formatos

intermedios utilizados fueron los siguientes:

• EndNote, para IEEE Xplore Digital Library.

• BibTex, para ACM Digital Library.

• RIS, para Science Direct.

Además, en todos los casos, se activó la opción de incluir en la exportación los

resúmenes (abstracts), con el objetivo de tener la máxima cantidad de información

posible para su posterior tratamiento. Finalmente, una vez en RefWorks, las 245

referencias bibliográficas fueron alojadas en una carpeta denominada IND-

ETH_PAPERS_SEARCH, que está disponible en Internet [32].

2.2.3 Selección de artículos de revista académica

El proceso de búsqueda expuesto en el subapartado anterior circunscribió la atención de

la investigación a un conjunto de artículos de revista académica que, de algún modo,

estaban relacionados con la cuestión técnica y descartó los que no tenían ninguna

conexión con ella. Es evidente que esta primera criba supuso un gran avance. Sin

embargo, el elevado número de artículos (245) hacía inviable en la práctica el estudio de

todos ellos.


19 de 143 Rev. 1

Así pues, se acometió un proceso de preselección con la intención de identificar los

artículos que podían ser de relevancia para la investigación, en base al análisis

exclusivamente de las referencias bibliográficas (incluyendo abstracts)5. Puesto que esa

información ya estaba disponible en el gestor de referencias bibliográfica, todo el

proceso de selección se llevó a cabo con la asistencia de tal gestor, sin necesidad de

recurrir a las fuentes documentales originales. A continuación se describen los pasos

seguidos.

a) Primera preselección

En el gestor de referencias bibliográficas RefWorks, se accedió a las 245 referencias

resultantes de la búsqueda, contenidas en la carpeta IND-ETH_PAPERS_SEARCH. La

visualización de las referencias se ordenó por “título de publicación”, con el fin de que

los documentos correspondientes a una misma publicación apareciesen de manera

contigua.

A continuación, se repasaron una a una las referencias bibliográficas –básicamente

títulos y resúmenes (abstracts)– con la finalidad de:

• Formarse una idea sobre el contenido de cada artículo y decidir si se incluía o

no en la preselección. Cuando se preseleccionaba una referencia, se editaba su

campo “Usuario1” para incluir un comentario personal sobre el contenido del

documento o su utilidad para el fin de la investigación. Además, la referencia en

cuestión se daba de alta adicionalmente en otra carpeta denominada IND-

ETH_PAPERS_PRESELEC, también disponible en Internet [33].

• Formarse una idea sobre la orientación de las diferentes publicaciones. En el

Anexo II, aparecen comentarios sobre la orientación de cada publicación y sobre

su relevancia para la investigación. También aparecen los detalles cuantitativos

referentes a la globalidad del proceso de búsqueda y selección de artículos.

5 Se decidió que no convenía recurrir al texto completo de los artículos para realizar la selección: Hacer esto de una manera homogénea y consistente para los 245 artículos era inviable, incluso leyendo “en diagonal”. En su lugar, se decidió confiar en que la lectura detenida de los títulos y los resúmenes (abstracts) proporcionaría información suficiente para seleccionar los artículos que convenía estudiar. Al fin y al cabo, esa es la razón de ser de los abstract.


20 de 143 Rev. 1

• Familiarizarse con la terminología y las palabras clave propias de la cuestión

técnica. Es evidente que las palabras clave nucleares en la cuestión bajo estudio

son Ethernet, Industrial, Real-Time,... Sin embargo, hay otras muchas palabras

clave que constituyen el mapa conceptual de la cuestión técnica y que, en

buena lógica, deberían aparecer en los abstracts de los artículos resultantes de la

búsqueda.

b) Segunda preselección

La primera preselección fue de carácter exhaustivo y manual. Para evitar que en ella se

hubiera descartado inadvertidamente algún artículo especialmente relevante para la

investigación, se realizó una segunda preselección, esta vez basada en las

funcionalidades de búsqueda automática proporcionadas por el propio gestor de

referencias. Así pues, se realizaron dos búsquedas circunscritas a la carpeta IND-

ETH_PAPERS_SEARCH, cada una de ellas con objetivos divergentes:

• La primera, para identificar los artículos de carácter general e integrador, que

podían facilitar una visión panorámica sobre la cuestión técnica, se ejecutó una

búsqueda con la siguientes palabras clave: Advances in, Progress in,

Perspective, Review, Overview.

• La segunda, para identificar los artículos que se concentraban en propuestas de

mercado concretas, se utilizaron como palabras clave las siguientes marcas

comerciales: EtherCAT, PROFINET, EtherNet/IP, Ethernet Powerlink.

Sobre los resultados de las búsquedas anteriores, se revisaron los títulos y resúmenes

para decidir qué referencias merecían ser añadidas a la preselección. Sin embargo, se

constató que todas las referencias que resultaron de este segundo proceso de

preselección ya habían sido identificadas en el primero. En definitiva, la carpeta IND-

ETH_PAPERS_PRESELEC resultó contener las referencias de 52 artículos de revista

académica.


21 de 143 Rev. 1

c) Selección final

La cantidad de artículos resultante de la preselección todavía era demasiado grande

como para abordar su análisis detallado, dentro de las pretensiones del presente estudio6.

Así pues, se estudiaron en detalle (por segunda vez) los títulos y resúmenes de las

referencias contenidas en IND-ETH_PAPERS_PRESELEC, con el objetivo de hacer la

selección final. En base al background obtenido durante el proceso de preselección, se

establecieron los diferentes aspectos que debía atender la selección final, a saber:

• Vista panorámica de las técnicas existentes para dotar a Ethernet de

comportamiento en tiempo real.

• Vista panorámica de las actividades de normalización en este ámbito.

• Monografías sobre protocolos que se han quedado en el ámbito experimental (p.

ej., Time-Triggered Ethernet).

• Monografías sobre protocolos que están disponibles en el mercado (p. ej.,

EtherCAT, PROFINET, EtherNet/IP, Ethernet Powerlink,...).

Las referencias de los 16 artículos de revista académica finalmente seleccionados se

dieron de alta adicionalmente en la carpeta de RefWorks denominada IND-

ETH_PAPERS_SELEC, que también está disponible en Internet [34].

2.2.4 Actas de conferencia. Complemento a las revistas académicas

Las actas de conferencia quedaron excluidas de la búsqueda en todo el proceso

explicado anteriormente. El motivo es que los artículos de actas de conferencia son más

cortos, menos ambiciosos, mucho más numerosos y no pasan por el proceso de filtrado

y revisión de las revistas académicas.

Sin embargo, en este punto de la investigación, se estimó oportuno complementar los

artículos de revista académica seleccionados con algunos artículos de acta de

6 Ante este argumento, cabe cuestionarse por qué no se planteó el proceso de preselección con criterios más estrictos para reducir más el número resultante. El motivo es que se consideró oportuno tener un “repositorio de materiales” identificados y comentados (campo “Usuario1”) que pudieran servir para alimentar una posible ampliación posterior del presente estudio. En definitiva, la idea clave es: IND-ETH_PAPERS_PRESELEC contiene los artículos relativos a la cuestión técnica que han suscitado algún interés en el autor e IND-ETH_PAPERS_SELEC contiene los artículos que se ha decidido analizar en profundidad para el presente estudio.


22 de 143 Rev. 1

conferencia. Para ello, se aprovechó el background adquirido en la fase anterior para

hacer búsquedas discrecionales directamente en las fuentes documentales. En total, se

seleccionaron 12 artículos de acta de conferencia, cuyas referencias se exportaron a

RefWorks y se añadieron directamente a la carpeta IND-ETH_PAPERS_SELEC, que

pasó a tener un total de 28 referencias, según se detalla en el Anexo II.

2.3 Estudio de los artículos seleccionados

Una vez seleccionados los artículos (tanto de revistas académicas como de actas de

conferencias) era necesario conseguir el texto completo de los artículos para estudiarlos

en profundidad. Puesto que las fuentes documentales consultadas tenían la prestación de

acceso al texto completo, sólo fue necesario volver a acceder a ellas para descargar los

artículos seleccionados. Si no hubieran tenido esta prestación, el camino a seguir habría

consistido en solicitar una copia de dichos artículos en un centro de documentación (por

ejemplo, una biblioteca de la UNED).

A continuación se procedió a la lectura detenida y análisis de los 28 artículos. Se

abordaron en primer lugar aquellos que proporcionaban una visión panorámica y

después aquellos que se concentraban en aspectos concretos. La información obtenida

de estos artículos se refería básicamente los fundamentos teóricos de los diferentes

protocolos y a las actividades de normalización sobre los mismos.

2.4 Búsqueda y selección de sitios Web y documentos on-line

2.4.1 Selección de las fuentes documentales a consultar

También existen fuentes documentales para la información contenida en sitios Web

(véase Anexo I). En este caso particular, sin embargo, la información que se pretendía

obtener mediante la consulta de sitios Web era referente a los principales fabricantes del

mercado y su gama actual de productos y, después de unos intentos preliminares, se

detectó que los resultados de búsquedas ejecutadas en estas fuentes documentales no

estaban especialmente enfocados hacia los productos de mercado sino más bien hacia

producción académica, que ya quedaba suficientemente cubierta por los artículos

estudiados en la fase anterior.


23 de 143 Rev. 1

Así pues, se optó por realizar la búsqueda de forma manual a partir de dos fuentes

documentales alternativas, a saber:

• Los apartados de referencias de los artículos estudiados anteriormente.

• El sitio Web IEB (Industrial Ethernet Book) [35]. Este sitio Web proporciona

información sobre una gran variedad de fabricantes relacionados con Ethernet

Industrial.

2.4.2 Búsqueda de sitios Web y documentos on-line

En primer lugar, a partir de las fuentes documentales alternativas, se identificaron los

sitios Web de las plataformas de estandarización de los principales protocolos de

Ethernet Industrial, así como los de los fabricantes que las promueven o se adhieren a

ellas. A continuación, se exploró el contenido de estos sitios Web, tanto los textos

HTML como los documentos accesibles desde ellos.

Como resultado de esta exploración, se obtuvo una idea sobre el interés de cada sitio

Web y se preseleccionaron los documentos de interés7. Tanto para los primeros como

para los segundos, se dieron de alta manualmente referencias en RefWorks (incluyendo

comentarios en el campo Usuario 1) en la carpeta IND-ETH_ONLINE_PRESELEC,

accesible desde Internet [36]. En total, se preseleccionaron 32 sitios Web y 61

documentos on-line.

2.4.3 Selección de sitios Web y documentos on-line

A diferencia de lo ocurrido con los artículos, en el caso de los sitios Web y documentos

on-line, la selección definitiva no se realizó en un punto concreto de la investigación,

sino que se utilizó la preselección como un repositorio de materiales del cual se

seleccionaban documentos para su estudio detallado a medida que se estimaba oportuno,

en el proceso de estudio. Aunque, en primera instancia, se pretendió utilizar estos

materiales solamente para obtener información sobre productos de mercado y

fabricantes, se observó que también existían documentos con contenido riguroso sobre 7 Al igual que ocurrió con la preselección de artículos, en esta preselección se incluyeron aquellos sitios Web y documentos on-line que se consideraron de posible interés no sólo para el presente estudio sino para eventuales ampliaciones que se pudieran plantear en el futuro.


24 de 143 Rev. 1

los fundamentos teóricos de los diferentes protocolos, que ayudaban a interpretar el

contenido de los artículos.

Las referencias de los sitios Web y documentos on-line finalmente seleccionado para su

estudio en mayor profundidad se dieron de alta adicionalmente en RefWorks, en la

carpeta IND-ETH_ONLINE_SELEC, accesible desde Internet [37]. En total, se

seleccionaron 23 sitios Web y 29 documentos on-line. El Anexo III resume el proceso

de preselección y selección. También aporta información orientativa sobre el contenido

los sitios Web.

2.5 Estudio de los sitios Web y documentos on-line

seleccionados

El estudio de los sitios Web y documentos on-line seleccionados permitió obtener

información sobre productos de mercado. Además, también permitió solucionar lagunas

sobre aspectos básicos de la cuestión técnica que, aunque eran mencionados en los

artículos, no se desarrollaban suficientemente profundidad. Especialmente útiles, en este

sentido, fueron los sitios Web de IETF [38], de IEEE [39] y de InES [40].


25 de 143 Rev. 1

3 Resultados

3.1 Visión general

En esta sección, se expondrán los resultados del estudio realizado. Es decir, se intentará

presentar de manera organizada y objetiva la información obtenida a través del método

de investigación detallado en la sección anterior. Todo el cuerpo de información

mencionado gira entorno a tres conceptos claves: Ethernet, Ethernet Industrial y

Ethernet en Tiempo Real. A continuación, se tratará establecer las relaciones entre ellos.

Ethernet es una tecnología de comunicación que ha ido adoptando formas diferentes a

lo largo del tiempo, pero que, sin embargo ha mantenido una coherencia

(compatibilidad) entre todas ellas, a medida que evolucionaba. Así pues, se podría

decir que solamente existe “una Ethernet” y es la que está especificada en la norma

IEEE 802.3. Además, cuando se habla de Ethernet a secas, normalmente se da por

supuesto que se utiliza en un entorno ofimático y en conjunción con la arquitectura

TCP/IP.

Ethernet Industrial es una expresión que denota una multiplicidad de propuestas

(incompatibles entre sí) que, partiendo como base de Ethernet (IEEE 802.3), pretenden

adaptarse a las necesidades de aplicaciones industriales. Frecuentemente, estas

necesidades incluyen la robustez ante ambientes agresivos y el comportamiento en

tiempo real. Sin embargo, no todas las propuestas de Ethernet Industrial presentan

comportamiento en tiempo real.

Ethernet en Tiempo Real también denota una multiplicidad de propuestas

(incompatibles entre sí) que modifican la manera habitual de utilizar Ethernet (esto es, a

través de la arquitectura TCP/IP) y/o incluso su propia esencia (capa física y capa

MAC) para conseguir un comportamiento en tiempo real. En este informe, cuando se

utiliza la expresión “Ethernet en Tiempo Real”, se hace referencia a su uso en

aplicaciones industriales.

Existe una clara secuencia cronológica en la aparición de los tres conceptos: Ethernet es

el concepto original, que apareció en la década de 1980. Ethernet Industrial apareció a


26 de 143 Rev. 1

principios de la década de 2000. Finalmente, Ethernet en Tiempo Real apareció más

recientemente, para dar respuesta a los requisitos temporales más exigentes de las


3.2 Ethernet Industrial

En este apartado se desarrollará el concepto de Ethernet Industrial. Para ello, se

organizará el texto de la siguiente manera.

En el subapartado de Background, se tratarán los fundamentos de la tecnología previa a

Ethernet Industrial. Esto incluye los diferentes modelos de referencia para los sistemas

de comunicación, Ethernet, los protocolos de capas superiores y aspectos referentes a

las implementaciones en hardware. Estos fundamentos son necesarios para comprender

qué novedades son las que aportan las propuestas de Ethernet Industrial.

En el subapartado de Salto evolutivo, se repasarán las principales características de las

propuestas de Ethernet Industrial, explicando cómo utilizan las posibilidades que ofrece

la tecnología existente y qué funcionalidades aportan.

Por último, en el subapartado Productos de mercado, se repasarán los principales

fabricantes de cada propuesta de Ethernet Industrial y las gamas de productos

correspondientes disponibles comercialmente. También se indicarán los tipos de

comunicación a los que van principalmente dirigida cada propuesta y algunos aspectos

sobre su posicionamiento estratégico en el mercado.

3.2.1 Background

a) Modelos de referencia

Modelo de referencia OSI La interconexión de sistemas informáticos requiere la resolución de gran cantidad de

aspectos, desde los niveles de tensión que puede adoptar la señal propagada por el

medio de comunicación hasta los mecanismos previstos para encriptar la información

transmitida, por ejemplo. En 1984, fue publicada la primera edición de la norma


27 de 143 Rev. 1

ISO/IEC 7498-1 y en 1994 la segunda y última edición, que sigue vigente en la

actualidad y que ha servido durante todo este tiempo para facilitar el desarrollo de

diferentes normas sobre interconexión de sistemas informáticos. Esta norma define el

Modelo de Referencia Básico para la Interconexión de Sistemas Abiertos, normalmente

conocido como Modelo de referencia OSI, que organiza la gran variedad de funciones

involucradas en una estructura de siete capas funcionales o niveles de abstracción.

Fig. 1. Modelo de referencia OSI

Ambos sistemas a interconectar (hosts) deben implementar las siete capas funcionales

con el objetivo de conseguir que los procesos de aplicación (aplicaciones de usuario)

que se ejecutan a ambos lados de la conexión puedan comunicarse de manera

transparente, es decir, simplemente sirviéndose de los servicios proporcionados por la

capa inmediatamente inferior (capa de aplicación) .y sin ser conscientes de las funciones

realizadas en el resto de capas inferiores. Para ello, las capas de aplicación de ambos

lados de la conexión se comunican entre ellas siguiendo unas ciertas reglas (protocolo

de aplicación) sirviéndose a su vez de los servicios proporcionados por la capa

inmediatamente inferior (capa de presentación). Este esquema se repite sucesivamente

hasta llegar a la capa física que se sirve de los transceptores y el medio físico para

transmitir los bits entre ambos hosts.


28 de 143 Rev. 1

Cada capa, para realizar sus funciones, requiere un tráfico de datos de control entre

ambos lados de la conexión, representado en la Fig. 1 por las flechas horizontales. Este

tráfico es tratado por las capas inferiores del mismo modo que el tráfico procedente de

los procesos de aplicación, esto es, como datos de usuario. Sin embargo, para las capas

superiores a la capa en cuestión, este tráfico es simplemente “invisible”.

Tanto el tráfico originado en una capa del modelo OSI (datos de control) como el tráfico

originado en los procesos de aplicación (datos de aplicación) sigue en el host emisor un

camino descendente a lo largo de las capas hasta alcanzar el medio de transmisión y,

una vez recibido en el host receptor un camino ascendente hasta llegar a la capa donde

se originó (datos de control) o bien al propio proceso de aplicación (datos de

aplicación). Esta otra manera de entender el tráfico es representada en la Fig. 1 mediante

las flechas verticales.

En el camino descendente del proceso de emisión, cada capa acoge la información

procedente de la capa superior como unos “datos de usuario” cuyos significado y

formato no es necesario conocer. Estos datos de usuario son encapsulados en una

“envoltura” (marcada en verde en la Fig. 2) con un formato específico de la capa, que

añade la información necesaria para que la capa pueda realizar sus funciones en el host

receptor.

Fig. 2. Proceso de encapsulación y desencapsulación

En el camino ascendente del proceso de recepción, cada capa utiliza la información de

la envoltura (cuyo formato conoce) para realizar sus funciones y entrega los datos de

usuario (cuyo formato desconoce) a la capa superior. De este modo, las sucesivas


29 de 143 Rev. 1

envolturas se van utilizando y desechando en el camino ascendente, hasta llegar al

propio proceso de aplicación.

A continuación se expone brevemente las funciones asignadas a cada una de las siete

capas del modelo de referencia OSI:

• Capa física. Define las características mecánicas (conectores y cables), físicas

(niveles de tensión, velocidades de transmisión,...) y funcionales (definición de

señales) de un enlace físico. Su función básica consiste en proporcionar un canal

de comunicaciones a la capa superior. Para ello, realiza la codificación y

señalización de los bits, la sincronización de emisor y receptor, la señalización /

detección del inicio y el fin de la transmisión, etc.

• Capa de enlace de datos. Su función básica consiste en mantener la

integridad de los datos de una transmisión no exenta de ruido. Para ello, arbitra

el acceso al medio físico de los diferentes participantes que comparten un mismo

dominio de acceso, se atiene a un formato de trama preestablecido y realiza

operaciones de detección y recuperación de errores de transmisión y otras

anomalías que pueden ocurrir en la capa física.

• Capa de red. Su función básica consiste en realizar el encaminamiento, es

decir, tomar la decisión sobre la sucesión óptima de nodos que debe recorrer

cada paquete de información, dentro de una red de conmutación de paquetes.

Esta decisión se evalúa en cada momento para evitar las zonas más

congestionadas de la red y, por tanto, dos paquetes con el mismo emisor y

receptor pueden seguir caminos diferentes.

• Capa de transporte. Su función principal consiste en establecer una conexión

punto a punto de naturaleza lógica entre dos sistemas finales conectados a la

red, asegurando que todos los paquetes tratados por la capa de red llegan al

receptor y, además, lo hacen en el mismo orden en que fueron transmitidos. Por

otra parte, si la información procedente de la capa superior viene en unidades

demasiado grandes, se encarga de fragmentarla en unidades más pequeñas para

que puedan ser tratadas por las capas inferiores a la hora de transmitirla. En la


30 de 143 Rev. 1

recepción, esta misma capa se encarga de reconstruir la información a partir de

los fragmentos para hacerla llegar a la capa superior de un modo transparente.

• Capa de sesión. Gestiona el establecimiento y la liberación de una sesión

solicitada por el usuario, así como el intercambio de datos durante su

existencia.

• Capa de presentación. Su función básica consiste en asegurar la compatibilidad

entre los sistemas de representación heterogéneos que pueden encontrarse en los

sistemas finales. Para ello, realiza las funciones de conversión de códigos (de

números, caracteres, etc.) necesarias. También puede encargarse de tareas de

encriptación / desencriptación para asegurar la seguridad de la transmisión.

• Capa de aplicación. Su función consiste en permitir, dentro de una aplicación

distribuida, la comunicación entre los procesos de aplicación residentes en los

diferentes sistemas interconectados. Para ello, proporciona una variedad de

servicios, como la transferencia de ficheros, el terminal virtual, la transferencia

de correo electrónico, etc.

Según sea la distancia geográfica existente entre los dos sistemas a interconectar, el

número y el tipo de dispositivos intermedios de comunicación involucrados será

diferente. Aunque los sistemas finales deben implementar obligatoriamente las siete

capas, los dispositivos intermedios de comunicación sólo deben implementar las capas

inferiores. El modelo OSI prevé que estos dispositivos podrán ser de tres tipos, según el

número de capas que implementen (véase zona azul en la Fig. 1):

• Si sólo implementan la capa física, servirán únicamente para extender el medio

de transmisión, asegurando el enlace físico. En este caso se denominan

repetidores (repeaters).

• Si implementan la capa física y la de enlace de datos, servirán conectar dominios

de acceso diferentes dentro de una red, asegurando el enlace lógico de datos. En

ese caso se denominan puentes (bridges).

• Si implementan las tres capas inferiores (incluida la de red), servirán para unir

redes diferentes, asegurando la función de encaminamiento. En este caso se

denominan encaminadores (routers).


31 de 143 Rev. 1

La pretensión del modelo de referencia OSI no era servir como una especificación de

implementación sino como referencia para:

• Definir una terminología común en el campo de la interconexión de sistemas

informáticos, aplicable en todos los posibles ámbitos: Tanto para aplicaciones

ofimáticas como industriales, tanto para ámbitos geográficos limitados como

amplios, etc.

• Establecer un marco apropiado para facilitar el desarrollo y la mejora de otras

normas (de implementación), facilitando así un mayor grado de

interoperabilidad.

• Ayudar a comprender las relaciones entre dichas normas.

Así, por ejemplo, la especificación Ethernet se puede situar en perspectiva gracias al

modelo de referencia OSI, advirtiendo que las funciones que define están ubicadas en

las capas física y de enlace de datos. Igualmente ocurre con otras especificaciones

tradicionalmente consideradas como buses de campo industriales (CAN, Modbus RS-

485, etc.): También ellas se circunscriben a las capas físicas y de enlace de datos.

Modelo de referencia IEEE 802 La especificación Ethernet, sin embargo, cuando la institución IEEE se hizo cargo de su

mantenimiento substituyendo a su creadora original (Xerox), quedó circunscrita dentro

de otro modelo de referencia, definido por IEEE para organizar sus trabajos de

normalización en un ámbito mucho más amplio. Se trata del modelo de referencia IEEE

802 [41] para LANs y MANs. Aun así, el proyecto de normalización 802 de IEEE

reconoce la utilidad del modelo de referencia OSI y establece la correspondencia

existente con el suyo propio en la Fig. 3.


32 de 143 Rev. 1

Fig. 3. Modelo IEEE 802 vs. modelo ISO

Las características más importantes del modelo de referencia IEEE 802 son las

siguientes:

• Limita su alcance a las dos capas inferiores del modelo de referencia OSI, es

decir, no prevé la implementación de routers.

• Desglosa la capa de enlace de datos del modelo OSI en dos subcapas:

o Subcapa LLC (Logical Link Control)

o Subcapa MAC (Medium Access Control)

A partir de este modelo de referencia, el proyecto de normalización IEEE 802 ha

definido diferentes tecnologías de redes LAN, MAN y PAN cuyas características clave

son:

• Orientación a ámbitos geográficos restringidos. En el caso de las LANs, hasta 2

km de extensión, adecuado para un edificio de oficinas o un campus.

• Estilo de comunicación está basado en paquetes, caracterizado por unidades de

información de longitud variable, con límites máximos superiores a 1000 octetos

y transmisión disparada por eventos (no por tiempo).

• Posibilidad de diferentes tipos de direccionamiento: unicast, multicast y

broadcast.

En la Fig. 4, se ilustra la situación de estas tecnologías dentro del marco global del

proyecto IEEE 802.


33 de 143 Rev. 1

Fig. 4. Panorámica del proyecto de normalización IEEE 802

Cada tecnología concreta abarca la capa física (PHY) y la subcapa de Control de Acceso

al Medio (MAC) y sus diversas implementaciones quedan especificadas en una norma

particular. A continuación se muestra una lista no exhaustiva de las normas y las

tecnologías correspondientes:

• IEEE 802.3: CSMA/CD (Ethernet).

• IEEE 802.5: Token ring.

• IEEE 802.11: Wireless LAN (WI-FI).

• IEEE 802.15: Wireless PAN

• IEEE 802.15.1: Bluetooth.

• IEEE 802.15.4: Zigbee.

• IEEE 802.16: Broadband Wireless Access (WiMAX)

Otras normas del proyecto tienen carácter transversal y aplican a todas las tecnologías.

Las más destacadas son:

• IEEE 802.1: Bridging y Management. Especifica la implementación de puentes

(bridges) que pueden comunicar diferentes dominios de acceso de una misma

tecnología o de tecnologías diferentes. También trata el tema de la gestión

remota (management) de los dispositivos que incorporan estas tecnologías.

• IEEE 802.2: Logical Link Control (LLC). Especifica la subcapa LLC que, junto

con la subcapa MAC, completa el conjunto de funcionalidades propias de la


34 de 143 Rev. 1

capa de enlace de datos del modelo de referencia OSI. Esta especificación, a

diferencia de la de la subcapa MAC, es única y común para todas las

tecnologías.

Modelo TCP/IP El modelo TCP/IP surgió como resultado de proyectos de investigación militar del DoD

(Department of Defence) de E.E.U.U. La primera noción del modelo TCP/IP como tal

aparece en 1991 en el RFC 1180 [42] y ha sido posteriormente evolucionada por

multitud de RFCs publicados por la IETF [38]. A diferencia del modelo IEEE 802,

estaba orientado a un ámbito geográfico global (continental o planetario). Es por eso

que dicho modelo pone el énfasis en las capas de red y de transporte y simplifica el

resto de capas del modelo de referencia OSI fusionándolas en las capas de aplicación y

de acceso a red, según se muestra en la Fig. 5.

OSI TCP/IP IEEE 802

Aplicación

Presentación

Sesión

Aplicación

Transporte Transporte

Red Red

Capas

superiores

(fuera de

alcance)

LLC Enlace de datos

MAC

Física

Acceso a red

(fuera de

alcance)8 PHY

Fig. 5. Correspondencia entre modelos OSI, TCP/IP e IEEE 802.

Como se puede observar, los modelos TCP/IP e IEEE 802 son complementarios y

abarcan todas las funciones necesarias para permitir la interconexión entre sistemas

abiertos establecidas por el modelo OSI. En efecto, las tecnologías IEEE 802 (sobre

todo Ethernet) se han convertido en las predominantes en el ámbito de las redes LAN

para uso corporativo y doméstico. Por otra parte, el modelo TCP/IP es el que se ha

8 Es cierto que en el RFC 1180 se menciona Ethernet como protocolo para la capa de acceso a red. Sin embargo, el foco de modelo TCP/IP está en las capas superiores.


35 de 143 Rev. 1

adoptado unánimemente para construir la infraestructura publica de telecomunicaciones

(Internet) que permite conectar esas LANs entre sí.

b) Ethernet (IEEE 802.3) En la actualidad, la tecnología Ethernet queda especificada por la norma IEEE 802.3

[43]-[47], que fue revisada por última vez en 2008. La norma recopila todas las

implementaciones, tanto las primeras –que ya están totalmente en desuso– como las más

recientes. La evolución en las implementaciones se debe a la adopción de los avances

tecnológicos y afectan básicamente a las especificaciones de la capa física (PHY). La

subcapa MAC en cambio se ha mantenido esencialmente invariable a lo largo del

tiempo.

Capa física (PHY) A continuación, se enumeran algunas de las implementaciones históricamente más

relevantes y los parámetros esenciales de sus capas físicas.

10BASE5 (Thick Ethernet)

• Topología en bus.

• Cable coaxial grueso con resistencias terminales

• Modo half duplex.

• Transceptores insertados en el cable para conectar las estaciones finales a la red.

• Tasa de transferencia: 10 Mbps.

• Modulación: Banda base.

• Longitud máxima del segmento (sin repetidores): 500 m.

10BASE2 (Thin Ethernet)

• Topología en bus.

• Cable coaxial fino con resistencias terminales

• Modo half duplex.

• Conectores tipo BNC en forma de “T”, para conectar las estaciones finales a la

red.

• Tasa de transferencia: 10 Mbps



36 de 143 Rev. 1


10BASE-T (Ethernet over Twisted Pair)

• Topología punto a punto o bien en estrella: Cada estación final se conecta punto

a punto con un dispositivo intermedio de comunicación (repetidor o puente)

multipuerto.

• Cable de par trenzado de 4 pares (sólo se utilizan 2), de sección 26 AWG a 22

AWG .

• Permite modo half duplex, full duplex o ambos.

• Conectores RJ-45.




100BASE-TX (Fast Ethernet over Twisted Pair)

• Topología punto a punto o bien en estrella.

• Cable de par trenzado de 4 pares (se utilizan sólo 2) sin apantallar (UTP) Cat5.

También se permite cable apantallado STP.




• Autonegociación (opcional): Permite adaptarse automáticamente a 10 Mbps para

proporcionar compatibilidad con 10BASE-T.



1000BASE-T (Gigabit Ethernet over Twisted Pair)


• Cable de par trenzado de 4 pares (se utilizan los 4) sin apantallar (UTP) Cat5.

• Full duplex (cada par se utiliza para transmitir en las dos direcciones

simultáneamente).




37 de 143 Rev. 1

• Autonegociación: Permite adaptarse automáticamente a 10 Mbps para

proporcionar compatibilidad con 10BASE-T y 100BASE-TX.

• Modulación: Banda base, pero utiliza cuatro niveles de tensión para codificar 2

bits en cada pulso de reloj.


Implementaciones para fibra óptica 10BASE-F, 100BASE-FX, 1000BASE-X


• Cableado: cada enlace físico requiere dos fibras: una para transmisión y otra

para recepción.


• Tasa de transferencia: 10, 100 y 1000 Mbps


• Longitud máxima del segmento: Superiores a las conseguidas en cobre.

Recientemente, se han especificado capas físicas para tasas de trasmisión de 10 Gbps,

mayoritariamente para fibra óptica, pero también para cable de cobre de altas

prestaciones. En todo caso, para el objetivo del presente estudio, la implementación

más interesante es la 100BASE-TX, dado que es la que ha sido adoptada como base

para la mayoría de las propuestas de Ethernet Industrial. Así pues, a continuación

se describen detalles adicionales de esta implementación.

La capa física 100BASE-TX acepta dos tipos de cableado: El basado en pares trenzados

apantallados (STP) de 150 Ohm y el basado en pares trenzados sin apantallar (UTP) de

100 Ohm. Este último es el que se ha utilizado con mayor frecuencia en la práctica y

consta de cuatro pares, de los cuales sólo se utilizan dos: uno para transmitir y otro para

recibir.

Para minimizar la susceptibilidad a las interferencias electromagnéticas, cada par está

trenzado y balanceado. Esto último significa que la señal transmitida por un hilo del par

se transmite por el otro hilo del par en modo invertido respecto del potencial de

referencia del transmisor, tal como se muestra en la Fig. 6.


38 de 143 Rev. 1

Fig. 6. Transmisión balanceada.

El potencial de referencia del receptor puede estar desplazado respecto del del

transmisor sin que ello afecte a la interpretación de la señal, que se toma como la

tensión diferencial entre ambos hilos.

A la hora de realizar un enlace físico, los ocho hilos (incluso los no usados) se deben

conectar en el conector RJ-45 siguiendo las asignaciones de la Tabla 1.

Tabla 1. Definición de señales y asignación a contactos.

Para denotar la pertenencia de dos hilos al mismo par, se utiliza en ambos el mismo

color. Por ejemplo, el hilo verde y el verde-blanco pertenecen al mismo par. Si se utiliza

la asignación de contactos de la Tabla 1 en ambos extremos, se obtiene un cable directo

(straight-through). Este tipo de cables es adecuado para conectar un equipo DTE (por

ejemplo, un ordenador) con un equipo DCE (por ejemplo, un puente). Esto es debido a

que el equipo DCE tiene implementado en su interior la función de cruzado (crossover),

que consiste en conectar los contactos +TD y –TD del conector a las señales +RD y –

RD de su electrónica (simétricamente para los contactos +RD y –RD). Por el contrario,

cuando se quiere conectar dos equipos de la misma naturaleza (por ejemplo, dos

ordenadores o dos puentes) es necesario realizar un cable cruzado (crossover) para


39 de 143 Rev. 1

mantener el principio de que la señal transmitida desde un extremo tiene que llegar al

receptor en el otro extremo y viceversa. La Fig. 7 ilustra los dos tipos de cable posibles.

Fig. 7. Asignación a contactos de cable directo y cruzado.

Aunque la especificación de 100BASE-TX no lo requiere, hay equipos comerciales que

implementan la función Auto-crossover, es decir, que detectan cómo están conectados

los pares y realizan automáticamente la función crossover según sea necesario. En este

caso, cualquier tipo de cable (cruzado o directo) funcionaría correctamente.

La norma IEEE 802.3 prevé una funcionalidad opcional para la capa física 100BASE-

TX (y también para la 10BASE-T y la 1000BASE-T) denominada Power over Ethernet

(PoE), que consiste en usar el mismo cable UTP como cable de alimentación. De este

modo, estaciones finales de poco consumo como puntos de acceso WLAN o teléfonos

IP pueden alimentarse directamente desde los dispositivos intermedios de

comunicaciones (hubs / switches) siempre y cuando esté implementada esta opción a

ambos lados del cable UTP.

La norma define dos elementos clave: el PSE (Power Sourcing Equipment) y el PD

(Powered Device). El PSE puede ser de tipo endpoint (típicamente un switch

compatible con PoE) o bien de tipo midspan (conocido como inyector PoE), que se

inserta en un punto intermedio entre el switch convencional y la estación final

compatible con PoE. En cualquier caso, el PSE debe ser capaz de entregar una tensión

nominal de 48 Vdc (entre 44 y 57 Vdc) y una corriente máxima de 350 mA para 44 Vdc

(15,4 W).


40 de 143 Rev. 1

Por su parte, el PD debe ser capaz de funcionar en un rango de tensiones entre 36 y 57

Vdc sin consumir más de 12,95 W. El margen hasta la potencia entregada por el PSE se

deja en previsión de las pérdidas en el cable UTP. Además, debe implementar la función

de auto-polaridad, de manera que funcione correctamente incluso si hay una inversión

respecto a lo previsto en la norma.

En cuanto a los conductores utilizados para transmitir la potencia, la norma prevé dos

alternativas (A y B). En general, a los PSE se les permite implementar sólo la

alternativa A, sólo la B o bien ambas (aunque no deben activarse ambas

simultáneamente)9. En cambio, los PD deben implementar ambas alternativas de

manera que se puedan alimentar indistintamente a través de cualquiera de ellas10.

La alternativa A consiste en utilizar los pares de datos para transmitir la potencia. Para

ello, se aplica una tensión continua entre los puntos medios de los devanados exteriores

de los transformadores existentes a la salida de los pares 1-2 y 3-6 en el PSE, tal como

muestra la Fig. 8. En el PD, se recibirá la misma tensión (excepto por las caídas en el

cable UTP) en los puntos medios de los devanados exteriores de los transformadores.

La corriente de alimentación (continua) podrá fluir repartiéndose por los dos hilos de un

par para alimentar el PD y retornar a la fuente de alimentación del PSE repartiéndose

por los dos hilos del otro par sin afectar por ello a la señal en modo diferencial (bits)

que fluye por cada uno de los pares.

Fig. 8. PoE. Alternativa A para PSE de tipo endpoint.

9 Los inyectores PoE (midspan PSE) sólo implementan la alternativa B. 10 Excepcionalmente, los PD de Gigabit Ethernet sólo implementan la alternativa A.


41 de 143 Rev. 1

La alternativa B consiste en utilizar los pares no usados (el 4-5 y el 7-8) para transmitir

la potencia, tal como muestra la Fig. 9. Al igual que en la alternativa A, la corriente de

alimentación fluye hacia el PD repartiéndose por ambos hilos de un par mientras que

vuelve a la fuente de alimentación del PSE a través del otro par. La electrónica del PD,

en todo caso, está preparada para alimentarse a través de cualquiera de las dos

alternativas.

Fig. 9. PoE. Alternativa B para PSE de tipo endpoint.

En caso de utilizarse un inyector PoE, sólo se permite la alternativa B y el conexionado

es el mostrado en la Fig. 10.

Fig. 10. PoE. Alternativa B para PSE de tipo midspan (inyectores PoE).

Subcapa de Control de Acceso al Medio (MAC) Tal como establece la norma IEEE 802 [41], las principales funciones de la subcapa

MAC son las siguientes:


42 de 143 Rev. 1

• Delimitación y reconocimiento de las tramas.

• Direccionamiento de las estaciones destino (tanto estaciones individuales como

grupos de estaciones).

• Transporte de información sobre el direccionamiento de la estación origen.

• Transferencia transparente de las PDUs LLC (o de la información equivalente en

la subcapa alternativa Ethernet).

• Protección contra errores de transmisión.

• Control del acceso al medio físico de transmisión.

Cabe destacar que la lista de funciones expuesta es igualmente aplicable para la capa

MAC de todas las tecnologías incluidas en el proyecto IEEE 802 (Ethernet, Token-ring,

WI-FI, etc.). En el resto de este subapartado se aportan detalles sobre cómo se concreta

la realización de dichas funciones en el caso de IEEE 802.3 (Ethernet).

La delimitación y el reconocimiento de las tramas se consigue mediante el

conocimiento a priori por parte de todos los dispositivos que participan en la capa MAC

(estaciones finales, puentes, routers,...) del formato que deben tener dichas tramas, es

decir: los campos que las componen, sus longitudes y sus significados. Por otra parte, la

capa MAC no entrega las tramas “desnudas” a la capa física para que se encargue de

transmitirlas a través del medio. Por el contrario, las envuelve de unos octetos que

ayudan a la capa física a cumplir sus funciones correctamente y que, en conjunto, dan

lugar al paquete MAC, cuyo formato se ilustra a continuación:

Fig. 11. Paquete y trama MAC.


43 de 143 Rev. 1

Como se puede observar, todos los campos tienen un longitud fija, excepto el campo de

Datos del cliente de MAC (también conocido como Datos de Usuario), el campo de

Relleno (Pad) y el campo de Extensión, la longitud de los cuales puede oscilar entre

unos valores máximos y mínimos que dependen de la implementación concreta de la

capa MAC.

• Preámbulo (7 octetos): No forma parte de la trama MAC. Es un patrón de ceros

y unos alternados utilizados por la capa física durante la recepción para

sincronizar su circuitería a nivel de bit.

• Delimitador de comienzo de trama, SFD (1 octeto): No forma parte de la trama

MAC. Consiste en la secuencia de bits 10101011, que indica al receptor que

justo a continuación comienza la trama MAC.

• Dirección de destino, DA (6 octetos): Especifica la estación/es final/es a la/s que

va dirigida la trama mediante una dirección individual (unicast) o de grupo

(multicast o broadcast).

• Dirección de origen, SA (6 octetos): Especifica la estación que envió la trama

mediante una dirección individual.

• Longitud / Ethertype11 (2 octetos): Este campo toma uno de los siguientes dos

significados, dependiendo de su valor numérico.

o Si su valor es menor que o igual a 1500 (0x05DC), entonces el campo

indica la longitud del campo de Datos del Cliente de MAC

(interpretación Longitud) y se sobreentiende que el protocolo cliente de

MAC es LLC, en consonancia con modelo de referencia IEEE 802

(véase la Fig. 3).

o Si su valor es mayor que o igual a 1536 (0x0600), sin embargo, se

sobreentiende que el protocolo cliente de MAC no es LLC, sino el

indicado por el valor del campo (interpretación Ethertype)12. Algunos

valores típicos y sus protocolos asociados se muestran en la Tabla 2:

11 La duplicidad en el significado en el significado de este campo es debida a razones históricas. La especificación Ethernet II utilizaba el significado Ethertype, mientras que la norma IEEE 802.3, en su origen, utilizaba el significado Longitud, lo cual llevaba a ambigüedad en una LAN con estaciones conforme a ambas normas. En 1997, IEEE introdujo el criterio de discriminación expuesto aquí para evitar dicha ambigüedad. 12 Esta es la manera como la norma IEEE 802.3 hace encajar la especificación Ethernet II dentro del modelo de referencia IEEE 802. Para preservar la estructura general del modelo IEEE 802, la norma explica que, cuando se usa Ethertype, la subcapa MAC da servicio a una “subcapa Ethernet alternativa” que esta situada en el mismo nivel que la LLC. La consecuencia práctica es que LLC se soslaya y Ethernet accede a protocolos de nivel superior.


44 de 143 Rev. 1

Ethertype Protocolo

0x0800 Internet Protocol, version 4 (IPv4)

0x86DD Internet Protocol, version 6 (IPv6)

0x0806 Address Resolution Protocol (ARP)

0x8100 Q-tagged frames (IEEE 802.1Q)

0x88CC LLDP (IEEE 802.1AB)

0x8847 MPLS unicast

0x8848 MPLS multicast

0x88E5 MAC Security (IEEE 802.1AE)

Tabla 2. Valores típicos de Ethertype.

• Datos del cliente de MAC: Este campo contiene los datos procedentes del

protocolo cliente en la estación final emisora y que son entregados de manera

transparente a ese mismo protocolo en la estación final receptora. Su longitud

puede oscilar entre cero y un valor máximo que depende de la implementación

concreta de Ethernet13. Cualquier implementación de Ethernet deberá soportar al

menos uno de los siguientes valores máximos:

o 1500 decimal: Tramas básicas.

o 1504 decimal: Tramas etiquetadas (tagged frames).

o 1982 decimal: Tramas marco (Envelope frames).

• Relleno (0 a 46 octetos): Octetos añadidos para asegurar que la trama es

suficientemente larga para un correcto funcionamiento de la técnica de detección

de colisión (CD). Puesto que longitud mínima de la trama debe ser 64 octetos, el

relleno necesario puede alcanzar los 46 octetos.

• Secuencia de comprobación de trama, FCS (4 octetos): Comprobación de

redundancia cíclica (CRC) de 32 bits, en base a todos los campos de la trama

MAC, excepto el propio FCS.

13 Tanto la especificación de Ethernet II como la de IEEE 802.3, en su origen, preveían una única longitud máxima de 1500 octetos (tramas básicas). Sin embargo, con el tiempo, IEEE 802.3 ha ido añadiendo capacidades que requerían destinar un espacio adicional para la metainformación correspondiente dentro del campo de Datos del Cliente de MAC. Así, hay implementaciones Ethernet que permiten insertar en las tramas unas etiquetas de 4 octetos con información adicional sobre el tratamiento que debe recibir la trama en la capa MAC (véase apartado 3.2.2.3). Por último, otras implementaciones de Ethernet permiten insertar prefijos y sufijos adicionales requeridos por protocolos de encapsulación de capas superiores (MAC Security, MPLS, etc.) y destinan para ello un espacio adicional de hasta 482 octetos en las llamadas tramas marco. En todo caso, el tamaño del campo de Datos del Cliente de MAC “original” sigue siendo de 1500 octetos y la norma desaconseja el uso de estos octetos extra para usos diferentes de los previstos.


45 de 143 Rev. 1

• Extensión: No forma parte de la trama MAC. Este campo se añade para

completar el paquete MAC, si es necesario (sólo en implementaciones de 1000

Mbps en half duplex).

El direccionamiento de las estaciones destino se consigue incluyendo en el campo

correspondiente de la trama MAC la dirección MAC deseada. La norma IEEE 802 [41]

establece las reglas para la asignación y la interpretación de las direcciones MAC, que

se resumen a continuación:

• Cualquier dispositivo asociado con un interfaz físico de conexión a una LAN

debe tener una dirección MAC única, incorporada en fábrica. Si un dispositivo

tiene varios interfaces LAN, debería tener una dirección MAC única por cada

interfaz14. La unicidad de la dirección MAC es universal: No debe coincidir con

la dirección de ningún otro interfaz LAN, sea del mismo dispositivo o de otro,

sea del mismo fabricante o de otro y sea de la misma tecnología LAN (Ethernet,

Token-ring, etc.) o de otra.

• La dirección MAC consta de 48 bits (seis octetos). Los tres primeros octetos

constituyen la OUI (Organizationally Unique Identifier), que es un identificador

del fabricante y está administrado por IEEE. Los últimos tres octetos constituyen

el identificador del propio interfaz LAN y está administrado por el propio

fabricante.

Fig. 12. Ejemplo de dirección MAC.

14 Aunque la norma reconoce que un enfoque alternativo sería asignar una sola dirección MAC al dispositivo, aunque tenga varios interfaces LAN, no recomienda este enfoque y advierte de que puede llevar a ocasionar la no conformidad con la norma en lo referente a la interconexión a través de puentes (bridging).


46 de 143 Rev. 1

• Dentro del OUI, realmente sólo hay 22 bits de espacio libre para definir el

fabricante. Los primeros dos bits, según el orden en que se transmiten (véase

Fig. 12), tienen otros significados:

o Bit I/G (dirección individual / de grupo): Si es “0”, la dirección es

individual y designa un solo dispositivo en la red. Si es “1”, la dirección

es de grupo y designa a uno o más dispositivos en la red. Se distinguen

dos tipos de dirección de grupo:

Dirección Multicast: Una dirección asociada mediante una

convención de un nivel superior con un grupo de dispositivos

lógicamente relacionados.

Dirección Broadcast: Una dirección de grupo predeterminada

(formada por exclusivamente por 1’s) y que todos dispositivos

están obligados a reconocer, a parte de la propia individual.

o Bit U/L (dirección universal o localmente administrada): Si es “0” la

dirección está administrada globalmente, es decir, por el organismo

pertinente de IEEE. Si es “1”, la dirección está administrada localmente

en la LAN (se entiende que por su operador).

El transporte de información sobre el direccionamiento de la estación origen se

consigue incluyendo en el campo correspondiente de la trama MAC la dirección MAC

de la estación emisora.

La transferencia transparente de las PDUs LLC (o de la información equivalente

en la subcapa alternativa Ethernet) se consigue entregando intacto el contenido del

campo Datos del cliente MAC al protocolo de la capa inmediatamente superior, en la

estación receptora.

La protección contra errores de transmisión se obtiene mediante la comprobación de

las siguientes condiciones:

• La longitud de la trama no es consistente con el valor de longitud indicado en el

campo Longitud / Ethertype (sólo en caso de interpretación Longitud).

• La longitud de la trama no tiene un número entero de octetos.


47 de 143 Rev. 1

• Los bits de la trama recibida (excluyendo el campo FCS) no generan el mismo

valor CRC que el contenido en el campo FCS recibido.

Si cualquiera de estas condiciones se cumple, la trama MAC se considera invalida y se

descarta sin más.

Por último, el control de acceso al medio de transmisión se realiza a través del

mecanismo CSMA/CD, que se basa en los siguientes pasos:

1. La estación final transmite si el medio está libre.

2. Si el medio se encuentra ocupado, la estación continúa escuchando hasta

que lo encuentra libre y, entonces, transmite inmediatamente.

3. Si se detecta una colisión durante la transmisión, las estaciones transmiten

una señal corta de interferencia (jam) para asegurarse de que todas las

demás estaciones presentes en el medio constatan la ocurrencia de una

colisión y cesan de transmitir.

4. Después de transmitir la señal de interferencia, cada estación en contienda

espera un tiempo aleatorio (backoff) y vuelve a intentar la transmisión, si el

medio está libre (paso 1).

5. Los reintentos se repiten hasta un numero máximo, después del cual se

abandona la transmisión de la trama y se reporta un error a la capa LLC.

c) Switched Ethernet (IEEE 802.1) En el subapartado anterior, se ha hecho un repaso de la norma IEEE 802.3, que

especifica la capa física y la subcapa MAC de Ethernet, tal como ilustra la Fig. 4. En la

misma figura, se puede observar que la norma IEEE 802.1 especifica diversos aspectos,

entre ellos el bridging. Con este término se denota la interconexión mediante puentes

(bridges) de diversas LANs IEEE 802 de dominio de acceso único, ya sean de un solo

tipo MAC o de varios (Ethernet, Token-ring, WI-FI, etc.). Para los fines de este estudio,

interesan básicamente las bridged LANs de tipo Ethernet, normalmente conocidas como

Switched15 Ethernet. Aun así, conviene tener presente que lo expuesto en el resto de

15 Aunque la norma IEEE 802 reconoce el término switch como sinónimo de bridge, insiste en usar exclusivamente este último. Por ese motivo, en estos apartados, que repasan el contenido de la norma, se respeta el término bridge (puente). En apartados posteriores, por ejemplo los que tratan productos de


48 de 143 Rev. 1

este subapartado –a menos que se indique expresamente lo contrario– es válido para

todo tipo de bridged LANs IEEE 802, incluyendo las que contienen partes con

tecnología WI-FI o Bluetooth, cada vez más presentes en aplicaciones industriales.

Los aspectos del bridging en las LANs IEEE 802 quedan contemplados básicamente en

los siguientes documentos:

• IEEE 802.1D – 2004 [48], que establece los fundamentos de las bridged LANs.

• IEEE 802.1Q – 2005 [49], que –basándose en el anterior– establece funciones

adicionales como las LANs virtuales (VLANs) y el etiquetado de tramas con

información del usuario sobre su prioridad.

• IEEE 802.1AX-2008 [50], que especifica la función de agregación de enlaces.

• IEEE 802.1AB-2009 [51], que permite el descubrimiento de la topología física y

de la configuración relevante para la conectividad.

A continuación, se exponen sus contenidos fundamentales.

Bridged LANs (IEEE 802.1D) Un puente (bridge) por definición está conectado a varios dominios de acceso. Su

función básica consiste en recibir las tramas MAC que llegan desde un dominio de

acceso y reenviarlas (o no: filtrarlas) al resto de los dominios de acceso. El criterio para

tomar estas decisiones consiste en limitar la propagación de las tramas MAC solamente

a aquellos dominios de acceso que se encuentran en el camino hacia las estaciones

finales destinatarias. El puente realiza esta función dentro de la capa MAC, tal como

ilustra la Fig. 13, y la realiza de una manera transparente para las estaciones finales,

dado que no requieren ninguna información adicional, más que la incluida en las tramas

MAC.

mercado, se utiliza el término switch por ser el habitualmente utilizado, sin que ello quiera sugerir ninguna diferencia de significado.


49 de 143 Rev. 1

Fig. 13. Situación de la función de reenvío (relay).

Los principales beneficios de una bridged LAN son:

• La interconexión de diferentes tipos de MAC. Por ejemplo, ejemplo Ethernet

(IEEE 802.3) y WI-FI (IEEE 802.11).

• El incremento del throughput de la LAN. En efecto, en una LAN con un único

dominio de acceso (p.ej., basada en bus o en repetidores) sólo se puede

transmitir una trama en cada instante. En cambio, en una LAN basada en

puentes es posible que varias tramas se propaguen simultáneamente, cada una en

un dominio de acceso diferente.

• Reducción de la carga de las estaciones finales. En efecto, la función de filtrado

de los puentes hace que las estaciones finales reciban menos tramas que no iban

dirigidas a ellas.

• El incremento de la extensión física y / o el número de estaciones finales

admisibles.

• Sectorización de la LAN con fines administrativos o de mantenimiento.

• Validación de acceso a la LAN, mediante autenticación y autorización de

dispositivos.

La esencia del comportamiento de un puente viene definida por el proceso de

forwarding, ilustrado en la Fig. 14.


50 de 143 Rev. 1

Fig. 14. El proceso de forwarding.

Cuando un puerto (origen) del puente recibe una trama MAC libre de errores procedente

de una estación final origen, dicha trama se somete al proceso de forwarding de manera

independiente para cada uno de los puertos (destino16) restantes del puente. En primer

lugar se aplica la topología activa17: Si el puerto origen o bien el puerto destino no están

habilitados para hacer forwarding, el proceso se aborta y la trama se descarta.

Seguidamente, se realiza el paso de filtrado, contrastando la dirección MAC de destino

contenida en la trama MAC con la información que contiene la Base de Datos de

Filtrado referente al puerto destino (potencial). La base de datos puede contener

criterios (entradas) de diversos tipos, a saber:

16 Naturalmente, la trama MAC entrante no contiene información explícita sobre cuál es el puerto por el que debe ser reenviada, únicamente sobre la dirección MAC de destino. Por tanto, en primera instancia, todos los puertos del puente (excepto el de entrada) son puertos destino (potenciales). Será el paso posterior de filtrado el que decidirá por qué puertos será finalmente reenviada la trama y por cuáles no. 17 La topología activa de una bridged LAN en un momento dado es el conjunto de vías de comunicación formado interconectando las LANs y los puentes a través de los puertos que están en ese momento habilitados para hacer forwarding. A parte de los condicionantes estáticos que pueda configurar el administrador de la bridged LAN, la topología activa viene básicamente determinada por el algoritmo de Spanning Tree.


51 de 143 Rev. 1

• Entradas Estáticas de Filtrado, establecidas manualmente por el administrador

de la bridged LAN. Estas entradas pueden hacer referencia tanto a direcciones

individuales como de grupo.

• Entradas Dinámicas de Filtrado, adquiridas automáticamente mediante el

proceso de aprendizaje, comentado más adelante. Estas entradas únicamente

hacen referencia a direcciones MAC individuales.

• Entradas de Registro de Grupos, establecidas vía el protocolo GMRP,

comentado más adelante. Estas entradas únicamente hacen referencia a

direcciones MAC de grupo.

Si la trama satisface los criterios de filtrado, se almacena en una cola donde espera su

turno para continuar el proceso. En caso contrario el proceso se aborta y la trama se

descarta. La implementación del puente puede opcionalmente soportar diversas clases

de tráfico (hasta ocho clases). En ese caso, el puerto tendrá una cola diferente para cada

clase de tráfico soportada y la trama será clasificada en la cola que le corresponda, de

acuerdo con su prioridad de usuario18.

El orden en que se seleccionarán las tramas para su transmisión estará de acuerdo con su

clase de tráfico: En primer lugar, se seleccionarán las tramas de la cola correspondiente

a la clase de tráfico más prioritaria y sólo cuando esta cola esté vacía se seleccionarán

tramas de una cola correspondiente a una clase de tráfico menos prioritaria.

Seguidamente, se asignará un valor de prioridad de acceso al medio acorde con el valor

de prioridad de usuario contenido en la trama19. Después se recalculará el campo FCS

sólo si es necesario, es decir, si el puerto de origen y el puerto de destino del puente

están conectados a LANs con tipos de MAC diferentes. Por último la trama será

transmitida por el puerto de destino.

El proceso de aprendizaje, mencionado anteriormente, se encarga de observar las

direcciones MAC de origen contenidas en las tramas MAC que entran al puente por 18 Aunque la MAC Ethernet no tiene capacidades de manera inherente para señalizar en la propia trama información de prioridad asignada por el usuario (a diferencia de otros tipos de MAC, como Token-ring), sí que permite asignar prioridades a las tramas (dentro del puente), en función del puerto de recepción. 19 Aunque otros tipos de MAC sí tienen capacidad para establecer prioridades de acceso al medio, Ethernet no la tiene, ni aun cuando la información esté disponible en la trama MAC, gracias a IEEE 802.1Q.


52 de 143 Rev. 1

cada uno de los puertos. De este modo, el puente aprende de manera dinámica por qué

puerto debería reenviar una futura trama que llegue con esa misma dirección MAC

como destino. En concreto, el proceso de aprendizaje creará o actualizará una Entrada

Dinámica de Filtrado en la Base de Datos de Filtrado siempre que entre una trama por

un puerto (origen) y se den todas estas condiciones:

• El puerto de origen se encuentra en el estado de Forwarding o en el estado de

Learning20.

• La dirección MAC de origen es individual (no de grupo).

• No existe una entrada estática para esa dirección MAC que en su Mapeado de

Puertos especifique cómo debe comportarse el puerto de origen (filtrando o

reenviando).

• La Base de Datos de Filtrado no ha agotado su capacidad y puede acoger la

nueva entrada (o bien se borra una entrada existente para dejar espacio).

El proceso de aprendizaje permite optimizar dinámicamente el filtrado de tramas con

dirección MAC individual, dentro de lo que se denomina Servicios de Filtrado Básicos,

declarados como obligatorios por la norma. La norma también prevé unos Servicios de

Filtrado Extendidos (de carácter opcional) que tratan el filtrado de las tramas con

dirección MAC de grupo, es decir, tramas multicast.

Los Servicios de Filtrado Extendidos basan su capacidad de adaptación dinámica en el

protocolo GMRP (GARP Multicast Registration Protocol21), que permite a un

determinado puente actualizar o crear Entradas de Registro de Grupos en su Base de

Datos de Filtrado. En efecto, las estaciones finales y otros puentes contiguos al puente

en cuestión pueden enviarle vía GMRP órdenes de alta o baja referentes a su

pertenencia a un determinado grupo (identificado por una dirección MAC de grupo).

Además, en la medida en que los demás puentes de la bridged LAN soporten los

20 Normalmente se encontrará en el estado de Forwarding, que habilita tanto el reenvío como el aprendizaje. Sin embargo, también es posible habilitar el aprendizaje y deshabilitar al mismo tiempo el reenvío, mediante el estado de Learning. El tercer estado posible es el de Discarding, que deshabilita ambos procesos. 21 Tal como indica su nombre, el protocolo GMRP se basa en el protocolo genérico GARP (Generic Attribute Registration Protocol), que también sirve de base para otros protocolos similares, como el GVRP (GARP VLAN Registration Protocol). Todos ellos son protocolos de capa 2 (OSI).


53 de 143 Rev. 1

Servicios de Filtrado Extendidos, la información sobre la pertenencia de cada estación

final a los diferentes grupos se podrá diseminar por toda la bridged LAN.

Otro protocolo auxiliar importante en la subcapa MAC es el Rapid Spanning Tree

Protocol (RSTP). Este protocolo permite el intercambio de información entre los

diferentes puentes de la bridged LAN, a través de tramas especiales denominadas

BPDUs, con el fin de que se pueda ejecutar de manera distribuida el algoritmo Rapid

Spanning Tree. Gracias al algoritmo y al protocolo, se asegura en todo momento que el

estado de los puertos de todos los puentes da lugar a una topología activa conectada de

manera completa (todas las estaciones finales tienen conectividad) y simple (dados dos

puntos diferentes de la red, no hay dos caminos lógicos diferentes que los unan, es

decir, no se forman bucles lógicos).

La ausencia de bucles lógicos es esencial para el funcionamiento de la bridged LAN.

Normalmente, en el diseño de una bridged LAN se prevén caminos físicos duplicados

para permitir la tolerancia al fallo de uno de ellos. Si todos los puertos de la bridged

LAN se mantuvieran en estado forwarding, esta duplicidad de caminos físicos se

traduciría en bucles lógicos, con el consiguiente riesgo de tormentas multicast22. RSTP,

sin embargo, se encarga de bloquear los puertos adecuados para que no haya bucles

lógicos, tal como ilustra la Fig. 15.

Fig. 15. Topología activa completa (spanning) y simple (tree).

Aún así, la duplicidad de caminos físicos existe, de modo que, si se detecta que un

camino físico activo ha dejado de funcionar (p.ej. el 4-5), RSTP puede recalcular, ante

las nuevas condiciones, la configuración de puertos que permita una topología activa

22 En una tormenta multicast (o broadcast), una trama MAC con dirección MAC destino de grupo es reenviada por los puentes sucesivamente describiendo bucles cerrados de manera indefinida.


54 de 143 Rev. 1

alternativa (activando los puertos del camino 2-5). De este modo, se proporciona la

tolerancia al fallo.

El protocolo antecesor del RSTP es el STP (Spanning Tree Protocol), que tiene la

misma funcionalidad, pero es más lento a la hora de restablecer la topología activa en

caso de fallo en un camino físico activo. Mientras que el STP puede tardar entre 30 y 50

segundos, el RSTP tarda entre 1 y 10 segundos. La edición vigente de la IEEE 802.1D

ya establece como obligatorio el uso del RSTP, en sustitución del STP. La

compatibilidad queda asegurada, de modo que se pueden mezclar puentes que

incorporan diferentes protocolos, pero en ese caso no quedan aseguradas las

prestaciones superiores del RSTP.

VLANs y señalización de prioridad sobre tramas (IEEE 802.1Q) El rasgo fundamental de la norma IEEE 802.1Q consiste en que prevé la inserción en

cada trama MAC de una etiqueta con información que condicionará el tratamiento

recibido durante su viaje a través de los puentes de la bridged LAN. En la Fig. 16, se

ilustra el formato de esta etiqueta y su ubicación dentro de la trama MAC23:

Fig. 16. Ubicación y formato de la etiqueta.

Como se puede observar, la etiqueta tiene cuatro octetos de longitud y está ubicada a

continuación del campo Dirección MAC de Origen. Consta de los siguientes campos:

23 En general, el formato es más complejo, esto es, variable en función de diferentes circunstancias. El formato expuesto aquí, sin embargo, es válido para LANs de tipo Ethernet en la mayoría de los casos.


55 de 143 Rev. 1

• TPID (Tag Protocol Identifier) (2 octetos): Contiene un valor Ethertype de

0x8100, que marca el inicio de la etiqueta.

• TCI (Tag Control Information) (2 octetos): Contiene la siguiente información

sobre la trama:

o PCP (Priority Code Point) (3 bits): Puede adoptar un valor del 0 al 7 que

indica la prioridad de usuario con que se debe tratar la trama.

o CFI (Canonical Format Indicator) (1 bit): En el formato de etiqueta que

se está suponiendo aquí, este bit tiene un valor de “0”.

o VID (VLAN Identifier) (12 bits): Identifica la VLAN a la que pertenece

la trama.

Cabe destacar que la etiqueta está realmente insertada, es decir, no afecta a otras partes

de la trama:

• El campo Longitud / Ethertype de la trama original (sin etiquetar) no se pierde,

lo cual implica que la trama etiquetada tiene dos campos de este tipo: El primero

(TPID) sirve para que la capa MAC reconozca la trama como etiquetada y el

segundo sirve para identificar el protocolo de la capa inmediatamente superior a

la MAC.

• El campo de Datos del Cliente de MAC sigue teniendo una longitud máxima de

1500 octetos, gracias a que la capa MAC de Ethernet reconoce la trama como

etiquetada y le permite una longitud máxima incrementada en 4 octetos.

Según sea el valor del VID contenido en la etiqueta se distinguen dos tipos de tramas

etiquetadas:

• Trama etiquetada con prioridad (priority-tagged frame). Contiene un valor de

VID igual a “0”. Este valor se usa para indicar que la etiqueta no contiene

información de pertenencia a ninguna VLAN. Así pues, sólo transporta

información sobre prioridad.

• Trama etiquetada con VLAN (VLAN-tagged frame). Contiene un valor de VID

diferente de “0”. En este caso, la etiqueta transporta información tanto sobre

prioridad como sobre pertenencia a una VLAN.


56 de 143 Rev. 1

A continuación, se concreta en qué consisten los dos aspectos fundamentales en que

la etiqueta condiciona el tratamiento recibido por la trama MAC:

• VLANs. En una bridged LAN conforme a IEEE 802.1D, una estación final tiene

conectividad con todo el resto de estaciones finales como si estuvieran en la

misma LAN. El etiquetado de tramas conforme a IEEE 802.1Q permite definir

grupos de estaciones finales que constituyen LANs separadas en un sentido

lógico (LANs virtuales). Esto aporta las siguientes ventajas:

o Segmentación flexible de la LAN. En una solución tradicional conforme

a IEEE 802.1D puede plantearse la implantación de varias bridged LANs

independientes para diferentes funciones (p.ej. departamentos). En ese

caso, el cambio de función de una estación final requiere nueva cableado

hacia el puente de una bridged LAN diferente. En cambio, en una

solución basada en IEEE 802.1Q, se puede implantar una única bridged

LAN y separar las funciones mediante LANs virtuales (VLANs)

diferentes. En ese caso, el cambio de función de un estación final require

simplemente un cambio de configuración en un puente.

o Seguridad adicional. La estación final de una VLAN no puede acceder a

la estación final de otra VLAN a menos se permita esta conexión a través

de un router.

o Restricción de tráfico. El tráfico broadcast y multicast24 queda

restringido a la VLAN donde se origina y no se extiende al resto.

• Priorización. El etiquetado de tramas proporciona un medio adicional para que

todos los tipos MAC (Ethernet, Token-ring, etc.) puedan señalizar sobre la

propia trama la prioridad de usuario de manera independiente a sus capacidades

inherentes, de modo que se asegure un tratamiento de la trama consistente a lo

largo todos los puentes que componen la bridged LAN.

A continuación se exponen los rasgos diferenciales del comportamiento de un

puente conforme a IEEE 802.1Q con respecto al de uno conforme a IEEE 802.1D

24 Es cierto que IEEE 802.1D prevé una solución para limitar la extensión del tráfico multicast consistente en los Servicios de Filtrado Extendidos. Sin embargo, esta solución requiere que los puentes tengan implementados estos servicios (que la norma declara como opcionales) y que las estaciones finales tengan implementado el protocolo GMRP, para poder registrarse en los grupos. Si no se dan estas condiciones el tráfico multicast es tratado por los puentes como broadcast. Así pues, la implantación de una bridged LAN que conforme a IEEE 802.1Q y la definición de VLANs puede ser una alternativa para limitar el tráfico multicast, cuando las estaciones finales no implementan GMRP.


57 de 143 Rev. 1

(explicado en el subapartado anterior), en las siguientes tres etapas que sigue la trama:

entrada, tratamiento y salida.

• Entrada. El puente clasifica la trama, es decir, determina a qué VLAN pertenece.

Si la trama es VLAN-tagged la clasificación se hace en base al campo VID

contenido en ella. En cambio, si es priority-tagged o untagged, se hace en base

al puerto de recepción de la trama25. Para ello, cada puerto tiene un parámetro

(PVID, Port VLAN Identifier) configurable. Por otra parte, el puente determina

la prioridad de usuario de la trama. Si la trama es VLAN-tagged o priority-

tagged se toma como prioridad de usuario el valor del campo PCP contenido en

ella. En cambio, si es untagged, se toma un valor en función del puerto de

recepción de la trama26. Para ello, cada puerto tiene un parámetro configurable,

cuyo valor por defecto es “0”.

• Tratamiento de la trama. El puente se comporta de manera diferente en función

de la VLAN a la que pertenece la trama:

o La aplicación de la topología activa (bloqueo de puertos para evitar

bucles) se realiza de forma independiente para cada VLAN. Esto se

consigue mediante una extensión del RSTP denominada MSTP (Muti-

Spanning Tree Protocol) que permite mantener el cálculo en todo

momento de una topología completa y simple para cada VLAN.

o Los procesos de aprendizaje y de filtrado también se realizan de forma

independiente para cada VLAN. Esto se consigue gracias a que las

entradas en la Base de Datos de Filtrado incluye información sobre la

VLAN a la que aplican.

o Además de sus funciones habituales, el proceso de filtrado se encarga de

asegurar el confinamiento dentro de la VLAN. Para ello, la Base de

Datos de Filtrado incluye dos nuevos tipos de entradas:

Entradas Estáticas de Registro de VLAN, establecidas

manualmente por el administrador de la bridged LAN.

Entradas Dinámicas de Registro de VLAN, establecidas vía el

protocolo GVRP.

25 La norma prevé la implementación (opcional) de un mecanismo más sofisticado de clasificación basado no sólo el en puerto de recepción sino también en el protocolo cliente de la trama MAC. 26 En caso de que el tipo MAC tenga mecanismos inherentes para señalizar la prioridad, se recurre a estos mecanismos para determinar la prioridad de usuario.


58 de 143 Rev. 1

o La priorización del reenvío de tramas se basa en los mismos mecanismos

ya establecidos en IEEE 802.1D. La novedad que aporta IEEE 802.1Q

(especialmente en los tipos de MAC como Ethernet, que no tienen

mecanismos inherentes para señalizar la prioridad en las tramas) es que

esa priorización del reenvío se puede realizar de manera consistente en

todos los puertos de la bridged LAN, gracias las etiquetas.

• Salida. Tal como se ha visto en el párrafo anterior, el puente tiene criterio

(previa configuración oportuna) para asignar la información de VLAN y de

prioridad, tanto si la trama llega etiquetada como si no. Gracias a eso, a la salida

se puede insertar la etiqueta a la trama incluso aunque no existiera a la entrada.

Por defecto, todos los puertos están configurados para transmitir tramas VLAN-

tagged. Sólo aquellos puertos en que se configure explícitamente lo contrario,

transmitirán tramas untagged (no existe posibilidad de enviar tramas priority-

tagged).

En definitiva, la norma permite abordar la implantación de VLANs mediante dos

enfoques: el estático y el dinámico:

• VLANs estáticas. Se definen mediante configuración manual en los puentes, por

parte del administrador de la bridged LAN.

o Ventajas: Son fáciles de configurar y no requieren que las estaciones

finales implementen el protocolo GVRP.

o Inconvenientes: La pertenencia del tráfico a una determinada VLAN se

identifica en base al puerto de entrada: El usuario de la estación final

debe prestar atención para conectarse al puerto correcto o será necesaria

una reconfiguración del puente.

• VLANs dinámicas. Se definen de manera automática mediante registros

dinámicos de pertenencia a VLANs realizados en los puentes por las estaciones

finales, mediante el protocolo GVRP.

o Ventajas: La pertenencia del tráfico a una determinada VLAN se

identifica en base a la propia estación final que lo transmite o incluso

(opcionalmente) en base al protocolo cliente de la capa MAC.

o Inconvenientes: Coste mayor debido a que son necesarios puentes con

mayores prestaciones (dentro de lo previsto en la norma IEEE 802.1Q) y

estaciones finales no estándar (deben implementar GVRP).


59 de 143 Rev. 1

Agregación de Enlaces (IEEE 802.1AX) La Agregación de Enlaces permite que uno o más enlaces se agreguen para formar un

Grupo de Agregación de Enlaces, de tal manera que un cliente MAC pueda utilizar

dicho Grupo como si fuera un único enlace. Las condiciones que deben cumplir los

enlaces para poder agregarse son:

• Ser enlaces punto a punto, entre los mismos dos sistemas. Puede tratarse de dos

puentes, de un puente y una estación final (que incorpore una NIC especial), un

puente y un router, etc.

• Pertenecer al mismo tipo de MAC27.

• Tener la misma tasa de transferencia.

• Operar en modo full-duplex.

El Grupo de Agregación de Enlaces resultante posee las siguientes características:

• Operación en modo full-duplex.

• Tasa de transferencia igual a la suma de las tasas individuales.

• Mayor fiabilidad, ya que proporciona tolerancia al fallo de un enlace físico.

• Configuración automática. Si dos enlaces se pueden agregar, lo harán

automáticamente, a menos que lo impida una configuración estática.

• Reconfiguración automática, si cambian las condiciones de conectividad física

(por ejemplo, si falla uno de los enlaces agregados). El servicio se restablece en

un intervalo del orden de un segundo o menos.

La subcapa de Agregación de Enlaces se sitúa justo por encima de la capa MAC y

resulta transparente para el cliente MAC (sea LLC u otro). Para realizar sus funciones,

se basa en un protocolo auxiliar LACP (Link Aggregation Control Protocol). Además,

implementa

Descubrimiento de la topología de la bridged LAN (IEEE 802.1AB) La norma IEEE 802.1AB especifica el protocolo LLDP (Link Layer Discovery

Protocol), que permite a las estaciones (tanto estaciones finales como puentes) de una

27 Actualmente, solamente está especificada la Agregación de Enlaces para la MAC IEEE 802.3 (Ethernet).


60 de 143 Rev. 1

bridged LAN transmitir a las estaciones adyacentes información sobre sus capacidades

y su configuración. Igualmente, permite a las estaciones recibir y almacenar

información del mismo tipo sobre las estaciones adyacentes. Tanto la información

propia como la ajena es almacenada en cada estación en forma de MIBs estándares, de

modo que puede ser consultada de forma centralizada desde cualquier punto de la

bridged LAN por un Sistema de Gestión de Redes (NMS, Network Management

System), a través de un protocolo de gestión, como por ejemplo el SNMP (Simple

Network Management Protocol).

Las principales ventajas que persigue esta norma son:

• Facilitar la interoperabilidad multi-fabricante y el uso de herramientas estándar

de gestión para descubrir y proporcionar información sobre la topología física

para la gestión de red.

• Permitir a la gestión de redes el descubrimiento de ciertas inconsistencias de

configuración que pueden dar lugar a falta de conectividad en capas superiores28.

La implementación de la norma se realiza mediante un agente LLDP que opera según se

ilustra en la Fig. 17.

28 Para el buen funcionamiento de las funcionalidades descritas en apartados anteriores (VLANs, agregación de enlaces) y otras, es necesaria una configuración consistente a lo largo de todas la bridged LAN.


61 de 143 Rev. 1

Fig. 17. Principio de funcionamiento de LLDP.

El agente LLDP recopila información sobre la propia estación a partir de otros MIBs

estándares que se encuentran implementados en ella. A continuación se enumeran

algunos MIBs que pueden interactuar con el agente LLDP:

• MIB Physical Topology (PTOPO) (RFC 2922).

• MIB Entity (RFC 4133).

• MIB Interfaces (RFC 2863).

• MIB Power Ethernet (RFC 3621).

• MIBs para bridges con de clases de tráfico, filtrado multicast y extensiones

VLAN (RFC 4363).

• MIBs para MAUs (Medium Attachment Units) de IEEE 802.3 (RFC 4836).

Con la información recopilada, el agente LLDP mantiene el MIB LLDP del sistema

local, que tiene una parte estándar y, opcionalmente, una extensión definida por el

propio fabricante. El agente LLDP transmite periódicamente la información de este

MIB mediante tramas del protocolo LLDP, denominadas LLDPDUs, hacia las

estaciones adyacentes. También periódicamente, el agente LLDP recibe LLDPDUs de

otras estaciones y con ellas refresca el contenido del MIB LLDP de sistemas remotos.


62 de 143 Rev. 1

Las tramas LLDP se encapsulan en tramas MAC con un valor de Ethertype 0x88CC.

Como dirección MAC de destino, utilizan valores reservados de direcciones MAC de

grupo (multicast).

d) LLC (IEEE 802.2) y la Subcapa Ethernet alternativa. Dentro del modelo de referencia IEEE 802, la subcapa LLC complementa a la subcapa

MAC para completar las funciones propias de la capa 2 (OSI). La especificación de

LLC tiene previstos tres tipos de operación, aunque sólo el tipo 1 debe ser soportado

obligatoriamente en una implementación de LAN conforme a IEEE 802:

• Tipo 1. Permite el intercambio de tramas sin necesidad de establecer

previamente una conexión lógica entre ambas entidades LLC. En este tipo de

operación, no se devuelven tramas de reconocimiento (acknowledgement) ni se

proporcionan mecanismos de control de flujo y recuperación de errores.

• Tipo 2. Se establece una conexión lógica entre ambas entidades LLC con

antelación a cualquier intercambio de tramas de datos. Durante la fase de

intercambio de datos la subcapa proporciona mecanismos para asegurar la

entrega ordenada de tramas, el control de flujo y la recuperación de errores.

• Tipo 3. Permite el intercambio de tramas sin necesidad del previo

establecimiento de una conexión lógica. Sin embargo, se proporciona

reconocimiento de tramas.

Las PDUs de LLC se incluyen como Datos de Usuario (campo Datos del Cliente MAC)

en una trama MAC cuyo campo Length / Ethertype tiene un valor menor de 1500

(Interpretación Longitud). Precisamente este hecho es el que permite identificar que el

protocolo cliente de MAC es LLC. El formato de las PDUs LLC se ilustra en la Fig. 18:

Fig. 18. Formato de la PDU LLC.


63 de 143 Rev. 1

En ella, se puede apreciar los siguientes campos:

• Dirección DSAP (Destination Service Access Point) (1 octeto). Identifica el/los

SAP/s a los que va dirigida la información LLC (dentro de la estación final a la

que va dirigida la trama MAC).

• Dirección SSAP (Source Service Access Point) (1 octeto). Identifica el SAP que

originó la PDU LLC (dentro de la estación final de origen identificada en la

trama MAC).

• Control (1 ó 2 octetos). Contiene información de control propia del protocolo

LLC.

• Información (M octetos). Contiene los Datos de Usuario de LLC, es decir, la

PDU del protocolo cliente. El límite superior de M depende del tipo de MAC

que dé servicio a la subcapa LLC.

Lo explicado hasta ahora en este subapartado aplica en general a todas las tecnologías

de LANs IEEE 802, incluyendo la CSMA/CD (IEEE 802.3). Sin embargo, dentro de la

tecnología IEEE 802.3 se prevé un caso que, a pesar de ser particular, es muy frecuente:

que las estaciones finales emitan las tramas MAC de acuerdo con el formato Ethernet,

es decir, con un valor mayor de 1536 en el campo Longitud / Ethertype (interpretación

Ethertype). En este caso la subcapa LLC no interviene y la capa MAC (Ethernet) da

servicio directamente un protocolo de capa superior. Para salvar la generalidad del

modelo de referencia IEEE 802 (véase la Fig. 3), la norma utiliza el concepto de

subcapa Ethernet alternativa y la sitúa en una ubicación dentro de la arquitectura

totalmente equivalente a la de la subcapa LLC.

e) Protocolo IP y extensiones A continuación se mencionan brevemente los protocolos existentes en la capa de red,

según el modelo TCP/IP:

IP (Internet Protocol). Es el protocolo principal de la capa de red y el utilizado para

transmitir datos de usuario. Utiliza un sistema de direccionamiento (IP) que permite

designar y alcanzar cualquier estación final en el mundo, siempre y cuando su red

(LAN, MAN o WAN) esté conectada a Internet mediante un router que implemente IP


64 de 143 Rev. 1

en su capa de red. Actualmente se usa mayoritariamente la versión 4 (IPv4), pero está

prevista una versión que en el futuro aportará mayor capacidad de direccionamiento

(IPv6).

ICMP (Internet Control Message Protocol). Permite el intercambio de información de

control para garantizar las funciones de la capa de red. Las PDUs de ICMP se

encapsulan dentro de paquetes IP.

IGMP (Internet Group Management Protocol). Permite a las estaciones finales

comunicar a los routers y otras estaciones finales su incorporación a los diferentes

grupos multicast (mensaje de host membership report). También les permite darse de

baja mediante mensajes de leave group. Las PDUs de IGMP se encapsulan dentro de

paquetes IP. Los routers almacenan esta información y la utilizan para reenviar los

paquete IP con direcciones IP multicast solamente a aquellas redes que contienen

estaciones finales pertenecientes al grupo multicast correspondiente. Además, los

routers envían periódicamente consultas (host membership query) que fuerzan a las

estaciones finales a transmitir de nuevo mensajes de host membership report.

IGMP Snooping. Se trata de una funcionalidad (no un protocolo) que implementan

algunos bridges pero que no es respaldada por una norma de jure. Consiste en

inspeccionar las tramas más allá de lo que le corresponde a un bridge (esto es, dentro

del campo de Datos del Cliente MAC) para identificar paquetes IGMP enviados por

estaciones finales con el objetivo de registrarse en un grupo multicast. De esta manera,

el bridge evita su comportamiento por defecto cuando recibe tráfico multicast (es decir,

reenviarlo por todos los puertos) y sólo lo reenvía por los puertos donde existen

estaciones finales que desean ese tráfico.

ARP (Address Resolution Protocol). Permite a un router o a una estación final lanzar

una consulta broadcast dentro de una red para averiguar cuál es la dirección hardware29

correspondiente a una dirección IP determinada. Las PDUs de ARP se encapsulan en

tramas de capa 2 (p. ej. Ethernet).

29 Se utiliza la expresión general “dirección hardware”. En el caso particular de LANs IEEE 802, se trataría de direcciones MAC.


65 de 143 Rev. 1

RARP (Reverse Address Resolution Protocol). De manera inversa al ARP, permite

consultar la dirección IP correspondiente a una dirección hardware determinada.

Igualmente, las PDUs de RARP se encapsulan en tramas de capa 2.

f) Protocolos TCP y UDP Tal como sugiere el nombre del modelo TCP/IP, el protocolo más importante en la capa

de transporte es TCP (Transmission Control Protocol). Su principal función es

proporcionar una comunicación fiable basándose en un protocolo subyacente (IP) no

fiable. Para ello, establece conexiones lógicas entre las entidades TCP de ambas

estaciones finales y proporciona los mecanismos para asegurarse de que los datos no se

pierden, no se duplican y llegan en el orden correcto.

Las PDUs de TCP, denominadas segmentos, incluyen direcciones de origen y de

destino, denominadas puertos. La existencia de diferentes puertos permite que entre dos

estaciones finales determinadas (identificadas por sus direcciones IP) se puedan

establecer varias conexiones simultáneamente, cada una de ellas con usos diferentes. La

Tabla 3 muestra algunos puertos reservados para el uso de determinados protocolos de

aplicación (capa inmediatamente superior).

Puerto TCP Protocolo

20 FTP (Datos)

21 FTP (Control)

23 TELNET

25 SMTP

80 HTTP

161 SNMP

Tabla 3. Puertos TCP reservados.

Hay protocolos de aplicación que requieren de un intercambio de información mínimo.

En este caso no resulta razonable el esfuerzo por establecer la conexión lógica antes del

intercambio efectivo de información y eliminarla después. En estos casos se utiliza el

protocolo UDP (User Datagram Protocol), que no ofrece ningún mecanismo para

asegurar la comunicación fiable. Este hecho debe ser tenido en cuenta por los protocolos

de aplicación que se apoyen en él.


66 de 143 Rev. 1

Las PDUs de UDP, denominadas datagramas, incluyen igualmente direcciones de

origen y destino (puertos). En la Tabla 4, se muestran algunos puertos reservados para

protocolos de aplicación de uso corriente:

Puerto UDP Protocolo

53 DNS

67 DHCP (Servidor)

68 DHCP (Cliente)

69 TFTP

123 NTP

161 SNMP

Tabla 4. Puertos UDP reservados.

g) Protocolos de aplicación TCP/IP Los protocolos de aplicación TCP/IP dan servicios de comunicaciones concretos

comúnmente requeridos por las aplicaciones de usuario distribuidas en varias estaciones

finales. Quedan justo por encima del nivel de transporte, es decir, se apoyan en los

servicios que proporciona el protocolo TCP o bien el UDP. Todos los protocolos de

aplicación TCP/IP se basan en el modelo cliente / servidor. A continuación se comentan

los más destacados:

SNMP (Simple Network Management Protocol). Este protocolo se apoya sobre UDP y

proporciona los medios para realizar gestión de red, es decir, para automatizar la

monitorización del estado de los diferentes elementos activos de la red, de modo que se

faciliten las tareas de diagnóstico de problemas. SNMP permite realizar las siguientes

funciones desde una estación de gestión:

• Consultar el estado de elementos activos de red.

• Configurar algunos aspectos de dichos elementos.

• Permitir que los elementos de red puedan informar al gestor por iniciativa

propia, en caso de eventos importantes.

SMTP (Simple Mail Transfer Protocol). Este protocolo especifica la manera de

transferir correo electrónico (pero no su formato). Una vez que el programa de usuario


67 de 143 Rev. 1

genera el correo electrónico a partir de las entradas del usuario, lo coloca en la cola de

correo de salida. Entonces el programa SMTP inicia un proceso en 3 fases:

• La estación emisora establece una conexión TCP con la estación destinataria en

el puerto 25. Ambas estaciones intercambian mensajes preliminares

estandarizados por SMTP.

• Se produce la transferencia de uno o más mensajes de correo.

• Se cierra la conexión, primero a nivel de comandos SMTP y después la propia

conexión TCP.

TELNET. Permite que un usuario en una terminal pueda acceder a recursos y

aplicaciones de un ordenador remoto a través de una red. Para permitir la conexión de

terminales heterogéneas a ordenadores también heterogéneos, TELNET define una

terminal virtual normalizada. La terminal establece una conexión TCP (en el puerto 23)

con el ordenador remoto. La terminal presenta la terminal virtual al usuario, recoge la

información del usuario y la transmite al ordenador remoto, actuando como cliente. A

su vez, el ordenador remoto da respuesta a las peticiones de la terminal, actuando como

servidor. El resultado es que el usuario tiene la percepción de estar conectado

directamente al ordenador remoto.

FTP (File Transfer Protocol). Proporciona un entorno interactivo para el acceso a

ficheros ubicados en ordenadores remotos. El cliente establece una conexión TCP

(puerto 21) con el servidor, que servirá para intercambiar información de control

durante la sesión FTP. A través de esta conexión, el cliente puede presentar al usuario

un entorno interactivo basado en línea de comandos. Cada vez que el usuario ordena la

transferencia de un fichero se abre una conexión TCP (puerto 20) exclusiva para ese

fichero y cuando acaba la transferencia se libera dicha conexión. La conexión TCP de

control se libera cuando se cierra la sesión FTP.

TFTP (Trivial File Transfer Protocol). También permite acceso a ficheros remotos,

pero es más simple que FTP y no ofrece un entorno interactivo. Tampoco requiere

varias conexiones TCP concurrentes. De hecho se apoya sobre UDP (puerto 69).

DNS (Domain Name System). En Internet, cada estación queda identificada por su

dirección IP. Sin embargo, trabajar con direcciones IP resulta engorroso. El servicio


68 de 143 Rev. 1

DNS es el que permite trabajar con nombres de dominio, en vez de con direcciones IP.

El sistema de nombres de dominio está organizado jerárquicamente: A partir de unos

dominios genéricos (.com para uso comercial, edu para uso educativo, org para

organizaciones no lucrativas, etc) se van definiendo subdominios de niveles inferiores

como upm.es o como fi.upm.es. Esta información reside en una base de datos

disponible en la red a través de servidores DNS. Cuando una estación necesita saber la

IP asignada a un cierto dominio, a través de un programa cliente (resolutor), envía un

datagrama UDP (puerto 53) a un servidor DNS local. En respuesta, el servidor le facilita

la dirección IP asociada.

HTTP (Hyper Text Transfer Protocol). Es el protocolo que permite descargar las

páginas web de Internet. Una vez que el navegador residente en la estación recibe del

servicio DNS la dirección IP correspondiente al servidor de un cierto dominio, el

navegador establece una conexión TCP por el puerto 80 con dicho servidor. A partir de

ahí, el protocolo HTTP se ocupa de descargar la página web: un fichero HTML

residente en el servidor.

DCOM (Distributed Component Object Model). Este protocolo permitía ejecutar

llamadas a procedimientos remotos (RPC, Remote Procedure Call).

NTP (Network Time Protocol). La versión actual de este protocolo (NTPv4), queda

especificada por el RFC 5905 [52]. NTP es un protocolo de sincronización concebido

para distribuir la señal horaria a través de las redes públicas (Internet) y hasta las redes

privadas (LANs). Prevé tres modos de operación, que se corresponden con las tres

funciones diferentes que pueden adoptar las estaciones finales, dentro de la jerarquía

descendente en el modelo de subred NTP:

• Servidor primario. Su reloj de sistema está sincronizado con un reloj de

referencia UTC por medio de cable o radio (GPS, Galileo, etc.). Utiliza el

protocolo NTP como medio para proporcionar su hora a otras estaciones finales


69 de 143 Rev. 1

situadas aguas abajo, dentro del modelo de subred NTP. Típicamente cada país

debería tener varios servidores primarios NTP30.

• Cliente. Utiliza el protocolo NTP para sincronizar su reloj de sistema a partir de

uno o varios servidores (primarios o secundarios), situados aguas arriba, dentro

del modelo de subred NTP. Típicamente, cualquier estación final con un reloj de

sistema en tiempo real podría beneficiarse de la sincronización NTP.

• Servidor secundario. Tiene uno o varios servidores primarios aguas arriba (ante

los cuales se comporta como cliente) y uno o varios clientes aguas abajo (ante

los cuales se comporta como servidor). Típicamente, en cada LAN debería haber

al menos un servidor secundario NTP31.

Posee algoritmos destinados a mitigar los errores que pueden resultar de fallos en las

redes o en los servidores. Típicamente, la precisión que se puede conseguir entre

servidores secundarios y clientes en una “LAN rápida”32 puede ser de:

• Pocas decenas de milisegundos, si se sincroniza una vez al día.

• Pocas centenas de microsegundos, si se sincroniza cada 15 minutos.

SNTP (Simple Network Time Protocol). La versión actual de este protocolo (SNTPv4),

es un subconjunto perfecto de NTPv4, de modo que está especificado en el mismo RFC

5905 [52]. SNTP es una versión simplificada destinada a:

• Servidores primarios con una sola fuente de hora.

• Clientes con un solo servidor de hora.

Los servidores secundarios típicamente implementan NTP para poder acceder a varios

servidores primarios.

h) Hardware Con este subapartado se cierra el repaso al cuerpo de conocimiento que constituye el

estado de la técnica previo a la aparición de Ethernet Industrial (background). Por lo que

30 Actualmente, en España hay alrededor de 20 servidores NTP primarios. 31 Incluso si la LAN no está conectada a Internet, puede ser necesario mantener todas estaciones finales sincronizadas con un reloj maestro, manteniendo una cierta precisión. En esa situación, la estación final elegida como maestra actuaría como servidor NTP y ofrecería la hora global de la LAN, aunque esa hora no estuviera sincronizada con la hora UTC. 32 Se reproduce aquí la expresión utilizada por el RFC 5905 [R432]. Se entiende que una red Fast Ethernet sería conforme a esta descripción.


70 de 143 Rev. 1

respecta al hardware, ese estado previo consiste en implementaciones destinadas a

entornos ofimáticos, en primera instancia, y residenciales, más tarde. A continuación, se

muestra una lista no exhaustiva de los tipos de dispositivos hardware con una interfaz

Ethernet que podían existir en este estadio:

• Elementos estructurales de comunicaciones: conversores de medio (repetidores)

switches y puntos de acceso WI-FI (puentes), routers, etc.

• Ordenadores servidores situados en CPDs (Centros de Proceso de Datos).

• Ordenadores Personales en puestos de trabajo.

• Impresoras, fotocopiadoras, etc.

• Cámaras de video (CCTV) sobre IP.

• Teléfonos sobre IP.

Naturalmente, el entorno al que estaban destinados estos dispositivos condicionaba las

características de sus diseños de hardware. A continuación se resumen las características

más estrechamente vinculadas con el entorno:

• Selección de chips y diseños electrónicos concebidos para ambientes poco

agresivos:

o Temperaturas reguladas o con fluctuaciones lentas.

o Humedad moderada.

o Entorno EMC moderado.

o A penas existencia de polvo, vibraciones, agresividad química.

• Entradas de alimentación a 230 Vac.

• Carcasas previstas para colocación en sobremesa o bien en racks normalizados

de 19”.

Otras características venían marcadas por la propia tecnología Ethernet. De acuerdo con

[53], las opciones de diseño de hardware típicas para Fast Ethernet33 son las expuestas a

continuación. (Se sigue un orden ascendente, desde el medio de transmisión y a través

de las capas del modelo TCP/IP).

33 Fast Ethernet es la tecnología Ethernet (capa física) que ha servido de base para la mayoría de propuestas de Ethernet Industrial.


71 de 143 Rev. 1

• Medio de transmisión: Cableado de pares trenzados sin apantallar (UTP)

Categoría 5.

• Conectores: RJ-45.

• Transformadores. Existe un transformador para cada uno de los pares (TX y

RX), que proporciona separación galvánica entre la electrónica interior y el

cableado exterior.

• PHY: Existen chips especializados (PHYTERs) que implementan la capa física

totalmente en hardware (sin necesidad de codificar ningún software) y que están

fácilmente disponibles en el mercado (COTS, Commercial-Of-The-Shelf). El

PHYTER se conecta, por un lado, a los transformadores para transmitir y recibir

las señales analógicas que se propagan por el medio. Por otro lado, se comunica

a través de una interfaz digital con otro chip que implementa la subcapa MAC.

Esta interfaz digital es la MII (Media Independent Interface), que está

especificada en IEEE 802.3 y que consta de dos partes:

o Un bus de datos de cuatro líneas de amplitud (nible).

o Señales de control (MIIM, Media Independent Interface Management).

Existen alternativas al MII, con diferentes amplitudes en el bus de datos:

o RMII (Reduced MII), cuyo bus de datos tiene dos líneas.

o SMII (Serial MII), cuyo bus de datos es serie (sólo tiene una línea).

A continuación se muestra el diagrama funcional de un PHYTER

comercialmente disponible.

Fig. 19. Diagrama funcional del PHYTER KSZ8051/31, de MICREL.

Una alternativa para implementar la capa PHY consiste en utilizar chips que

incluyen switches de tres puertos, como el mostrado en la Fig. 20.


72 de 143 Rev. 1

Fig. 20. Diagrama funcional de un switch de tres puertos.

Al igual que el PHYTER de la Fig. 19, este chip se comunica con otro que

implementa la subcapa MAC a través de un interfaz MII o RMII. En cambio,

hacia el lado del medio de transmisión, incluye dos PHYTERs preparados para

conectarse a los transformadores y los conectores RJ-45 correspondientes. Los

dispositivos Ethernet que incorporan este diseño permite conectarse en una

topología de línea o daisy-chain.

• MAC: La subcapa MAC también se encuentra totalmente implementada en

hardware dentro de productos COTS. Sin embargo, no suele estar en chips

dedicados exclusivamente a esta función sino que se combina con otras

funciones en un chip común. Por ejemplo, existen microprocesadores y

microcontroladores que tienen incorporado un controlador MAC con una

interfaz MII o RMII listo para conectarse con un PHYTER tal como ilustra la

Fig. 19 o con un switch de tres puertos (Fig. 20). También existen FPGAs que

incorporan controladores MAC; en este caso es más frecuente que utilicen un

interfaz SMII, por su menor necesidad de pines. Otra posibilidad es que el

controlador MAC se combine con el PHYTER en un solo chip, dando lugar a un

controlador Ethernet como el que se ilustra en la Fig. 21.


73 de 143 Rev. 1

Fig. 21. Diagrama funcional del Controlador Ethernet KSZ8841, de MICREL.

En este caso, la interfaz MII o equivalente es interna al chip. Las interfaces

externas son, hacia abajo, con los transformadores y, hacia arriba, con el

dispositivo programable de la estación final (host). Las posibilidades aquí son

una interfaz PCI de 32 bits o una interfaz genérica de 8/16/32 bits.

• Capa de red y de transporte. Las capas de red y de transporte no se encuentran

implementadas en hardware. En cambio, existen codificaciones (software)

comercialmente disponible para las diferentes familias de dispositivos

programables de la estación final. Estos paquetes de código reciben el nombre

de stacks TCP/IP e implementan los protocolos TCP,UDP e IP.

• Capa de aplicación. Igual que en el caso anterior, los diferentes protocolos de

aplicación que pueda requerir la estación final (FTP, SMTP, etc.) deberán ser

implementados en software.

Por último, existe la opción de incluir todo el hardware necesario (PHY+MAC+HOST

programable) en un solo chip (SoC, System on Chip), tal como ilustra la Fig. 22.


74 de 143 Rev. 1

Fig. 22. Diagrama funcional del SoC KSZ8695P, de MICREL.

Un sistema de este estilo se podría conectar directamente a los transformadores de los

pares trenzados y permitiría acoger en su interior el software del stack TCP/IP, de los

protocolos de aplicación necesarios e incluso de la propia aplicación de usuario.

En definitiva, cualquiera de las opciones de diseño anteriores tienen en común dos

puntos:

• Las capas correspondientes a Ethernet (PHY+MAC) siempre se implementan

sobre hardware.

• El resto de capas del modelo TCP/IP siempre se implementan sobre software.

3.2.2 Salto evolutivo

a) Introducción A principios de la década de 2000, los principales fabricantes del sector de la

Automatización Industrial lanzaron las primeras propuestas para introducir Ethernet en

las plantas de producción (Ethernet Industrial). A continuación, se muestra una lista no

exhaustiva de los tipos de dispositivos susceptibles de incorporar una interfaz Ethernet

en un entorno industrial:

• Elementos estructurales de comunicaciones (hubs, switches, conversores de

medio,...).


75 de 143 Rev. 1

• Controladores: PLCs (Programmable Logic Controllers) o PCs industriales.

• Módulos de entradas / salidas remotas.

• Equipos industriales con electrónica de control incorporada (SAIs,

accionamientos, centralitas de incendios, grupos electrógenos, máquinas

enfriadoras, etc.).

• Equipos de medida (analizadores de red, sensores inteligentes, etc.).

El primer rasgo diferencial de estos dispositivos Ethernet respecto a los que existían

hasta entonces (a parte de la función desempeñada) consistía en las características de su

diseño de hardware. [54] ha establecido una comparativa entre las características del

diseño de hardware de un entorno ofimático / residencial y las uno industrial, que se

resume en la Tabla 5.

Entorno ofimático / residencial Entorno industrial

Instalación básica del edificio fija (cableado estructurado). Conexiones a los puestos de trabajo variables.

Instalación hecha a medida para la aplicación industrial: Apenas cambia.

Cables situados en falsos suelos o techos. En ocasiones los cables deben permitir su instalación en canalizaciones móviles.

Uso predominante de cable de par trenzado UTP Cat 5.

Uso predominante del cable UTP Cat 5, pero mayor presencia de la fibra óptica.

Uso predominante del conector RJ-45, sin requisitos de estanquidad.

Uso compartido de conectores RJ-45 y M-12, con implementaciones que cuidan la resistencia mecánica y la estanquidad (grado de protección IP).

Alimentaciones a 230 Vac o bien PoE Alimentaciones a 24 Vdc (en ocasiones redundadas) o bien PoE

Topología en anillo para el backbone. Topología en estrella para el acceso a los dispositivos terminales

Topología en anillo para el backbone, si hay. Uso habitual de topología en línea para el acceso a los dispositivos terminales.

Carcasas previstas para montaje en bastidor de 19” (servidores) o en sobremesa (estaciones de trabajo)

Carcasas previstas para montaje sobre carril DIN, dentro de envolvente industrial.

Dispositivos con refrigeración activa (ventiladores) Dispositivos con refrigeración pasiva (radiadores) para evitar partes en movimiento.

No se incorporan contactos libres de potencial. Los elementos estructurales de comunicaciones suelen incorporar un contacto libre de potencial para señalizar avería.

Temperaturas moderadas con fluctuaciones lentas. Temperaturas extremas con grandes fluctuaciones.

Escasa presencia de polvo y humedad. Presencia abundante de polvo. Probable presencia de humedad e incluso agua.

Escasa presencia de vibraciones y choques. Probable existencia de vibraciones continuadas e incluso choques.

Nivel bajo de interferencias electromagnéticas (EMI)

Alto nivel de EMI.

Ausencia de peligros químicos. Probable presencia de ambientes químicamente agresivos.

Tabla 5. Características de diseño de hardware en entornos ofimático / residencial e industrial.


76 de 143 Rev. 1

Las propuestas de dispositivos Ethernet Industrial fueron progresivamente incorporando

los requisitos de diseño relativos al entorno industrial (Tabla 5). Sin embargo, por lo

que se refiere a la implementación de las comunicaciones, adoptaron sin cambios la

tecnología existente (véase subapartado 3.2.1.h):

• En las capas 1 y 2 (Ethernet), se adoptaron los componentes COTS existentes

para Fast Ethernet, aprovechando así su coste reducido.

• En las capas de red y de transporte, se aprovecharon los stacks TCP/IP

existentes y se incorporaron a dispositivos programables de propósito general.

Así pues, las diferentes propuestas de Ethernet Industrial, son realmente protocolos de

aplicación que se basan sobre la arquitectura TCP/IP/Ethernet tal como es, es decir, sin

introducir ninguna modificación sobre dicha arquitectura que pretenda mejorar su

comportamiento en aspectos clave para las aplicaciones industriales más exigentes

(tiempo real, tolerancia al fallo). Normalmente, estos protocolos se basan directamente

en TCP y/o UDP, según ilustra la Fig. 23.

Fig. 23. Arquitectura típica de los protocolos Ethernet Industrial.

En paralelo con el protocolo Ethernet Industrial propiamente dicho, también suelen

operar otros protocolos de aplicación que permiten a los dispositivos Ethernet Industrial

disfrutar de las funcionalidades típicas de las Tecnologías de la Información:


77 de 143 Rev. 1

Transferencia de ficheros (FTP), envío de e-mails (SMTP), gestión de red (SNMP),

sincronización horaria (SNTP), etc. En los siguientes subapartados, se exponen las

características específicas de cada una de las propuestas que pueden considerarse de

Ethernet Industrial.

b) Modbus TCP La organización promotora de Modbus TCP (y de su precursor Modbus Serie) es

Modbus-IDA [55]. La especificación de Modbus TCP, se compone de dos documentos

públicamente accesibles:

• El primero [56] hereda de la especificación original de Modbus Serie la parte

que se mantiene común para ambos: La PDU básica de Modbus, los códigos de

función, etc.

• El segundo [57] especifica el servicio de mensajería de Modbus sobre TCP/IP y

el modelo funcional de un cliente, un servidor y una pasarela Modbus TCP a

Modbus serie.

Modbus TCP hereda de su precursor Modbus Serie su simplicidad: No prevé perfiles de

dispositivos, ni objetos para la gestión de red (SNMP), ni mecanismos de

sincronización. Simplemente establece un mecanismo de intercambio de datos según el

modelo cliente – servidor, basándose en los servicios del protocolo TCP (puerto 502).

En efecto, un dispositivo cliente (equivalente al maestro de la especificación para bus

serie) se encarga de hacer consultas sucesivas (polling) a los diferentes dispositivos

servidores (esclavos en Modbus serie). El intercambio y el formato de las tramas quedan

ilustrados en la siguiente Fig. 24.


78 de 143 Rev. 1

Fig. 24. Intercambio de tramas Modbus TCP.

Como se puede observar, las tramas Ethernet contendrán las correspondientes cabeceras

IP y TCP antes de la PDU Modbus TCP, cuyos campos se comentan a continuación:

• Identificador de Transacción (2 octetos): Contiene un valor marcado por el

cliente y copiado por el servidor en su PDU de respuesta. Este valor permite al

cliente emparejar cada respuesta recibida con su consulta correspondiente.

• Identificador de Protocolo (2 octetos): Este campo permitiría una hipotética

multiplexación de diferentes protocolos. En la práctica, siempre tiene el valor

“0”, denotando “Modbus”.

• Longitud (2 octetos): Indica la longitud en octetos de los siguientes campos

(Identificador de Unidad, Código de Función y Datos).

• Identificador de Unidad (1 octeto): Tiene una función de direccionamiento

interna al sistema Modbus. Cuando el servidor al que va dirigida la trama es una

pasarela Modbus TCP / Modbus serie (con un dirección IP única), este campo

sirve para indicar a qué participante del bus serie va dirigida la consulta, de

modo que la pasarela pueda reenviar la consulta en el formato propio de Modbus

serie. La respuesta hacia el cliente mantendrá el mismo valor en este campo.

• Código de Función Modbus (1 octeto): En este campo el cliente indica al

servidor la acción a ejecutar. Puede tomar cualquier valor entre 1 y 255.

• Datos (0...252 octetos): En una consulta emitida por un cliente, este campo

contiene información adicional para acabar de especificar la operación indicada


79 de 143 Rev. 1

por el Código de Función Modbus. Si dicho código indica por sí mismo

inequívocamente la acción a ejecutar, este campo es inexistente (longitud “0”).

En una respuesta de un servidor, este campo contiene la información requerida

por el cliente. La longitud máxima de este campo viene impuesta por una

restricción del original Modbus serie y es de 252 octetos.

Fig. 25. Principio de funcionamiento de Modbus TCP.

Tal como se ha mencionado anteriormente, el principio de funcionamiento de Modbus

TCP es por consulta (polling) (véase Fig. 25). Un solo cliente (que actúa como maestro)

envía consultas sucesivas a cada uno de los servidores; Los servidores (que actúan como

esclavos) responden proporcionando la información requerida. En cada ciclo consulta /

respuesta, se atraviesa cuatro veces el stack TCP/IP, lo cual hace que el rendimiento

general del intercambio dependa especialmente en la eficiencia de la implementación de

dicho stack, tanto en el cliente como en el servidor. Típicamente, el tiempo de respuesta

de cada esclavo puede ser del orden de 20 ms34.

Algunas implementaciones de cliente (maestro) optimizan el proceso global enviando

varias consultas de manera sucesiva y esperando a que los servidores (esclavos) 34 En caso de pérdida de una trama (por ejemplo, por error en la comprobación del FCS) el mecanismo de reintentos del stack TCP/IP asegurará que el cliente recibe la información. Sin embargo, el tiempo de respuesta puede ascender al orden de los segundos.


80 de 143 Rev. 1

procesen las respuestas en paralelo. El campo de Identificador de Transacción en las

PDUs asegura que el cliente podrá atribuir cada respuesta a la consulta correcta.

c) EtherNet/IP La organización promotora de EtherNet/IP es ODVA [58]. EtherNet/IP queda

enmarcada dentro un sistema de automatización más amplio, denominado CIP

(Common Industrial Protocol), que engloba también otros protocolos tradicionalmente

considerados como buses de campo: ControlNet, DeviceNet y CompoNet. Tal como

ilustra la siguiente Fig. 26, CIP aporta una capa de aplicación común para todos esos

protocolos, de modo que permite implementar soluciones de automatización que

combinen, por ejemplo, redes DeviceNet con redes EtherNet/IP.

Fig. 26. Stack de protocolos de EtherNet/IP.

Además, CIP aporta funcionalidades que exceden de la capa de aplicación y se internan

en la propia aplicación de usuario, como son los diferentes perfiles de dispositivo

(válvulas, dispositivos I/O, robots, etc.).

De acuerdo con [59], las comunicaciones en la capa de aplicación CIP se organizan en

dos tipos de conexiones:

• Conexiones CIP explícitas. Son de naturaleza consulta / respuesta entre dos

dispositivos determinados y de propósito general. Por ejemplo, la carga de un

programa en un controlador (PLC) se realiza mediante una conexión explícita.


81 de 143 Rev. 1

El término “explicita” se refiere a que todos los mensajes CIP incluyen

información básica (dirección origen, dirección destino, tipo de datos, etc.).

• Conexiones CIP implícitas. Están dedicadas a la transmisión de información

crítica en el tiempo entre un productor y uno o más consumidores. Los mensajes

son enviados cíclicamente (cada RPI, Requested Packet Interval) sin que exista

un reconocimiento particular para cada uno de ellos. La comunicación entre

dispositivos de los estados I/O o del valor de una variable lógica (tag) son

ejemplos de conexiones implícitas. El término “implícita” hace referencia a que

la información básica (dirección origen, dirección destino, tipo de datos, etc.) no

está contenida de forma explícita en el mensaje.

En el caso de EtherNet/IP, las conexiones CIP se apoyan sobre conexiones TCP (puerto

2222). Una conexión TCP existente entre dos dispositivos EtherNet/IP puede soportar

múltiples conexiones CIP entre entidades de la capa CIP de ambos dispositivos. En el

caso de las conexiones CIP explícitas, el servicio proporcionado por la conexión TCP es

suficiente para cubrir todas las necesidades de comunicación. En el caso de las

conexiones CIP implícitas, sin embargo, la conexión TCP sólo se utiliza para el

establecimiento de la conexión CIP, tal como ilustra la siguiente Fig. 27.

Fig. 27. Patrón de una conexión CIP implícita.

En efecto, según [60], el dispositivo que pretende establecer la conexión CIP implícita

(p. ej. un PLC) envía al dispositivo objetivo (p. ej. un rack remoto de I/Os) un mensaje

de negociación, haciendo uso de la conexión TCP previamente establecida. En este

mensaje, se indican los objetos de datos requeridos y la periodicidad (RPI) con que se


82 de 143 Rev. 1

deben refrescar, así como un identificador de conexión CIP. Si el dispositivo objetivo

puede satisfacer los requisitos del mensaje inicial, comenzará a actuar como productor,

enviando mensajes cíclicamente al ritmo requerido (RPI) sobre UDP (puerto 2222).

Estos mensajes contendrán los datos requeridos, el identificador de conexión CIP

correspondiente y una dirección IP multicast relacionada, que permitirá a múltiples

dispositivos (no sólo al que hizo la petición inicial) actuar como consumidores de la

información.

El dispositivo productor, continuará enviando mensajes sobre UDP de manera

indefinida mientras exista algún consumidor interesado en ellos. Dado que la

comunicación sobre UDP es no reconocida, los consumidores envían periódicamente un

mensaje de heartbeat para que el productor sepa que debe mantener la conexión.

Cuando transcurre un cierto tiempo sin haber recibido ningún mensaje de hearbeat, el

productor deja de transmitir y da por finalizada la conexión CIP implícita.

El mecanismo productor / consumidor expuesto anteriormente es eficiente cuando

existen varios dispositivos que requieren la misma información cíclica. Sin embargo, el

tráfico multicast generado puede tener efectos negativos:

• Sobrecarga de la red: Tradicionalmente los switches trataban una trama multicast

reenviándola a través de todos los puertos (flooding). Este comportamiento,

unido a la naturaleza cíclica de la transmisión (cada productor puede enviar un

mensaje multicast cada 10 ms, por ejemplo) puede fácilmente sobrecargar la red.

• Sobrecarga de los dispositivos: El mecanismo de flooding en la red hace que un

dispositivo cualquiera reciba los mensajes multicast, incluso aunque no esté

interesado en ellos. El dispositivo tiene que procesar este mensaje antes de

decidir que no le interesa, lo cual supone una sobrecarga.

En definitiva, es cierto que EtherNet/IP funciona sobre redes de switched Ethernet

totalmente estándar, pero no sobre cualquier red switched Ethernet. [61] y [59]

establecen los siguientes requisitos y recomendaciones:


83 de 143 Rev. 1

• Full-duplex. Todos los puertos deben operar en modo full-duplex. Para ello, se

recomienda no deshabilitar la opción de autonegociación de los dispositivos, ya

que, en ese caso, el puerto correspondiente del switch pasa a modo half-duplex.

• IGMP snooping. Los switches deben implementar IGMP snooping, de modo que

el tráfico multicast quede restringido únicamente a los caminos necesarios para

dar servicio a los dispositivos que lo requieren (véase subapartado 3.2.1.e). Hay

que tener en cuenta que algunos switches que implementan IGMP snooping

requieren de un router que envíe consultas (host membership querys) para poder

aprender qué dispositivos pertenecen a cada grupo multicast. Por tanto, si la red

debe funcionar de modo aislado (sin presencia de ningún router) o bien si debe

funcionar incluso si el router queda fuera de servicio, entonces debe confirmarse

que los switches pueden operar IGMP snooping incluso sin presencia de router.

• Port mirroring. Los switches deben implementar port mirroring. Se trata de una

funcionalidad de diagnóstico que duplica el tráfico que atraviesa un puerto

determinado del switch (tanto entrante como saliente) y lo reenvía por otro

puerto libre del switch . Conectando a este puerto un PC con un software de

análisis de tráfico Ethernet (como Wireshark [62]), se puede realizar tareas de

resolución de averías.

• VLANs. Se recomienda el uso de VLANs como un medio adicional para

restringir el tráfico multicast.

• SNMP. Se recomienda que los switches sean gestionables, es decir, que

implementen el protocolo SNMP, lo cual facilita tareas de diagnósitco y

configuración remotas.

En 2008, se introdujo en la especificación de EtherNet/IP la tecnología DLR (Device

Level Ring), permitiendo las topologías en anillo y en línea, que se sumaban a la

topología en estrella, propia de las redes switched Ethernet. [63] expone las

características de esta tecnología, que se resumen a continuación.

La topología en anillo proporciona redundancia de caminos físicos hasta el mismo

dispositivo EtherNet/IP y, por tanto, tolerancia al fallo a nivel de enlaces físicos e

interfaces. Si el fallo ocurre en el propio dispositivo EtherNet/IP (en adelante nodo), el


84 de 143 Rev. 1

resto de nodos continuarán teniendo servicio. Los nodos del anillo DLR tienen

características especiales:

• Incorporan switches especiales de dos puertos exteriores (y uno interior para el

host), que implementan un protocolo propietario (DLR) de capa 2 para gestionar

la configuración del anillo. Es posible incorporar dispositivos EtherNet/IP

estándar en el anillo, a través de switches DLR de tres puertos exteriores.

• Al menos uno de los nodos, debe implementar la funcionalidad de nodo

supervisor, tal como se ilustra en la Fig. 28.

Fig. 28. Topología en anillo DLR.

A continuación se expone el principio de funcionamiento:

• Al menos uno de los nodos debe configurarse como nodo supervisor del anillo.

Si se configura más de uno, el propio protocolo DLR decide cuál de ellos actúa

como nodo supervisor activo y el otro queda como backup.

• Cada nodo normal, cuando recibe una trama, la reenvía por el otro puerto, a no

ser que la trama fuera dirigida a él mismo.

• El nodo supervisor activo tiene uno de sus puertos bloqueado, evitando así la

formación de un bucle, tal como se ilustra en la Fig. 28.

• Cada 400 μs, por defecto, el nodo supervisor activo envía unas tramas beacon

(propias del protocolo DLR) por sus dos puertos y espera su recepción por el

lado opuesto del anillo. Si no las recibe, interpreta un fallo en el anillo y

desbloquea su propio puerto para mantener la conectividad. Típicamente, la

recuperación de un anillo de 50 nodos se consigue en menos de 3 ms.


85 de 143 Rev. 1

Fig. 29. Diagnósitco del anillo DLR.

Aunque la topología nativa de la tecnología DLR es el anillo, también permite otras

posibilidades. Si se renuncia a la redundancia de caminos físicos una red DLR se puede

disponer en línea. Así mismo, es posible integrar uno o más anillos DLR en una red

switched Ethernet estándar, tal como ilustra la Fig. 30.

Fig. 30. Integración de anillos DLR en redes Ethernet estándar.

Sin embargo, en este caso hay que tener en cuenta las siguientes salvedades:


86 de 143 Rev. 1

• El hecho de intercalar en el anillo DLR un switch estándar puede afectar al

tiempo de recuperación del anillo, en caso de fallo.

• Para el funcionamiento correcto del anillo es necesario configurar de manera

apropiada los puertos del switch estándar que forman parte de él.

• El protocolo DLR puede coexistir con los protocolos equivalentes de la red

Ethernet estándar (STP, RSTP, MSTP) pero no interactúa con ellos: Las tramas

BPDUs enviadas por los switches estándar son bloqueadas por el nodo

supervisor del anillo, de modo que la topología activa del anillo queda

únicamente determinada por el protocolo DLR.

• Si se integran varios anillos DLR en una red Ethernet, hay que tomar la

precaución de configurar cada anillo con una VID (identificador de VLAN)

independiente35.

d) PROFINET CBA El protocolo PROFINET CBA (Component Based Automation) es promovido por la

organización PROFIBUS International [64], que también promueve el bus de campo

PROFIBUS DP. PROFINET CBA fue el primer intento de introducir PROFIBUS DP

en el ámbito de Ethernet Industrial. Su propósito no era hacer evolucionar PROFIBUS

DP hacia una versión compatible con Ethernet, sino permitir la implementación de

pasarelas (proxys) que integraran las instalaciones PROFIBUS DP existentes en

infraestructuras de Ethernet Industrial, tal como ilustra la Fig. 31.

35 Las switches incorporados en los dispositivos DLR envían tramas VLAN-tagged


87 de 143 Rev. 1

Fig. 31. Ejemplo de utilización de PROFINET CBA.

Más tarde, se desarrolló PROFINET IO (véase apartado 3.3.2.c) -que sí tiene

capacidades equivalentes a PROFINET DP- y PROFINET CBA mantuvo su papel

como protocolo destinado a comunicación entre controladores, sin requerimientos

temporales exigentes.

PROFINET CBA soporta un enfoque de la automatización de la planta industrial

basado en la comunicación de componentes entre sí, dentro de un sistema distribuido.

Un componente está típicamente formado por un controlador IO y sus dispositivos IO

(comunicados entre sí por PROFIBUS DP o por PROFINET IO) y puede encargarse del

control de toda una máquina. Un sistema distribuido puede ser típicamente toda una

planta industrial. PROFINET CBA va asociado a una herramienta de software de

ingeniería (SIMATIC iMAP) que permite establecer de manera gráfica los vínculos

entre los componentes, es decir, las variables que deben comunicarse entre los

diferentes controladores IO.

PROFINET CBA funciona a base de llamadas a procedimientos remotos (RPC, Remote

Procedure Call). En su versión original se apoyaba sobre el protocolo de aplicación

DCOM (Distributed Component Object Model), que a su vez utilizaba conexiones


88 de 143 Rev. 1

TCP/IP. Sin embargo, cuando DCOM fue abandonada por su desarrollador (Microsoft),

se especificó una nueva versión, basada sobre el protocolo CLRPC (Connectionless

Remote Procedure Call) que a su vez se apoya sobre UDP/IP.

3.2.3 Productos de mercado

En este subapartado, se pretende dar un breve repaso a las diferentes gamas de

productos existentes en el mercado y que se pueden considerar dentro de la categoría de

Ethernet Industrial.

Hubs o repetidores multipuerto. En su momento, fueron los elementos estructurales

más comunes para formar redes Ethernet sobre par trenzado. Después, fueron

progresivamente desplazados por los switches hasta el punto que actualmente son

totalmente inexistentes en el mercado destinado al entorno ofimático. En el mercado

destinado al entorno industrial, la tendencia es la misma. Sin embargo, todavía tienen

una mínima representación debido a que uno de los protocolos más representativos de

Ethernet en Tiempo Real (Ethernet Powerlink) recomienda su uso frente al de los

switches. El motivo es que los hubs, precisamente por implementar menos

funcionalidades, introducen una latencia menor, del orden de 500 ns. Los fabricantes

Phoenix Contact [15] y Schneider Electric [20], por ejemplo, todavía cuentan con hubs

en su catálogo.

Switches o puentes multipuerto. Los switches de Fast Ethernet (100BASE-TX y

100BASE-FX) son los elementos estructurales predominantes en las redes Ethernet

Industrial. Muchos grandes fabricantes del mundo de la Automatización Industrial han

incorporado estos productos en su catálogo como un complemento más, por ejemplo:

Phoenix Contact [15], Schneider Electric [20], Rockwell Automation [16], Siemens [13]

y Moxa [23]. En cambio, existen otros fabricantes cuyo núcleo de negocio se centra

precisamente en los switches industriales, por ejemplo: Hirschmann [25], Korenix [22]

y O-ring [24].

En los catálogos de todos estos fabricantes, se utiliza el término “gestionable”

(managed) para distinguir los equipos con prestaciones básicas respecto de los que

tienen prestaciones adicionales. Un switch no gestionable sería aquel que cumple


89 de 143 Rev. 1

estrictamente las funcionalidades obligatorias según la norma IEEE 802.1D, es decir,

básicamente reenvía o filtra las tramas en función del aprendizaje realizado sobre las

direcciones MAC de origen. En cambio, cuando se utiliza el término “gestionable”, se

alude a un conjunto de prestaciones adicionales como son:

• Funciones de gestión36, relacionadas con diferentes aspectos: configuración,

malfuncionamiento y estadísticas de desempeño.

• Posibilidad de acceder a las funciones de gestión de manera remota, mediante el

protocolo SNMP.

• Posibilidad de definir VLANs, de acuerdo con IEEE 802.1Q.

• Función de Port Mirroring.

Implementaciones COTS de Ethernet. Todas las propuestas de Ethernet Industrial

mencionadas en el subapartado 3.2.237, se basan en hardware estándar como el

explicado en el apartado 3.2.1.h. Existen diversos fabricantes de circuitos integrados

que incorporan en su catálogo implementaciones de la capa física (PHYTERs), de la

subcapa MAC (procesadores MAC), o de ambas simultáneamente (Controladores

Ethernet). También existen circuitos integrados que incorporan varios puertos MAC y

sirven como núcleo para switches autónomos o como complemento para dotar de varios

puertos (típicamente dos) a estaciones finales destinadas a conectarse en una topología

en línea. Algunos ejemplos de estos fabricantes son Micrel [65] y National

Semiconductor [66].

Productos Modbus TCP. Antes de que apareciera Modbus TCP, su predecesor

Modbus serie ya era un estándar muy extendido en el ámbito de las comunicaciones

industriales. Esto explica el hecho de que Modbus TCP también sea un protocolo

soportado por gran variedad de fabricantes. En todo caso, el fabricante que más ha

impulsado la utilización de Modbus TCP es Schneider Electric [20], que a su vez es

propietario de la marca Modicon, que originalmente desarrolló Modbus serie.

36 En el sentido estricto utilizado por la norma IEEE 802.1D, el término “gestionable” sólo haría referencia a este primer punto. Sin embargo, la utilización en el mercado suele aludir a la lista completa. En todo caso, esta utilización comercial del término hace recomendable investigar en la documentación técnica de cada producto en qué consiste exactamente este carácter “gestionable”. 37 Excepto los switches integrados en los dispositivos Ethernet/IP que soportan el protocolo DLR.


90 de 143 Rev. 1

Uno de los objetivos principales de Modbus TCP es permitir la integración de los

esclavos Modbus serie en una red Ethernet Industrial. Esto se consigue mediante una

pasarela que actúa como maestro en el bus serie y como servidor en la red Ethernet, por

ejemplo la TSXETG100, de Schneider Electric. Por otra parte, todas las gamas de PLCs

de Schneider Electric (Advantys, Momentum, Premium, M340, Quantum) soportan el

protocolo Modbus TCP y multitud de softwares SCADA/HMI, tanto de Schneider

Electric como de otros fabricantes, también.

En definitiva, Modbus TCP es ampliamente utilizado en los siguientes tipos de

comunicaciones:

• Entre aplicaciones SCADA / HMI y PLCs.

• Entre aplicaciones SCADA / HMI y dispositivos de campo (analizadores de red,

contadores eléctricos, SAIs, teleindicadores, etc.). Normalmente estos

dispositivos tienen un puerto Modbus serie y es necesaria una pasarela

intermedia.

• Entre PLCs.

Sin embargo, sus capacidades limitadas en cuanto al comportamiento en tiempo real

hacen que no se utilice para comunicación entre PLCs y módulos de entradas / salidas

remotas ni, por supuesto, en aplicaciones de control de movimiento.

Como se ha dicho anteriormente, durante muchos años Modbus TCP ha sido la apuesta

de Schneider Electric por lo que respecta a Ethernet Industrial. Sin embargo, en 2007,

Schneider Electric se adhirió a la organización ODVA [58] y anunció el lanzamiento al

mercado de productos con interfaz Ethernet/IP. Por su parte, la ODVA anunció que

proporcionaría compatibilidad con Modbus TCP en las redes basadas en CIP. Así pues,

parece que la especificación Modbus TCP no sufrirá mejoras ni mantenimiento, pero

probablemente los productos se mantendrán en el mercado durante mucho tiempo.

Productos Ethernet/IP. El principal fabricante de equipos con interfaz Ethernet/IP es

Rockwell Automation [17]. Esto incluye las diferentes gamas de PLCs (Control Logix,

Micro Logix, etc.), módulos de entradas / salidas remotas (Flex I/O, Control Logix I/O,

etc.), HMIs (PanelView), analizadores de red (Power Monitor), accionamientos


91 de 143 Rev. 1

(PowerFlex). Además, múltiples aplicaciones SCADA tienen drivers para Ethernet/IP.

En definitiva, Ethernet/IP se usa en los siguientes tipos de comunicaciones:

• Entre aplicaciones SCADA / HMI y PLCs.

• Entre aplicaciones SCADA / HMI y dispositivos de campo (p.ej. analizadores de

red).

• Entre PLCs.

• Entre PLC y módulos de entradas / salidas remotas o bien dispositivos de campo

(p.ej. analizadores de red y accionamientos).

Este último punto es una característica diferencial respecto de Modbus TCP. Ethernet/IP

se apoya sobre el stack TCP/IP estándar y no incorpora ninguna modificación para

mejorar su comportamiento en tiempo real, al igual que Modbus TCP. Además, un

argumento de venta utilizado por Ethernet/IP es que se puede usar en una red Ethernet

estándar y que puede admitir otros tráficos ajenos a Ethernet/IP, al igual que reivindica

Modbus TCP. Sin embargo, a diferencia de lo que ocurre con Modbus TCP, Ethernet/IP

se implementa en muchos productos para realizar comunicaciones que previsiblemente

tendrán ciertos requisitos temporales, como la comunicación entre PLC y módulos de

entradas salidas remotas. El cumplimiento de estos requisitos temporales (más o menos

exigentes en función de la aplicación industrial) dependerá de la habilidad con que se

haya planificado y configurado la red Ethernet y no está en absoluto asegurado

intrínsecamente en la concepción de Ethernet/IP.

En consonancia con lo anterior, Rockwell Automation y ODVA han establecido una

colaboración con Cisco (el fabricante de switches líder en el sector ofimático) que ha

dado como fruto toda una serie de guías para la concepción de redes Ethernet

industriales y la estimación de su desempeño (véase como ejemplo [61]). Además, la

gama alta de switches industriales de Rockwell reivindica la incorporación de

tecnología Cisco como signo de solvencia técnica [67].

Productos PROFINET CBA. El principal fabricante de productos que soportan

PROFINET CBA es Siemens [13]. El tipo de Ethernet Industrial por excelencia de

Siemens es PROFINET IO (explicado en el subapartado 3.3.2.c). Sin embargo, un


92 de 143 Rev. 1

subconjunto de todos los productos Siemens que soportan PROFINET IO soporta

también el protocolo PROFINET CBA, a través del mismo interfaz físico. A

continuación se repasa la naturaleza de estos dispositivos:

• Algunos módulos IM (Interface Module) de la gama ET200 con CPU

incorporada.

• Algunas CPUs y módulos de comunicaciones (CP, Communication Processors)

de la gama de PLCs S7-300 y S7-400.

• Una versión de controlador implementado en software para PC industrial

(WINAC RTX).

• La pasarela (proxy) IE/PB Link PN CBA38, para integrar controladores

PROFIBUS DP en la red de Ethernet Industrial.

• Driver OPC para PROFINET CBA, que permite a cualquier aplicación SCADA

/ HMI compatible con OPC acceder a la información procedente de un equipo

que comunica en PROFINET CBA.

En definitiva, PROFINET CBA se utiliza únicamente para establecer comunicaciones:

• Entre aplicaciones SCADA / HMI y controladores y

• Entre controladores (sean PLCs o PCs industriales)

Esto es debido a que PROFINET CBA no tiene capacidades de tiempo real (esta

necesidad queda cubierta por PROFINET IO). En cambio, el punto fuerte que reivindica

PROFINET CBA es su enfoque basado en componentes, que permite interconectar

diferentes islas de automatización en una planta industrial, mediante una herramienta de

ingeniería de estilo gráfico (SIMATIC iMAP). Aun así, la hegemonía de PROFINET IO

en el mundo Siemens es total y PROFINET CBA tiene poca aceptación en el mercado.

3.3 Ethernet en Tiempo Real (RTE)

En este apartado se desarrollará el concepto de Ethernet en Tiempo Real. Para ello, se

organizará el texto de la misma manera que en el apartado anterior. 38 Cabe destacar que esta pasarela ha sido recientemente descatalogada por Siemens. Sin embargo, su función (esto es, permitir la integración en redes Ethernet Industrial de instalaciones existentes basadas en PROFIBUS DP) es estratégicamente clave para el fabricante y sigue estando disponible a través de las CPUs de la gama S7-300 y S7-400.


93 de 143 Rev. 1

En el subapartado de Background, se tratarán avances aparecidos con posterioridad a la

aparición de las primeras propuestas de Ethernet Industrial y que actualmente ya forma

parte de la tecnología comercialmente disponible. Estos avances son utilizados por

algunas de las propuestas de Ethernet en Tiempo Real como elementos clave para

soportar sus prestaciones.

En el subapartado de Salto evolutivo, se repasarán las principales características de las

propuestas de Ethernet en Tiempo Real, explicando cómo utilizan las posibilidades que

ofrece la tecnología existente y qué funcionalidades aportan.

Por último, en el subapartado Productos de mercado, se repasarán los principales

fabricantes de cada propuesta Ethernet en Tiempo Real y las gamas de productos

relacionados comercialmente disponibles. También se indicarán los tipos de

comunicación a los que van principalmente dirigida cada propuesta y algunos aspectos

sobre su posicionamiento estratégico en el mercado.

3.3.1 Background

a) Sincronización El protocolo (S)NTP ha satisfecho durante muchos años las necesidades de

sincronización horaria de las estaciones finales. En su utilización típica, permite que

todas las estaciones finales en una LAN tengan la misma hora, con una precisión más

que suficiente para las aplicaciones ofimáticas, gracias al papel de maestro que juega

una de las estaciones finales. Si además la LAN tiene conexión a Internet, esta última

estación final hace las veces de maestro secundario y se sincroniza con un maestro

primario situado en algún punto de Internet y que ofrece la hora UTC con un precisión

razonable. En definitiva, todas las estaciones de la LAN tienen la misma hora y,

además, la hora correcta.

Los dispositivos de Ethernet Industrial, especialmente si se pretenden utilizar en una

aplicación con requerimientos temporales exigentes, están destinados a constituir un

Sistema Distribuido de Control en Tiempo Real. “Distribuido” porque cada

dispositivo realiza una tarea particular que ha de formar parte de un todo coordinado; En


94 de 143 Rev. 1

“tiempo real” porque el comportamiento del conjunto no sólo debe ser correcto, sino

que también ha de llegar en el momento oportuno y no más tarde [68]. Un sistema de

control de este tipo necesita una base de tiempo global, basada en la existencia de un

reloj local en cada uno de los nodos y un mecanismo de sincronización (proporcionado

por el sistema de comunicación) que debe ser capaz de asegurar una sincronización

entre todos los relojes locales con una precisión conocida, en el rango de los

microsegundos. La base de tiempo global permite:

• Coordinar instantes de medida (observaciones) e instantes de acciones, en

diferentes nodos del sistema distribuido.

• Determinar la antigüedad de observaciones realizadas por otro nodo y enviadas a

través del sistema de comunicaciones.

• Determinar el orden en que suceden los eventos sin que el hecho de que son

observados por nodos diferentes pueda introducir errores.

Los dispositivos de Ethernet Industrial disponen de reloj local y se pueden aprovechar

(si implementan el stack TCP/IP) del protocolo (S)NTP para sincronizarse, pero la

precisión conseguida no es suficiente para aplicaciones exigentes como las siguientes:

• En automatización y control:

o Sincronización de accionamientos multi-eje.

o Sincronización de subsistemas con operación cíclica.

• En sistemas eléctricos (generación, transporte y distribución):

o Control sobre aparamenta eléctrica.

o Reconstrucción de una sucesión de eventos.

Desde hace tiempo, existen tecnologías de sincronización que proporcionan las

precisiones requeridas por estas aplicaciones, pero son caras y tienen inconvenientes:

• GPS. Necesita línea de visión directa con los satélites.

• IRIG-B. Necesita una red cableada dedicada a la sincronización.


95 de 143 Rev. 1

En 2002, apareció la primera versión de la norma IEEE 1588, que especifica el

protocolo PTP (Precision Time Protocol), con los siguientes rasgos fundamentales:

• Pretende soportar precisiones de sincronización mejores que 1 μs.

• Aprovecha la propia red de datos para transmitir las señales de sincronización.

Se concentra en IEEE 802.3, aunque no se limita a ella.

• Su ámbito de aplicación se restringe a una LAN.

• Aunque permite implementación únicamente por software, es necesaria

asistencia de hardware específico para conseguir las mejores precisiones.

Más tarde, en 2008, se publicó la segunda versión de esta norma con ciertas mejoras y

extensiones. A continuación se resumen ambas.

PTPv1 (2002) PTPv1 es un protocolo de aplicación que se basa sobre UDP/IP. Utiliza el puerto UDP

319 para mensajes de evento (esto es, los que requieren time-stamp al ser enviados y al

ser recibidos) y el puerto UDP 320 para los mensajes generales (es decir, los que no lo

requieren). En los paquetes IP, define un valor de TTL (Time to Live) de “0”. De este

modo, ningún router los reenvía y su alcance queda circunscrito a una sola LAN.

Utiliza direccionamiento multicast: Tiene cuatro direcciones IP multicast reservadas,

que utiliza para soportar hasta cuatro dominios de sincronización independientes en la

LAN.

El principio de funcionamiento se basa en permitir que una estación final con reloj

maestro pueda enviar información sobre su hora y su frecuencia (velocidad a la que

avanza la hora) a una estación final con reloj esclavo. Para ello, actúan en paralelo dos

mecanismos de intercambio de mensajes: el de sintonización y el de sincronización.

El mecanismo de sintonización se encarga de transmitir al esclavo la información sobre

la frecuencia del maestro, tal como ilustra la Fig. 32.


96 de 143 Rev. 1

Fig. 32. Mecanismo de sintonización.

El reloj maestro envía mensajes Sync en instantes k separados regularmente en el

tiempo (por defecto, cada dos segundos). Los mensajes Sync son de tipo evento, de

modo que provocan un time-stamp al ser enviados (t1k) y otro al ser recibidos (t2

k), cada

uno de ellos en base al reloj local. La información de time-stamp (t1k) se genera en el

maestro, pero debe ser procesada en el esclavo. Si el hardware del maestro no tiene

capacidad para insertar ese time-stamp en el propio mensaje Sync de modo on-the-fly39

con suficiente precisión, entonces se indica esta circunstancia en un flag y se envía un

segundo mensaje (Follow_up) que incluye esta información. De este modo, el esclavo

tiene en todo momento información para calcular la deriva (drift) de su reloj respecto

del reloj maestro:

11

11

121

211

21

2

11

11

1

+

+++

++

++

ΔΔ−Δ

=

−=Δ−=Δ

k

kkk

kkk

kkk

Drift

tttt

El mecanismo de sincronización se encarga de calcular la desviación (offset) del

esclavo respecto del maestro, tal como ilustra la Fig. 33.

39 On-the-fly: Modo de escribir o modificar información sobre una trama sobre la marcha, sin entorpecer su transmisión.


97 de 143 Rev. 1

Fig. 33. Mecanismo de sincronización.

El reloj esclavo envía un mensaje de Delay_Req al maestro. Este mensaje es de tipo

evento, de modo que el esclavo registra el time-stamp de salida (t3) y el maestro registra

el time-stamp de llegada (t4), que seguidamente envía al esclavo mediante el mensaje

Delay_Resp. Con esta información, y con la del último mensaje Sync, el esclavo puede

calcular el offset de su reloj sin que introduzca error el retardo (delay) de transmisión de

los mensajes a través de la red, que también se puede calcular:

2)()(

2)()(

3412

3412

ttttOffset

ttttDelay

−−−=

−+−=

De esta manera, bajo la hipótesis de que el delay es simétrico y constante, la norma

establece el método en que el esclavo puede obtener su desviación respecto del maestro.

Sin embargo, la norma no prescribe cómo el esclavo debe llevar a cabo su corrección. A

este respecto, [69] alerta de que una implementación conforme a IEEE 1588 podría

ajustar la hora del reloj esclavo simplemente sumándole el offset, de modo que no

quedaría garantizada la muy deseable capacidad del reloj para producir una sucesión

monótonamente creciente de time-stamps40. Es, pues, aconsejable utilizar relojes

sintonizables [70], cuyo oscilador puede acelerarse o decelerarse a voluntad. Esto

permitiría al mecanismo de corrección compensar un offset positivo o negativo de una

manera suave y garantizando la monotonicidad creciente. Además permitiría aprovechar

40 En efecto, en caso de que el offset fuera negativo, el contador del reloj pasaría dos veces por el mismo conjunto de valores. Así, podría ocurrir que un evento ocurrido después que otro tuviera, en cambio, un time-stamp más pequeño.


98 de 143 Rev. 1

la información sobre la deriva41 respecto del reloj maestro (mensajes Sync) y sintonizar

el reloj esclavo con un tiempo de respuesta más rápido que el que permitiría tener en

cuenta únicamente el offset.

Cabe preguntarse en qué medida son válidas las hipótesis de partida utilizadas en el

método de cálculo.

• La simetría del delay (es decir, que sea igual entre maestro y esclavo que

viceversa) parece razonablemente válida. Incluso en una red switched Ethernet

con caminos físicos redundados, la simetría de la topología activa calculada por

el algoritmo de spanning tree (STP, RSTP o MSTP) asegura que el camino

físico de ida y el de vuelta son el mismo.

• El carácter constante del delay (jitter nulo) es más discutible y depende

fuertemente del punto en que se haga el time-stamp. La Fig. 34 muestra las

diferentes posibilidades.

Fig. 34. Posibles puntos de time-stamp.

Una implementación basada exclusivamente en software, realizaría el time-

stamp en la capa de aplicación (PTP), quedando afectada por el jitter que

introduce el stack UDP/IP. La norma prevé (aunque no impone) que el time-

stamp se haga lo más cerca posible de la capa física, utilizando hardware

41 La importancia de la deriva puede parecer a primera vista despreciable. En el nivel de precisión que reivindica la norma IEEE 1588, no lo es. Un oscilador de cuarzo barato tiene una dependencia respecto de la temperatura de 1 ppm/ºC [71]. Esto significa que una variación de la temperatura ambiente de 1ºC provoca que el oscilador empiece a derivar respecto de su comportamiento anterior en 1 μs por cada segundo que pasa. Esta es la razón por la norma prevé que se envíen mensajes Sync con tanta frecuencia (cada 2 segundos, por defecto). En cambio los mensajes Delay_Req y Delay_Resp se envían con una frecuencia mucho menor.


99 de 143 Rev. 1

dedicado. En el caso de IEEE 802.3, propone la interfaz MII como punto

adecuado, según se muestra en la Fig. 35.

Fig. 35. Time-stamp asistido por hardware en la interfaz MII.

En esta implementación, la unidad de time-stamp inspeccionaría todas las tramas

que se transmiten y que se reciben. Las tramas que contienen mensajes de

evento, es decir, las que contienen una cabecera UDP con identificador de puerto

319 disparan el time-stamp.

Otro factor que puede introducir jitter es la propia red, especialmente los

switches, en caso de que un mensaje PTP se quede retenido en la cola de un

puerto42. Para paliar este problema, la norma prevé que los switches de la red

participen del protocolo PTP en calidad de boundary clock. Un switch de este

tipo incorpora un reloj y, de los múltiples puertos que suele poseer, uno actúa

como esclavo sincronizando el reloj local con un reloj maestro remoto, tal como

muestra la Fig. 36.

42 Como ejemplo, una trama Ethernet con 1500 octetos en su campo Datos del Cliente MAC cuya transmisión acabara de comenzar ocasionaría a un mensaje PTP que llegara a la cola del mismo puerto un retardo adicional de 120 μs aproximadamente. De este modo quedarían invalidados totalmente los cálculos de del protocolo PTP.


100 de 143 Rev. 1

Fig. 36. Funcionamiento de un switch actuando como boundary clock.

El resto de puertos actúan como maestros y permiten la sincronización de los

relojes remotos a partir de su reloj local. En definitiva, introduce un reloj

intermedio (y por tanto una cierta imprecisión) pero resuelve el grave problema

del retardo en las colas.

Los boundary clocks dan lugar a una jerarquía de relojes que se ilustra en la Fig. 37.

Fig. 37. Jerarquía de relojes PTP.

En ella, se pueden distinguir los boundary clocks (con un reloj y múltiples puertos, de

los cuales sólo uno es esclavo) y los ordinary clocks (con un reloj y un puerto). El

protocolo PTP incorpora un algoritmo (BMC, Best Master Clock) para que cada puerto,

de manera independiente, calcule cuál debe ser su estado (maestro o esclavo). Para ello,

se comparan las características técnicas del reloj local con las de los relojes remotos

(recibidas a través de mensajes Sync). De este modo, se consigue una jerarquía


101 de 143 Rev. 1

consistente para todo el dominio de sincronización, en la que sólo hay un grandmaster,

que sirve de referencia para todos los demás relojes.

PTPv2 (2008) La versión 2 de la norma IEEE 1588 aporta mejoras y extensiones respecto la versión 1.

A continuación se resumen las más importantes:

Capas inferiores. La versión 1 sólo especificaba PTP sobre UDP/IPv4 sobre IEEE

802.3. La versión 2 añade especificaciones para:

• PTP sobre UDP/IPv6.

• PTP sobre IEEE 802.3 directamente. En este caso se utiliza el Ethertype 0x88F7

como identificador del protocolo PTP.

• PTP sobre PROFINET.

• PTP sobre otros buses de campo (DeviceNet y ControlNet).

Precisión. La nueva versión introduce mejoras para poder soportar precisiones de

sincronización entre relojes del orden de nanosegundos43:

• Aumenta la frecuencia máxima a la que se pueden enviar mensajes Sync: 128

mensajes por segundo.

• La resolución con que se representa los time-stamps pasa de 1 nanosegundos a

15 femtosegundos.

Topologías en línea. La topología en línea es deseable en el sector de la

Automatización y el Control. Las redes de Ethernet Industrial la consiguen

incorporando en las estaciones finales switches de 2 puertos exteriores. Esto, en

términos de PTP, supone una cascada considerable de boundary clocks que introducen

una imprecisión acumulativa en la sincronización. Para solventar este problema, la

versión 2 de IEEE 1588 introduce el concepto de transparent clock (TC) en dos

modalidades: end-to-end (e2e) y peer-to-peer (p2p).

Un TC e2e es un switch que es capaz de medir el tiempo transcurrido entre la entrada y

la salida de los mensajes PTP de evento. Puesto que se trata de un tiempo relativo y no

43 Que el protocolo soporte estas precisiones no quiere decir que la tecnología actual (hardware) las pueda conseguir. En todo caso, la intención de la norma es promover el avance en esta dirección.


102 de 143 Rev. 1

una hora absoluta, no hace falta que el reloj del TC esté sincronizado44; sólo que pueda

medir intervalos cortos de tiempo con razonable precisión. El tiempo de estancia en el

TC atravesado se acumula en un campo de corrección (c) previsto en el mensaje Sync,

si el TC es capaz de modifcarlo on-the-fly, o bien es enviado a continuación en un

mensaje Follow_up, tal como ilustra la Fig. 38.

Fig. 38. Mensaje Sync atravesando dos TCs e2e.

El campo de corrección (c) da constancia de la parte aleatoria del delay entre maestro

y esclavo, que es precisamente la que invalida la hipótesis de partida sobre su carácter

constante. Los esclavos envían mensajes Delay_Req hacia el maestro, que son tratados

análogamente por los TCs. En definitiva, teniendo en cuenta los campos de corrección

(c), los esclavos obtienen información suficiente para hacer sus correcciones sin

necesidad de un boundary clock.

Un TC p2p, además de tener las capacidades del e2e, mide los delays correspondientes

a los enlaces físicos hacia todos los relojes contiguos mediante mensajes Pdelay_Req,

Pdelay_Resp y Pdellay_Follow_up, tal como ilustra la Fig. 39.

44 En cambio, el mecanismo de sintonización sí puede ser beneficioso para la precisión de esa medida.


103 de 143 Rev. 1

Fig. 39. Flujo de mensajes en un dominio de sincronización con TCs p2p.

Como se puede observar, incluso aquellos enlaces que están bloqueados por un

protocolo de spanning tree son objeto de medida por los TCs. Cuando un mensaje Sync

atraviesa un TC, en el campo de corrección (c) no sólo se acumula el tiempo de

residencia en el TC sino también el delay del enlace de aguas arriba por el que ha

llegado el mensaje Sync (véase la Fig. 40).

Fig. 40. Mensaje Sync atravesando dos TCs p2p.

De este modo, el mensaje Sync siempre lleva consigo su propio delay y el esclavo tiene

toda la información necesaria para hacer la sintonización y la sincronización, también

sin necesidad de boundary clock. En caso de reconfiguración del spanning tree, los TCs

no deben hacer ninguna nueva medida y el protocolo PTP sigue operando con

normalidad.


104 de 143 Rev. 1

Mecanismo para extensiones. La nueva versión introduce un mecanismo TLV (Type,

Length, Value) para que otras organizaciones puedan añadir extensiones propias al

protocolo PTP.

Compatibilidad. No existe compatibilidad entre la versión 2 y la 1. Únicamente existe

la posibilidad de utilizar boundary clocks que implementen diferentes versiones en

diferentes puertos. En todo caso, se espera que la versión 2 desplace eventualmente a la

versión 1.

3.3.2 Salto evolutivo

a) Introducción Las soluciones de Ethernet Industrial que aparecieron en primera instancia se apoyan

sobre la arquitectura TCP/IP/Ethernet estándar. Ofrecen un servicio de comunicación

basado en un enfoque Best-effort (el mejor, dentro de lo posible), con una latencia y

jitter considerables, introducidos en su mayor parte por el stack TCP/IP y en menor

medida por la propia red Ethernet. En definitiva, no ofrecen comportamiento en tiempo

real.

Para abordar esta problemática, surgieron diversas propuestas que pretendían conseguir

comportamiento en tiempo real introduciendo mejoras sobre la arquitectura

TCP/IP/Ethernet estándar. Atendiendo a la naturaleza de las mejoras introducidas, estas

propuestas se puede agrupar en dos grandes categorías:

La primera categoría se caracteriza por un canal paralelo al stack TCP/IP y hardware

estándar, tal como ilustra la Fig. 41.


105 de 143 Rev. 1

Fig. 41. Ethernet en Tiempo Real. Arquitecturas basadas en hardware estándar.

El protocolo de aplicación que trata los datos de proceso (los que necesitan

comportamiento en tiempo real) accede directamente a la capa 2 (Ethernet), sin pasar

por el stack TCP/IP. De este modo, se elimina la latencia y el jitter introducidos por

dicho stack. Las tramas Ethernet tienen un Ethertype específico que identifica el

protocolo Ethernet en Tiempo Real. Estas tramas quedan contenidas dentro de la red (no

pueden atravesar los routers, dado que no se trata de paquetes IP).

El stack TCP/IP también puede utilizarse, pero sólo para los datos de parametrización

(los que no requieren comportamiento en tiempo real). De este modo, se puede

aprovechar las funciones propias de las Tecnologías de la Información (HTTP, SNMP,

FTP, ...). El acceso del stack TCP/IP a la capa Ethernet está supeditado al control de una

capa intermedia que da prioridad a los datos de proceso.

Por último, los controladores Ethernet y los switches (o hubs) utilizados son totalmente

estándar. Como ejemplos de protocolos que caen dentro de esta categoría cabe destacar

Ethernet Powerlink y PROFINET RT.

La segunda categoría se caracteriza por un canal paralelo al stack TCP/IP y

hardware especial, tal como ilustra la Fig. 42.


106 de 143 Rev. 1

Fig. 42. Ethernet en Tiempo Real. Arquitecturas basadas en hardware especial.

Como se puede observar, el tratamiento del stack TCP/IP es igual al de la categoría

anterior. Sin embargo, utiliza controladores o switches especiales, lo cual permite

mayores prestaciones en cuanto la comportamiento en tiempo real. Ejemplos destacados

de esta categoría son EtherCAT y PROFINET IRT.

Por último, aunque no cae dentro de ninguna de las categorías anteriores, en el presente

estudio también se consideran como propuesta de Ethernet en Tiempo Real las

extensiones CIP Sync y CIP Motion del protocolo Ethernet/IP. En efecto, estas

extensiones introducen una mejora (el mecanismo de sincronización PTPv1) que no

forma parte de lo que normalmente se considera como arquitectura TCP/IP/Ethernet

estándar.

b) Ethernet/IP con CIP Sync y CIP Motion CIP Sync es una extensión de la capa de aplicación CIP (véase el apartado 3.2.2.c) que

proporciona un mecanismo de sincronización entre participantes de un protocolo CIP.

De acuerdo con [72], la especificación de CIP Sync para Ethernet/IP se basa en el

protocolo PTPv1 para mantener sincronizada con la base de tiempo global una variable

Hora del Sistema en cada dispositivo local.

Además de la anterior función, CIP Sync para Ethernet/IP presenta algunas

particularidades. Además de la variable Hora del Sistema, mantiene disponibles para la


107 de 143 Rev. 1

propia aplicación que se apoya sobre la capa CIP la variable Hora Local y la variable

Offset (diferencia entre ambas). De este modo, se pueden aplicar cambios en la variable

Hora del Sistema sin afectar necesariamente a la variable Hora Local del dispositivo.

Según [72], esta separación es importante en caso de que una discontinuidad en la

frecuencia o la escala lineal del tiempo fuera perjudicial para la capacidad del

dispositivo para controlar apropiadamente.

Otra característica de CIP Sync es que permite que en el nivel de aplicación se

determine a qué dominio de sincronización se debe asignar cada dispositivo. De este

modo, se pueden formar varios grupos de dispositivos según sus necesidades de

sincronización. Por ejemplo, los accionamientos de un grupo de ejes en una máquina

pueden requerir sincronización entre ellos pero independiente de la de otro grupo de

ejes.

De acuerdo con [72], una sincronización de precisión entre los diferentes dispositivos de

un sistema permite reacciones sincronizadas con un jitter bajo sin la necesidad de una

transmisión de datos con jitter bajo. De este modo, gracias al mecanismo de

sincronización CIP Sync, aunque Ethernet/IP sea un sistema de comunicación no exento

de jitter, sería posible la realización de aplicación de control de movimiento de altas

prestaciones. Esto es lo que pretende CIP Motion, aplicando dos principios básicos:

• Los datos que recibe un dispositivo accionador no están referenciados al propio

ciclo del bus, sino que tienen un time-stamp con un hora absoluta.

• Los datos recibidos a tiempo son aplicados en el dispositivo accionador, previo

ajuste mediante interpolaciones sobre los time-stamps. Los datos que recibe

fuera de tiempo (debido al jitter) también son aplicados, en este caso previo

ajuste mediante extrapolaciones.

c) PROFINET IO45 PROFINET IO es, más que un protocolo, una solución global para la comunicación

entre dispositivos de campo y controladores, que permite desarrollar aplicaciones

45 La versión de PROFINET IO expuesta aquí es la que corresponde a los productos comercialmente disponibles en la actualidad. Sin embargo, su especificación está en proceso de revisión: Se está trabajando en su optimización mediante el uso de Dynamic Frame Packing [73] y la revisión general del mecanismo de sincronización.


108 de 143 Rev. 1

distribuidas de automatización y control. PROFINET IO46 es la evolución hacia la

tecnología Ethernet Industrial del bus de campo PROFIBUS DP. En ese sentido,

pretende mantener su filosofía de funcionamiento, sus perfiles de dispositivos

(PROFIDrive, PROFISave,...), etc. Ambas soluciones de comunicación son promovidas

por la organización PROFIBUS International [64].

Los dispositivos PROFINET IO se caracterizan por las siguientes particularidades:

• Todo dispositivo PROFINET IO posee una interfaz PROFINET, con una

dirección MAC, una dirección IP y un nombre de dispositivo. Además, posee

uno o varios puertos Ethernet. En el segundo caso el interfaz PROFINET

incorpora un switch interno.

• Cualquier dispositivo PROFINET IO se puede clasificar en uno de estos tres

tipos:

o Controlador IO. Dispositivo con inteligencia, que ejecuta programas de

control (PLC, PC industrial,...)

o Disposivo IO. Incluye sensores, actuadores, módulos IO. También se

incluyen en esta categoría los switches que incorporan funcionalidades

propias de PROFINET IO.

o Supervisor IO. Estación de ingeniería (PCs) desde donde se realizan

tareas de diagnóstico y configuración / programación.

En PROFINET IO, existen dos protocolos disponibles para el intercambio de datos en

tiempo real:

• PROFINET RT (Real Time). Es el que se utiliza por defecto (todos los

dispositivos PROFINET IO lo implementan). Se basa en controladores Ethernet

estándares.

• PROFINET IRT (Isochronous Real Time). Tiene mayores prestaciones en

cuanto a su comportamiento en tiempo real, pero requiere controladores Ethernet

especiales. Los dispositivos PROFINET IO que lo implementan, implementan al

mismo tiempo PROFINET RT.

A continuación, se resumen ambos.

46 IO hace referencia a Input/Output.


109 de 143 Rev. 1

PROFINET RT PROFINET RT se basa en switches Ethernet estándar, operando en modo full-duplex a

100 Mbps (Fast Ethernet). Sin embargo, intenta aprovechar las posibilidades de la

especificación estándar para mejorar sus prestaciones en aspectos importantes para las

aplicaciones industriales:

• Comportamiento en tiempo real. Se apoya directamente sobre Ethernet

(Ethertype 0x8892)47. De este modo, evita el delay y el jitter que introduciría el

stack TCP/IP. Además, utiliza tramas priority-tagged según IEEE 802.1Q, con

un valor de prioridad de 6 (1 corresponde a la prioridad más baja y 7 a la más

alta).

• Topologías disponibles:

o Topología en estrella. Es la tradicional de switched Ethernet. Se puede

conseguir mediante switches estándar, pero deben ser conformes a IEEE

802.1Q y permitir varias clases de tráfico en los puertos destinados al

tráfico PROFINET RT. También se pueden utilizar switches PROFINET

IO, que aseguran lo anterior y, además, proporcionan algunas ventajas no

imprescindibles, como diagnóstico y configuración mediante la

herramienta de software propia de PROFINET IO. Algunos de estos

switches, incluso reenvían las tramas mediante el método cut-through.

o Topología en línea o en árbol. Los dispositivos PROFINET IO

acostumbran a tener un switch incorporado y dos puertos Ethernet

externos. De este modo, permiten una topología en línea. Algunos

dispositivos tienen 3 o más puertos exteriores, lo cual permitiría

topologías en árbol.

o Topología en anillo. La topología en línea se puede cerrar con un enlace

que conecte los puertos libres del primer dispositivo y el último. Todos

los dispositivos que constituyen el anillo deben soportar el protocolo

MRP y al menos uno de ellos debe asumir el papel gestor del anillo.

47 Otra consecuencia de utilizar directamente Ethernet es que su ámbito se restringe a una bridged LAN: no puede atravesar un router. Sin embargo, esto no supone ningún inconveniente, dada la finalidad del protocolo.


110 de 143 Rev. 1

PROFINET RT se utiliza para transmitir en tiempo real información acíclica (p.ej.

alarmas) y también información cíclica (datos IO). A continuación se exponen los

conceptos básicos sobre el ciclo PROFINET IO:

• Tiempo de ciclo. Es un valor común a toda la red PROFINET IO. Indica la

periodicidad con que se realiza el intercambio de tramas PROFINET RT. Este

valor se puede ajustar entre 250 μs y 4 ms (por defecto, se configura a 1 ms). A

continuación, se ilustra el ciclo PROFINET IO en una red que sólo se

implementa PROFINET RT (no existe ningún dispositivo PROFINET IRT).

Fig. 43. Ejemplo de ciclo PROFINET IO con tráfico RT (valores en μs).

• Ancho de banda para tráfico cíclico. Este parámetro divide el ciclo PROFINET

IO en dos fases. En la primera fase, los dispositivos PROFINET RT tienen

permiso para enviar tramas PROFINET RT. Aunque en esta fase el tráfico

TCP/IP no está prohibido, las tramas PROFINET RT son tratadas de manera

prioritaria, gracias a su etiqueta IEEE 802.1Q. Durante la segunda fase, los

dispositivos PROFINET RT dejan de enviar tramas RT48 y las tramas TCP/IP

que habían quedado esperando en las colas de los puertos de los switches podrán

continuar su camino49.

• Tiempo de refresco. Este parámetro se puede configurar de manera individual

para cada dispositivo IO. Indica la periodicidad con la que ese dispositivo IO en

48 Por eso, el ajuste de este parámetro debe ser tal que haya suficiente ancho de banda disponible para las necesidades de tráfico RT. 49 En caso de un ciclo de 1 ms, el ancho de banda reservado para tráfico cíclico puede ajustarse como máximo a 500 μs. Para un ciclo de 250 μs, el ancho de banda reservado para tráfico cíclico se limita como máximo a 100 μs. Esto significa que, en el caso más desfavorable, habrá 150 μs para que las tramas TCP/IP puedan ser reenviadas (la trama más larga tiene un tiempo de transmisión de 125 μs, aproximadamente).


111 de 143 Rev. 1

concreto intercambia datos con su controlador IO. Puede ser igual al tiempo de

ciclo o bien un múltiplo de él. Por defecto, se ajusta a 2 ms o más.

• Tiempo de comprobación de respuesta. Se utiliza para decidir un dispositivo IO

ha de pasar al estado de “fallo” ante una falta de comunicación. Por defecto, se

ajusta a 6 ms.

Con respecto a los ajustes en los parámetros anteriores, [74] alerta sobre las

precauciones a tener en cuenta:

• Aun teniendo prioridad la trama PROFINET RT, una trama NRT (p.ej. TCP/IP)

que ya ha empezado a transmitirse por un puerto de un switch puede dejar

esperando en la cola a una trama PROFINET RT. La presencia de tráfico

multicast puede provocar que un dispositivo IO entre en estado de “fallo”. En

ese caso, habría que incrementar el tiempo de refresco o el tiempo de

comprobación de respuesta.

• Cuantos más switches hay entre un dispositivo IO y su controlador IO, más

grande debe ser el tiempo de comprobación de respuesta para que no entre en

fallo. Con los valores por defecto que calcula la herramienta de configuración de

PROFINET RT, puede haber 50 nodos en línea sin problemas.

PROFINET IRT PROFINET IRT se utiliza para transmitir datos IO que tienen requerimientos

temporales estrictos (hard real time) y, por tanto, no pueden ser satisfechos por

PROFINET RT. La implementación de PROFINET IRT requiere controladores

Ethernet específicos, denominados ERTEC (Enhanced Real-Time Ethernet Controller),

que incorporan en su interior switches especiales de dos y cuatro puertos [75]-[76]. Los

controladores ERTEC deben estar presentes en todos los dispositivos PROFINET IRT:

tanto en controladores IO y dispositivos IO como en los propios switches adicionales (a

parte de los incorporados) que se utilicen para comunicarlos.

Cuando existe tráfico PROFINET IRT, queda acomodado dentro del ciclo PROFINET

IO general de la red tal como ilustra la Fig. 44.


112 de 143 Rev. 1

Fig. 44. Ejemplo de ciclo PROFINET IO con tráfico RT e IRT (valores en μs).

En tal caso, deberán tenerse en cuenta los siguientes parámetros adicionales:

• Límite máximo para la comunicación IRT. Este parámetro se especifica como un

porcentaje del ancho de banda para tráfico cíclico (en la figura, 30 %) y es

común para toda la red PROFINET IO. Deberán cumplirse estas dos

condiciones:

o El ancho de banda consumido realmente por la comunicación IRT no

podrá rebasar el ajuste límite máximo para la comunicación IRT.

o La sumo del ancho de banda consumido por el tráfico IRT y el RT no

podrá rebasar el ajuste ancho de banda para tráfico cíclico.

• Tiempo de refresco. Al igual que los dispositivos RT, cada dispositivo IRT tiene

su propio tiempo de refresco, que podrá ser igual al tiempo de ciclo o un

múltiplo. Pueden conseguirse tiempos de refresco de hasta 250 μs si se ajusta el

tiempo de ciclo a ese valor.

Las características de PROFINET IRT requieren que todos los participantes tengan una

base de tiempo global, sincronizada con una precisión de menos de 1 μs. El

mecanismo de sincronización para conseguir esta precisión se basa en el protocolo

PTCP (Precision Transparent Clock Protocol) implementado en los propios

controladores ERTEC.

Según [77], este protocolo es muy similar al PTPv2 (véase subapartado 3.3.1.a

operando con Transparent Clocks de tipo p2p. Normalmente, envía una trama Sync


113 de 143 Rev. 1

cada 30 ms. Sin embargo, muchas implementaciones la envían en cada fase IRT, por

simplicidad. Según [75]-[76], el time-stamping es plenamente conforme a PTPv2 y se

realiza en el switch incorporado en el controlador ERTEC, a nivel de interfaz (R)MII.

Un dominio de sincronización puede tomar como referencia (maestro) un controlador

IO o bien un switch IRT y puede abarcar varios sistemas IO, es decir, varios

controladores, tal como ilustra la Fig. 45.

Fig. 45. Ejemplo dominio de sinronización IRT.

Además, como se puede observar, en la periferia del dominio de sincronización se

pueden conectar otros switches y dispositivos no IRT.


114 de 143 Rev. 1

La base de tiempo global permite:

• Que la reserva del intervalo para el tráfico IRT sea efectiva. En efecto, los

switches incorporados en los controladores ERTEC son conscientes de la base

de tiempo global e interrumpen el tráfico que no es IRT, es decir, no lo reenvían

y lo dejan retenido en las colas de sus puertos.

• Que, dentro de ese intervalo reservado, en los instantes planificados a priori en

la herramienta de configuración de PROFINET IRT.

PROFINET IRT dispone de dos modos de operación: alto desempeño y alta

flexibilidad. El modo seleccionado aplica a todo el tráfico IRT de un dominio de

sincronización. El modo de alto desempeño es más estricto: Requiere una

configuración rígida de la topología de la red y una planificación (asistida por la

herramienta de configuración de PROFINET IRT) de la secuencia de transmisiones que

debe tener lugar en cada ciclo y del camino físico que debe seguir cada una de ellas.

Además requieren necesariamente del reloj maestro: Si este falla, todos los dispositivo

IRT pasan a estado “fallo”. Sin embargo, es el que ofrece mayor grado de determinismo

y, además, aprovecha todo el ancho de banda reservado para tráfico IRT, a diferencia

del otro modo de operación.

El modo de alta flexibilidad, en cambio, no requiere una configuración de la topología:

La topología es libre, siempre que no se exceda el ancho de banda disponible en ningún

punto de la red. Tampoco planifica la secuencia de transmisiones que debe tener lugar

en cada ciclo ni los caminos físicos que deben seguir: Simplemente, los controladores

IO y los dispositivos IO aprovechan la reserva del ancho de banda para enviar sus

tramas, que son tratadas por los switches siguiendo las reglas estándares de IEEE

802.1D/Q . En caso de fallo del reloj maestro, los dispositivos IRT continuarán

comunicando, con calidad RT. Por último, el modo de alta flexibilidad no aprovecha

todo el ancho de banda reservado para él. Para su buen funcionamiento, necesita una

franja de seguridad, en la que ningún otro tipo de tráfico puede circular (véase la Fig.

44).


115 de 143 Rev. 1

Otros protocolos de PROFINET IO Todos los dispositivos PROFINET IO implementan el protocolo LLDP (véase

subapartado 3.2.1.c). Además de mantener la MIB propia de LLDP, especificada en

IEEE 802.1AB, también implementan una MIB específica (MIB LLDP PNIO). Estas

MIBs son consultables vía SNMP y permiten a la herramienta de configuración de

PROFINET IO determinar la topología de la red, lo cual es un prerrequisito para poder

planificar la comunicación IRT.

El protocolo MRP (Media Redundancy Protocol) permite formar topologías en anillo

con tolerancia al fallo. Los dispositivos que pueden formar parte de un dominio MRP

(anillo) son controladores IO, dispositivos IO y switches externos. Se requiere que todos

ellos implementen el protocolo MRP. En los dispositivos con más de dos puertos, debe

asegurarse que los puertos conectados en el anillo sean de tipo ring port o estén

configurados como tales. Los puertos extra que no sean de tipo ring port permitirán

extender la red alrededor del anillo, tal como ilustra la Fig. 46, aunque no disfrutarán de

la tolerancia al fallo.

Fig. 46. Ejemplo red PROFINET IO con anillo MRP.

Debe haber al menos un dispositivo del anillo que tenga capacidades de gestor del

anillo (controlador IO o switch externo). Este dispositivo tiene uno de sus puertos

bloqueado a las tramas de datos, para evitar la formación de un bucle. Además envía


116 de 143 Rev. 1

tramas de comprobación MRP por sus dos puertos de anillo y espera recibirlas por el

extremo opuesto como prueba de la integridad del anillo. En caso de detectar un fallo en

el anillo, habilita el puerto que tenía bloqueado para restablecer la conectividad lógica.

Cuando se recupera la integridad del anillo, el gestor del anillo se vuelve a bloquear uno

de los puertos.

El protocolo MRP permite formar anillos de hasta 50 nodos y asegura un tiempo de

restablecimiento de 200 ms. La topología MRP soporta tráfico TCP/IP y también tráfico

PROFINET RT. Sin embargo, hay que tener en cuenta que si el tiempo de

restablecimiento del anillo es superior al tiempo de comprobación de respuesta de los

dispositivos RT, éstos entrarán en estado de fallo. Para evitarlo, se deberá ajustar un

tiempo de comprobación de respuesta mayor. Por último, hay que tener presente que la

topología MRP no soporta el tráfico PROFINET IRT.

La mayor parte del tráfico generado en el marco de PROFINET IO es en tiempo real.

Sin embargo, PROFINET IO también se apoya en el stack TCP/IP para algunas

funciones:

• Cuando un controlador IO pretende establecer una relación de comunicación con

un dispositivo IO, la negociación se hace a través del protocolo de aplicación

CLRPC (Connectionless Remote Procedure Call), que a su vez se apoya sobre

UDP (puertos 34962, 34963, 34964).

• La consulta de las diferentes MIB (p.ej. de LLDP) que contiene un dispositivo

PROFINET IO se hace a través del protocolo de aplicación SNMP, que a su vez

se apoya sobre UDP.

En ningún caso, sin embargo, PROFINET IO genera tráfico sobre TCP.

d) EtherCAT La organización promotora de EtherCAT es ETG (EtherCAT Technology Group) [78].

A diferencia de otras organizaciones mencionadas anteriormente, ésta no tiene sus

intereses repartidos entre un bus de campo tradicional y una propuesta de Ethernet

Industrial. Por el contrario, la única razón de ser de ETG es la promoción de EtherCAT

como solución de comunicaciones en el entorno industrial.


117 de 143 Rev. 1

Según [79] y [80], EtherCAT se basa sobre 100BASE-TX full duplex (Fast Ethernet) y

utiliza tramas Ethernet estándar. Su modelo de comunicación básico es maestro /

esclavo. El maestro puede ser cualquier estación final con un controlador Ethernet

estándar (p. ej. un PC industrial). Sin embargo, los esclavos incorporan un hardware

especial que proporciona a las comunicaciones altas prestaciones de tiempo real sin

consumir recursos de la CPU host que ejecuta la aplicación de usuario en el esclavo.

Dicho hardware, entre otras funciones, incorpora una capa MAC modificada, con un

sistema de direccionamiento diferente del estándar especificado en IEEE 802.3. Además

en esclavos con varios puertos, no se incorporan switches conformes con IEEE

802.1D/Q, sino que se implementa unidades de Autoforward & Loopback, muy

características de EtherCAT.

Topología EtherCAT implementa una topología lógica en anillo. El maestro (que tiene hardware

estándar) implementa la funcionalidad control de las comunicaciones mediante

software, que se ejecuta en la propia CPU, junto con la aplicación de usuario.

Cíclicamente, el maestro envía una trama EtherCAT con información dirigida a los

esclavos a través del par trenzado TX y espera una trama de respuesta a través del par

trenzado RX, tal como ilustra la Fig. 47.

Fig. 47. Topología lógica de EtherCAT.


118 de 143 Rev. 1

Los esclavos, por su parte, se comportan como una sola unidad (segmento EtherCAT).

En el caso concreto de la Fig. 47, el segmento EtherCAT adopta una topología física en

línea: Cada esclavo tiene dos puertos Ethernet que se conectan mediante cables estándar

con los esclavos contiguos. El primer esclavo recibe la trama EtherCAT a través del par

RX del puerto que lo conecta al maestro. El hardware especial del esclavo, procesa la

trama on-the-fly. Es decir, sin almacenarla, lee su contenido para encontrar información

dirigida a él y escribe la información requerida en las zonas de la trama destinadas para

ello. Todo este proceso se realiza mientras la trama atraviesa una FIFO, lo cual tan solo

introduce un retardo del orden de ns. El proceso se repite sucesivamente en todos los

esclavos. El último esclavo del segmento procesa igualmente la trama, pero la reenvía

por el par TX del mismo puerto de recepción. De este modo, la trama vuelve hacia atrás

(ahora ya sin sufrir modificaciones) cerrando el anillo hasta que llega al maestro.

Gracias a este mecanismo se consiguen tiempos de ciclo típicamente inferiores a 100

μs.

El funcionamiento descrito anteriormente corresponde a un caso particular en que todos

los esclavos tienen dos puertos Ethernet. Sin embargo, los esclavos EtherCAT pueden

tener hasta cuatro puertos. En el caso general, la unidad de Autoforward & Loopback

redirige la trama según se muestra en la Fig. 48.


119 de 143 Rev. 1

Fig. 48. Función de Autoforward & Loopback.

El puerto 0 siempre es el que recibe la trama procedente del maestro. Al recibirla por

este puerto, la función Autoforward automáticamente hace intervenir la Unidad de

procesado EtherCAT, on-the-fly. Una vez procesada, la trama es dirigida hacia el

siguiente puerto (par TX) para que sea procesada por otros esclavos y espera a que

vuelva (par RX). Cada vez que vuelve, la trama es redirigida hacia el siguiente puerto

(Autoforward) para ser transmitida. En caso de que el puerto esté cerrado (porque no

está físicamente implementado, porque no está conectado o porque está configurado

como tal), la función de Loopback redirige la trama hacia el siguiente puerto.

Finalmente, la trama llega al puerto 0 y es devuelta hacia el camino por donde llegó,

hasta llegar al maestro.

Este mecanismo permite implementar en la práctica topologías físicas en árbol sin que

se vea afectada la topología lógica en anillo subyacente y sin las limitaciones propias de

los switches en cascada (véase la Fig. 49).


120 de 143 Rev. 1

Fig. 49. Topología física en árbol.

En EtherCAT no hay limitación de nodos (hasta 65535), más allá de la que imponga las

necesidades de la aplicación sobre el tiempo de ciclo. Además, en caso de fallo en un

enlace, no se pierde el servicio en toda la red (como ocurriría en un anillo convencional)

sino que la función Loopback lo detecta y redirige la trama por la parte que queda en el

lado del maestro, tal como ilustra la Fig. 50.

Fig. 50. Reconfiguración de la red en línea, en caso de fallo.


121 de 143 Rev. 1

EtherCAT permite también la topología física en anillo, lo cual proporciona

redundancia de caminos físicos y, por tanto, tolerancia al fallo (véase la Fig. 51).

Fig. 51. Reconfiguración de la red en anillo, en caso de fallo.

Para ello, no se requiere ningún tipo especial de esclavos EtherCAT. Simplemente, es

necesario un segundo puerto Ethernet (también estándar) en el maestro, que se

conectaría al puerto libre del último esclavo. Según [80], el tiempo de recuperación en

caso de fallo es inferior a 15 μs.

Formato de las tramas EtherCAT Normalmente, EtherCAT se apoya directamente sobre Ethernet (Ethertype 0x88A4).

Sin embargo, también se puede utilizar sobre UDP/IP (puerto UDP 0x88A4), en cuyo

caso tiene la capacidad de atravesar routers. Además, admite tramas con etiqueta VLAN

(IEEE 802.1Q), aunque no procesan la información contenida en ella. La Fig. 52 ilustra

la variedad de formatos que pueden adoptar la tramas Ethernet utilizadas por EtherCAT.


122 de 143 Rev. 1

Fig. 52. Formato de la trama EtherCAT.

Todos estos posibles formatos son reconocidos por los esclavos EtherCAT directamente

a través de hardware, como paso previo al procesado on-the-fly. Como datos de usuario

de la trama Ethernet (o bien del datagrama UDP), se encuentra la PDU de EtherCAT,

cuyo formato se ilustra en la Fig. 53.


123 de 143 Rev. 1

Fig. 53. Formato de la PDU EtherCAT.

Una PDU EtherCAT consta de los siguientes campos:

• Longitud (11 bits): Longitud en octetos del campo de datos EtherCAT, es decir,

de los n datagramas EtherCAT.

• Reservado (1 bit): No se usa. Vale “0”.

• Tipo (4 bits): Tipo de protocolo EtherCAT. Los esclavos sólo soportan el tipo

“1”: comandos EtherCAT.

• Campo de datos: Formado por los datagramas EtherCAT. Cada PDU EtherCAT

puede tener uno o varios datagramas, que constituyen los comandos que

cíclicamente el maestro envía a los eslavos.

A su vez, los datagramas están formados por los siguientes campos:

• Cmd (1 octeto): Es un código de Comando EtherCAT que indica el tipo de

operación (lectura / escritura) y el tipo de direccionamiento utilizado.


124 de 143 Rev. 1

• Idx (1 octeto): Es un índice utilizado por el maestro para detectar la duplicación

o pérdida de datagramas. No es modificado por los esclavos.

• Address (4 octetos): Es la dirección, que debe interpretarse de acuerdo con el

tipo de direccionamiento indicado por el campo Cmd. Existen tres posibilidades:

o Direccionamiento del esclavo en base a su posición relativa dentro del

segmento EtherCAT. La dirección se completa con un offset que indica

una posición de memoria dentro de la memoria del controlador

EtherCAT (ESC) esclavo.

o Direccionamiento del esclavo en base a una dirección de nodo. Incluye la

posibilidad de direccionamiento broadcast. Igual que en el caso anterior,

la dirección se completa con un offset.

o Direccionamiento lógico. No direcciona un nodo concreto sino una

posición de memoria dentro de un espacio de direccionamiento lógico

(virtual) de 32 bits (4 Gb). Cada controlador EtherCAT (ESC) posee una

unidad FMMU (Fieldbus Memory Management Unit), configurable por

el maestro, que establece una asociación entre direcciones lógicas

predeterminadas y sus correspondientes direcciones físicas en el ESC.

Cuando llega un datagrama con una dirección lógica que coincide con

una de las configuradas, cada ESC sabe a qué zona de su memoria física

interna debe acceder y sobre qué zona del campo de datos debe

escribir/leer. De este modo un solo datagrama puede utilizarse para

ejecutar una operación sobre diferentes esclavos, tal como ilustra la Fig.

54.

Fig. 54. Uso del direccionamiento lógico, mediante FMMUs.

• Len (11 bits): Longitud en octetos del campo Data dentro de este datagrama.

• R (1 bit): Reservado. Vale “0”.


125 de 143 Rev. 1

• C (1 bit): Se utiliza para evitar que una trama se quede indefinidamente

circulando, debido al mecanismo de Loopback.

• M (1 bit): Si vale “1” indica que hay más datagramas a continuación. Si vale “0”

indica que es el última datagrama dentro de esta PDU.

• IRQ (2 octetos): Contiene la combinación OR de los registros de Petición de

Evento de todos los esclavos.

• Data (n octetos): Campo de datos del datagrama. Contiene la información que

los esclavos deben leer o reserva el espacio para que los esclavos puedan

escribir.

• WKC (2 octetos): Una vez la trama ha vuelto al maestro, este campo le sirve

para llevar un control de cuántos esclavos han ejecutado operaciones de lectura /

escritura sobre este datagrama y comprobar si se corresponde con lo esperado.

Esclavos EtherCAT La capa física de los escalvos EtherCAT se implementa mediante PHYTERs estándares

de mercado (COTS). Sin embargo, no sirve cualquier PHYTER estándar. [81] establece

las características que deben cumplir:

• Deben ser conformes a 100BASE-TX o 100BASE-FX (para fibra óptica).

• Deben conectarse la capa MAC preferiblemente mediante el interfaz MII. No se

recomienda RMII porque los PHYTERs con este tipo de interfaz incluyen una

FIFO en TX que introducen delay y jitter.

• Deben proporcionar interfaz de gestión de MII.

• Deben implementar la función auto-crossover.

• El tiempo de reacción para indicar pérdida de enlace debe ser menor de 15 μs,

para permitir el funcionamiento del mecanismo de redundancia para la topología

física en anillo.

• No deben modificar el preámbulo de la trama Ethernet.

La capa MAC se implementa mediante un procesador MAC especial (ESC, EtherCAT

Slave Controller), cuyos principales bloques funcionales se muestran en la Fig. 55.


126 de 143 Rev. 1

Fig. 55. Bloques funcionales de un ESC.

La Unidad de Procesado EtherCAT entra en contacto con el flujo de datos de la red

EtherCAT a través de la unidad de Autoforward & Loopback, según ilustra la Fig. 48.

Por otra parte, entra en contacto con la aplicación interna del esclavo a través del

interfaz PDI (Process Data Interface). Dentro de la Unidad de Procesado EtherCAT, las

funciones más destacadas son:

• El Espacio de Direccionamiento ESC, constituido por 4 kb de registros internos

y memoria de usuario y 60 kb de memoria de proceso.

• FMMU. Según se explicó anteriormente, establece la correspondencia entre el

direccionamiento lógico utilizado en los datagramas EtherCAT y las direcciones

físicas del Espacio de Direccionamiento ESC.

• SyncManager. Se encarga de asegurar la consistencia en el intercambio de datos

con el Espacio de Direccionamiento ESC.

Estas funciones permiten tanto al maestro (conectado a través de la red EtherCAT)

como a la aplicación interna del esclavo acceder a los registros internos y a la memoria

RAM del ESC de manera análoga a como actuaría una memoria de puerto dual. De este

modo, las prestaciones en tiempo real de la comunicación no dependen de la potencia

que puede tener la CPU del esclavo.


127 de 143 Rev. 1

Sincronización Además de las funciones descritas en el subapartado anterior, un ESC puede,

opcionalmente, implementar funciones de sincronización (Distributed Clocks). Hay tres

niveles de soporte a este respecto:

• Soporte de la Hora del Sistema. Los esclavos con este nivel de soporte tienen

reloj local, Hora del Sistema y mecanismo de corrección que consigue mantener

la precisión muy por debajo de 1 μs. Además, opcionalmente, generan señales

de sincronización para los esclavos que permiten:

o Sincronizar la actualización de salidas digitales.

o Sincronizar el muestreo de señales digitales.

o Sincronizar mediante señales de interrupción la ejecución de la

aplicación de usuario en los esclavos.

• Soporte de la medida de los delays en los enlaces. Este nivel de soporte es

obligatorio para los esclavos con tres o más puertos. Conlleva el soporte de reloj

local y de time-stamp a la recepción de tramas, pero no de Hora del Sistema.

• Esclavos que no soportan ninguna función de sincronización. Los esclavos con

uno o dos puertos no requieren ninguna función de sincronización. El delay que

puede introducir en las tramas de sincronización se asimila al que pueda

producir el propio enlace.

De entre los ESCs que soportan Hora del Sistema, uno se comportará como reloj

maestro (normalmente el más cercano al inicio del segmento EtherCAT) y los demás lo

tomarán como referencia (esclavos), tal como ilustra la Fig. 56.

Fig. 56. Sincronización en una red EtherCAT.


128 de 143 Rev. 1

El maestro EtherCAT en ningún caso desempeñará la función de maestro de

sincronización, aunque sí puede implementar la funcionalidad de sincronizarse con él.

El mecanismo de sincronización es independiente del maestro EtherCAT y no depende

(como ocurre en otros protocolos) de que la cadencia con que el maestro transmite los

mensajes cíclicos esté libre de jitter. En EtherCAT, incluso, está previsto que la

transmisión de los mensajes cíclicos por parte del maestro tenga un cierto jitter sin que

eso afecte a las prestaciones del protocolo. Esto permite que la implementación del

maestro se pueda hacer en software.

e) Ethernet Powerlink Ethernet Powerlink es promovido por la organización EPLSG (Ethernet Powerlink

Standardization Group) [82]. Su especificación prevé una capa de aplicación que se

apoya directamente sobre Ethernet (Ethertype 0x88AB) para tratar el tráfico cíclico

(RT). Para el tráfico acíclico (NRT), prevé la utilización del stack TCP/IP por parte de

otros protocolos de aplicación estándares.

La especificación prevé una topología en estrella o árbol, basada en hubs (100 Mbps,

half-duplex), ya sea externos o integrados en los dispositivos, según ilustra la Fig. 57.

Fig. 57. Topología y principio de funcionamiento de Ethernet Powerlink.

Aunque los switches no están prohibidos, se desaconseja su uso: La latencia que

introducen puede llevar el desempeño de la red a unos niveles inaceptables. Según [80]


129 de 143 Rev. 1

La especificación prevé hasta 10 hubs en cascada, lo cual viola las reglas de roundtrip

de IEEE 802.350.

De acuerdo con [83], para arbitrar el acceso de ambos tipos de tráfico (RT y NRT) a la

subcapa MAC, el protocolo utiliza un mecanismo de consulta (polling) maestro –

esclavo, implementado en una subcapa intermedia (Ethernet Powerlink Data Link

Layer) que establece el ciclo de acceso al medio, ilustrado en la siguiente Fig. 58.

Fig. 58. Ciclo de Ethernet Powerlink.

Como se puede observar, el ciclo consta de cuatro fases, a saber:

• Trama de inicio de ciclo (Start of Cycle, SoC). El maestro (Managing Node,

MN) envía una trama broadcast que marca el inicio del ciclo y sirve para que los

esclavos (Controlled Nodes, CN) se sincronicen. Esta sincronización es relativa,

es decir, no sirve para distribuir una Hora del Sistema absoluta, sino

simplemente para asegurar que todos los nodos tienen la misma noción del

tiempo transcurrido desde el inicio del ciclo.

• Periodo síncrono. El maestro consulta secuencialmente a los esclavos. Envía una

trama de Poll Request al primer esclavo y queda a la espera de respuesta. Este

esclavo envía una trama de Poll Response en modo broadcast (de este modo se

puede implementar también una comunicación esclavo – esclavo). El maestro

repite la operación sucesivamente con los demás esclavos. El maestro espera

cada trama de respuesta durante un cierto tiempo, expirado el cual, pasa a

consultar el siguiente esclavo. En caso de pérdida de una trama, este mecanismo

50 En estas condiciones, el mecanismo CSMA/CD no funciona, lo cual quiere decir que se confía el control del acceso al medio exclusivamente a la subcapa de Ethernet Powerlink Data Link Layer, explicada a continuación.


130 de 143 Rev. 1

asegura que el proceso de consulta no queda bloqueado. Sin embargo, no evita

que se produzca un cierto alargamiento ocasional (jitter) en el periodo síncrono

y, por tanto, en el ciclo. Además, una trama de respuesta tardía puede colisionar

con otra trama con la consiguiente pérdida de información y el empeoramiento

del jitter. Dada la ausencia de una Hora de Sistema absoluta y las prestaciones

de tiempo real que pretende dar este protocolo, la ausencia de jitter en el ciclo es

esencial. Por ello, cada vez que el jitter de un ciclo supera un cierto umbral, los

esclavos incrementan un contador; Cuando el contador alcanza un cierto valor,

los esclavos pasan de un estado “operacional” a un estado “pre-operacional” y se

interrumpe el intercambio cíclico.

• Periodo asíncrono. Cuando el maestro completa las consultas a todos los

esclavos, transmite un trama broadcast de inicio del periodo asíncrono (SoA,

Start of Asinchronous). Este periodo está explícitamente concebido para tráfico

NRT (TCP/IP), no para tráfico RT acíclico (p. ej., alarmas). Los esclavos que

tienen necesidad de enviar un mensaje NRT deben declararlo en el periodo

síncrono. El maestro decide qué esclavo puede enviar su mensaje NRT (sólo uno

por cada ciclo) y envía una trama de petición a la cual responde el esclavo.

• Periodo reservado (idle). Es un periodo de seguridad, en el que no se produce

tráfico.

En general, el desempeño del protocolo viene limitado por dos factores fundamentales:

• El mecanismo de consulta obliga a ocupar el medio de transmisión con tramas

petición para cada esclavo.

• Durante el tiempo de respuesta de cada esclavo, el medio de transmisión queda

inutilizado.

Según [8], esto puede llevar a que una red de 100 Mbps opere al 25 % de su capacidad,

incluso optimizando los tiempos de respuesta de los esclavos mediante

implementaciones en hardware especial (cosa que en principio no es obligatoria).

La implementación del maestro, sin embargo, sí requiere obligatoriamente una

implementación en hardware especial (no sirve una tarjeta NIC estándar). Esto es


131 de 143 Rev. 1

debido a que es fundamental para el funcionamiento del protocolo la ausencia de jitter

en el ciclo marcado por el maestro.

3.3.3 Productos de mercado

Productos que implementan IEEE 1588. A la hora de seleccionar los diferentes tipos

de dispositivos para formar un dominio de sincronización en una red Ethernet Industrial,

es esencial tener presente que existen dos versiones de la norma IEEE 1588: La del año

2002, que especifica el protocolo PTPv1, y la del 2008, que especifica el protocolo

PTPv2. Ambas normas son incompatibles, de modo que no se pueden mezclar

dispositivos de ambas versiones en un solo dominio de sincronización. A continuación,

se enumeran ejemplos de los diferentes tipos de dispositivos existentes para PTPv2:

• Grandmaster, modelo LANTIME M600/GPS/PTP, marca Meinberg [84]. Posee

un receptor GPS que permite sincronizar su reloj interno con la señal horaria

procedente de los satélites. Además, la gran calidad de su reloj le permite

mantener sus funciones ante interferencias o pérdidas temporales de recepción.

Dentro de la red Ethernet actúa como reloj de referencia (grandmaster) según el

protocolo PTPv2 y también como servidor según protocolo (S)NTP.

• Boundary clock, modelo MICE MM23, marca Hirschmann [25]. Es un switch

Fast Ethernet de 4 puertos, con reloj interno y que puede actuar como boundary

clock según PTPv2.

• Ordinary clock, modelo PTP270PEX, marca Meinberg [84]. Consiste en una

tarjeta PCI express para PC, que actúa como reloj esclavo en un dominio de

sincronización PTPv2. A la vez, puede actuar como servidor (S)NTP en la red

Ethernet.

• Ordinary clock, modelo DP83640, marca National Semiconductor [66]. Se trata

de un PHYTER Fast Ethernet COTS que incorpora toda la funcionalidad PTP

para actuar como reloj esclavo:

o Timestamp de las tramas en la propia capa PHY (incluso más cerca del

medio de transmisión de lo que propone la norma IEEE 1588).

o Soporta mensajes PTP tanto directamente sobre Ethernet (Ethertype

0x88F7) como sobre UDP/IPv4 y UDP/IPv6. Sin embargo, no los

transmite a través de la interfaz MII sino que los utiliza para sincronizar


132 de 143 Rev. 1

el reloj que incorpora en el propio PHYTER. Este reloj se puede utilizar

como la base de tiempo del dispositivo Ethernet en el que va

incorporado.

o Soporta generación de señales sincronizadas y timestamp de señales

recibidas a través de entradas / salidas de propósito general (GPIO).

o Soporta tanto PTPv1 como PTPv2.

o Reivindica una precisión de sincronización con el maestro mejor de 10

nanosegundos.

Productos Ethernet/IP con CIP Sync y CIP Motion. CIP Sync y CIP Motion son

extensiones que permiten paliar parcialmente las limitaciones de Ethernet/IP para

aplicaciones con requerimientos temporales exigentes, como es el caso del control de

movimiento. Los productos de Rockwell Automation en que se implementan estas

extensiones son servo-accionadores (Kitenix) y módulos especificos de PLCs (Control

Logix, etc.).

Productos PROFINET IO. El principal fabricante de equipos PROFINET IO es

Siemens [13]. La mayoría de estos equipos incorpora controladores Ethernet estándares

e implementa el protocolo PROFINET RT, cuyas prestaciones en tiempo real son

suficientes en la mayoría de las ocasiones. Dentro de esta categoría, se incluyen las

diferentes gamas de PLCs (S7-1200, S7-300, S7-400), controladores sobre PC industrial

(WIN AC), módulos de entradas / salidas remotas (ET200), HMIs, analizadores de red

(PAC), switches (SCALANCE).

Sin embargo, para las aplicaciones con requerimientos temporales más exigentes se

utilizan productos que incorporan los controladores Ethernet especiales ERTEC e

implementan el protocolo PROFINET IRT (además del PROFINET RT). Existen

versiones IRT en las gamas de PLCs (S7-1200, S7-300, S7-400), módulos de entradas /

salidas remotas (ET200) y switches (SCALANCE). Además, existen productos que, de

manera nativa, implementan estas altas prestaciones como son los servo-accionamientos

(SINAMICS y SIMOTION) y el control numérico (SINUMERIK). En definitiva,

PROFINET IO se usa en los siguientes tipos de comunicaciones:

• Entre aplicaciones SCADA / HMI y controladores (PLCs o PCs industriales).


133 de 143 Rev. 1

• Entre aplicaciones SCADA / HMI y dispositivos de campo (p.ej. analizadores de

red).

• Entre controladores.

• Entre controladores y módulos de entradas / salidas remotas o bien dispositivos

de campo (p.ej. analizadores de red, accionamientos, servo-accionamientos,

etc.).

Productos EtherCAT. El principal fabricante de productos EtherCAT es Beckhoff

[18]. En su catálogo se encuentran PCs industriales, Panel PCs, módulos de entradas /

salidas remotas (EtherCAT Terminals) y servo-accionamientos (AX5000, etc.).

EtherCAT está muy orientado a las comunicaciones entre un controlador maestro

basado en PC Industrial o Panel PC y un conjunto de módulos de entradas / salidas

remotas y / o servoaccionamientos (segmento EtherCAT). Además, tiene excelentes

prestaciones en cuanto al comportamiento en tiempo real.

Productos Ethernet Powerlink. El principal fabricante de productos que implementan

este protocolo es B&R [19]. En su catálogo se encuentran PCs industriales, HMIs,

PLCs (X20) y servo-accionamientos (ACOPOS). Dadas las características del

protocolo, es apto para aplicaciones con requisitos temporales exigentes.


134 de 143 Rev. 1

4 Conclusiones

4.1 Conclusiones de carácter académico

En su vertiente académica, este estudio pretendió ser un ejercicio para adquirir las

habilidades necesarias en la elaboración de un informe sobre el estado de la técnica. Se

constató que existe una gran cantidad de información sobre la cuestión objeto de

estudio, hasta el punto que puede resultar abrumadora, si no se aborda de una manera

metódica: Sumergirse demasiado pronto en el análisis de fuentes de información

concretas puede llevar a una visión parcial de la cuestión técnica y provocar dudas sobre

la pertinencia del enfoque escogido.

La experiencia ganada durante el estudio nos hace pensar que es aconsejable

aproximarse al cuerpo de artículos de investigación (ya sean de revista académica o de

actas de conferencias) a través de fuentes documentales. Además, el gestor de

referencias bibliográficas se muestra como un recurso muy útil en varias tareas:

• Almacenar de una forma homogénea la metainformación (incluidos los

abstracts) procedente de diferentes fuentes documentales.

• Hacer la clasificación y la criba de los artículos sin necesidad de acceder al texto

completo.

• Servir de repositorio para futuras ampliaciones de la investigación.

• Automatizar la elaboración de bibliografías.

Por otra parte, el acceso a sitios Web resultó más útil de lo esperado en un principio.

Aunque es cierto que existe gran cantidad de información comercial sesgada, también se

encuentra información técnica rigurosa.

Por último, la experiencia durante la redacción del informe nos lleva a creer que el

proceso de redacción no es un paso posterior y separado del proceso de análisis e

interpretación de la información. Más bien, el proceso de redacción hace surgir

interrogantes que requieren volver sobre las fuentes de información para completar la

comprensión de la cuestión técnica, de un modo iterativo.


135 de 143 Rev. 1

4.2 Conclusiones de carácter técnico

En su vertiente técnica, el presente estudio se propuso profundizar en el conocimiento

sobre Ethernet Industrial. Con anterioridad al estudio, los eslóganes comerciales del

sector de la Automatización Industrial, nos condujeron a imaginar que Ethernet

Industrial era un sistema de comunicación digital estándar (común para todos los

fabricantes) y que superaba con creces las capacidades de la diversidad de buses de

campo existentes hasta entonces en el mercado.

Los resultados del estudio, sin embargo, refutaron nuestras esperanzas iniciales. No

existe una única Ethernet Industrial, sino que existen múltiples propuestas

incompatibles entre sí. Además, no en todos los casos las prestaciones de Ethernet

Industrial son mejores que las de los buses de campo tradicionales, al menos en lo

referente al comportamiento en tiempo real.

En efecto, aunque es cierto que la mayoría de las propuestas incorporan las facilidades

estándares propias de las Tecnologías de la Información (HTTP, SNMP, FTP, etc.), el

hecho fundamental es que el mecanismo de transmisión de datos de proceso es diferente

en cada propuesta, lo cual las hace incompatibles entre sí. Por otra parte, no todas las

propuestas de Ethernet Industrial son aptas para aplicaciones en tiempo real. Aquellas

conocidas como Ethernet en Tiempo Real intentan superar esta carencia, con diferentes

grados de éxito.

Una explicación para el fracaso en la especificación de una única Ethernet Industrial

podrían ser los intereses comerciales de los grandes fabricantes del sector. Ya antes de

la aparición de Ethernet Industrial, la incompatibilidad entre los buses de campo

existentes constituía una barrera de entrada mediante la cual cada uno de los principales

fabricantes defendía su cuota de mercado. Es probable que el surgimiento del concepto

Ethernet Industrial fuera visto por fabricantes emergentes como una oportunidad para

introducirse en el mercado. Sin embargo, es razonable pensar que el interés de los

grandes fabricantes era mantener sus cuotas de mercado sin perder el tren de la próxima

generación de sistemas de comunicación industriales prometida por Ethernet. En

consecuencia, podía resultar una salida airosa para estos fabricantes el desarrollo de una


136 de 143 Rev. 1

propuesta de Ethernet Industrial perfectamente integrada con el propio bus de campo y

perfectamente incompatible con las propuestas Ethernet Industrial de otros fabricantes.

Respecto a las dificultades de las propuestas basadas en Ethernet para proporcionar

comportamiento en tiempo real, existen explicaciones claras. Quizás, la más importante

de ellas es la naturaleza intrínsecamente no determinista de Ethernet, tanto de su

mecanismo de acceso al medio (CSMA/CD) como de su mecanismo para interconectar

dominios de colisión (switches). Otra explicación podría ser que su principio de

funcionamiento basado en paquetes implica una infrautilización del ancho de banda

disponible, sobre todo cuando se requiere la transmisión de gran número de mensajes

con poca cantidad de información en cada uno de ellos, que es la situación típica en


Estas dificultades innatas han sido paliadas por las diferentes propuestas introduciendo

modificaciones más o menos importantes en la concepción original de Ethernet. No es

de extrañar, pues, que las propuestas con prestaciones en tiempo real más altas sean las

que introducen modificaciones más drásticas. La información consultada durante este

estudio nos lleva a pensar que las propuestas Ethernet Industrial aptas para las

aplicaciones en tiempo real más exigentes (hard real time) serían, en orden

descendente:

• EtherCAT.

• PROFINET IRT.

• Ethernet Powerlink.

En aplicaciones con requisitos temporales más laxos (soft real time) serían válidas,

también en orden descendente, las siguientes propuestas:

• Ethernet IP con CIP Sync – CIP Motion.

• PROFINET RT.

• Ethernet/IP.

• Modbus TCP.

• PROFINET CBA.


137 de 143 Rev. 1

5 Referencias

[1] R. Sierra Bravo, Tesis Doctorales y Trabajos de Investigación Científica. Madrid: Paraninfo, 1996.

[2] J. Colobrans, El Doctorando Organizado. Zaragoza: Mira, 2001.

[3] M. Schaible, "Searching scientific databases for guides to experiment and theory," Computing in Science & Engineering, vol. 3, pp. 30-39, 2001.

[4] R. Weissberg and S. Buker, Writing Up Research: Experimental Research Report Writing for Students of English. Englewood Cliffs, NJ: Prentice Hall Regents, 1990.

[5] (2010, Oct.). IEEE editorial style manual [Online]. Available: http://www.ieee.org/portal/cms_docs_iportals/iportals/publications/authors/transjnl/stylemanual.pdf.

[6] P. Pedreiras, L. Almeida, and J. A. Fonseca, "The quest for real-time behavior in Ethernet," in The Industrial Information Technology Handbook, R. Zurawski, Ed. Boca Raton: CRC Press, 2005, pp. 48-1-48-14.

[7] J.-D. Decotignie, "Ethernet-based real-time and industrial communications," Proc. IEEE, vol. 93, pp. 1102-1117, Jun. 2005.

[8] J.-D. Decotignie, "The many faces of industrial Ethernet [Past and present]," IEEE Ind. Electron. Mag., vol. 3, pp. 8-19, Mar. 2009.

[9] M. Felser and T. Sauter, "Standardization of industrial Ethernet - The next battlefield?" in Proc. IEEE Int. Workshop Factory Commun. Syst. 2004, pp. 413-420.

[10] M. Felser, "Real-time Ethernet - Industry prospective," Proc. IEEE, vol. 93, pp. 1118-1129, Jun. 2005.

[11] M. Felser, "Real time Ethernet: Standardization and implementations," in IEEE Int. Symp. Industrial Electronics (ISIE), 2010, pp. 3766-3771.

[12] M. Huynh, S. Goose, and P. Mohapatra, "Resilience technologies in Ethernet," Comput. Networks, vol. 54, pp. 57-78, 2010.

[13] Siemens. (2011, Feb.). Industrial communication - Product overview [Online]. Available: http://www.automation.siemens.com/mcms/automation/en/industrial-communications/Pages/Default.aspx.

[14] Siemens. (2011, Feb.). Industrial communication - Product support [Online]. Available: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&objid=10805878&treeLang=en.

[15] Phoenix Contact. (2011, Feb.). Tecnología PROFINET [Online]. Available: http://www.phoenixcontact.es/tecnologia/40911.htm.

[16] Rocwell Automation. (2011, Feb.). Industrial switches [Online]. Available: http://www.ab.com/en/epub/catalogs/12762/2181376/214372/9142990/index.html.


138 de 143 Rev. 1

[17] Rocwell Automation. (2011, Feb.). Networks and communications [Online]. Available: http://www.ab.com/networks/architectures3.html.

[18] Beckhoff. (2011, Feb.). EtherCAT (Ethernet for control automation technology) [Online]. Available: http://www.beckhoff.com/ethercat/.

[19] B&R. (2011, Feb.). Product overview [Online]. Available: http://www.br-automation.com/.

[20] Schneider Electric. (2011, Feb.). Redes Ethernet y buses de campo [Online]. Available: http://www.schneiderelectric.es/spain/es/productos-servicios/productos-servicios-intermediate.page?f=NNM1:Redes+Ethernet+y+buses+de+campo&p_function_id=12.

[21] TTTech. (2011, March). Time-triggered Ethernet [Online]. Available: http://www.tttech.com/products/ttethernet/technology/.

[22] Korenix. (2011, March). Korenix Web site [Online]. Available: http://www.korenix.com/.

[23] Moxa. (2011, March). Industrial Ethernet [Online]. Available: http://www.moxa.com/industrial_ethernet/index.htm.

[24] O-ring. (2011, March). O-ring Web site [Online]. Available: http://www.oring-networking.com/.

[25] Hirschmann. (2011, March). Industrial Ethernet product overview [Online]. Available: http://www.beldensolutions.com/en/Brands-Products/Hirschmann_Produkte/Industrial_Ethernet/index.phtml.

[26] UNED. (2010, Oct.). Bases de datos en línea por materias [Online]. Available: http://www.uned.es/biblioteca/referencia/basesdedatosmaterias.htm.

[27] IEEE. (2010, Oct.). IEEE Xplore Digital Library [Online]. Available: http://ieeexplore.ieee.org.

[28] Elsevier. (2010, Oct.). Engineering Village [Online]. Available: http://www.engineeringvillage2.com.

[29] Thomson Reuters. (2010, Oct.). Web of Knowledge [Online]. Available: http://www.isiwebofknowledge.com.

[30] ACM. (2010, Oct.). ACM Digital Library [Online]. Available: http://www.acm.org.

[31] Elsevier. (2010, Oct.). Science direct [Online]. Available: http://www.info.sciencedirect.com.

[32] A. Paiz. (2011, Aug.). Búsqueda de artículos sobre Ethernet industrial - Resultados [Online]. Available: http://www.refworks.com/refshare/?site=041891166590800000/RWWEB106129337/IND-ETH_PAPERS_SEARCH.

[33] A. Paiz. (2011, Aug.). Búsqueda de artículos sobre Ethernet industrial - Preselección [Online]. Available: http://www.refworks.com/refshare/?site=041891166590800000/RWWEB106129337/IND-ETH_PAPERS_PRESELEC.

[34] A. Paiz. (2011, Aug.). Búsqueda de artículos sobre Ethernet industrial. Selección [Online]. Available:


139 de 143 Rev. 1

http://www.refworks.com/refshare/?site=041891166590800000/RWWEB106129337/IND-ETH_PAPERS_SELEC.

[35] IEB Media. (2011, March). Industrial Ethernet book [Online]. Available: http://www.iebmedia.com/.

[36] A. Paiz. (2011, Aug.). Búsqueda de sitios Web y documentos on-line sobre Ethernet - Preselección [Online]. Available: http://www.refworks.com/refshare/?site=041891166590800000/RWWEB106129337/IND-ETH_ONLINE_PRESELEC.

[37] A. Paiz. (2011, Aug.). Búsqueda de sitios Web y documentos on-line sobre Ethernet - Selección [Online]. Available: http://www.refworks.com/refshare/?site=041891166590800000/RWWEB106129337/IND-ETH_ONLINE_SELEC.

[38] IETF. (2011, Aug.). Internet standards [Online]. Available: http://www.ietf.org/.

[39] IEEE. (2011, March). IEEE 802 standards [Online]. Available: http://standards.ieee.org/about/get/index.html.

[40] Institute of Embedded Systems. (2011, March). IEEE 1588 - Precision time protocol [Online]. Available: http://www.ines.zhaw.ch/en/engineering/ines/ieee-1588.html.

[41] (2011, March). IEEE standards for local and metropolitan area networks: Overview and architecture. IEEE Std 802-2001 [Online]. Available: http://standards.ieee.org/about/get/802/802.html.

[42] T. Socolofsky and C. Kale. (2011, Aug.). A TCP/IP tutorial [Online]. 1991. Available: http://datatracker.ietf.org/doc/rfc1180/.

[43] (2011, March). IEEE standard for information technology--telecommunications and information exchange between systems--local and metropolitan area networks--specific requirements part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - section one. IEEE Std 802. 3-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.3.html.

[44] (2011, March). IEEE standard for information technology--telecommunications and information exchange between systems--local and metropolitan area networks--specific requirements part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - section two. IEEE Std 802. 3-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.3.html.

[45] (2011, March). IEEE standard for information technology--telecommunications and information exchange between systems--local and metropolitan area networks--specific requirements part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - section three. IEEE Std 802. 3-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.3.html.

[46] (2011, March). IEEE standard for information technology--telecommunications and information exchange between systems--local and metropolitan area networks--specific requirements part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - section four. IEEE Std 802. 3-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.3.html.

[47] (2011, March). IEEE standard for information technology--telecommunications and information exchange between systems--local and metropolitan area networks--specific requirements part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - section five. IEEE Std 802. 3-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.3.html.


140 de 143 Rev. 1

[48] (2011, March). IEEE standard for local and metropolitan area networks media access control (MAC) bridges. IEEE Std 802. 1D-2004 [Online]. Available: http://standards.ieee.org/about/get/802/802.1.html.

[49] (2011, March). IEEE standard for local and metropolitan area networks virtual bridged local area networks. IEEE Std 802. 1Q-2005 [Online]. Available: http://standards.ieee.org/about/get/802/802.1.html.

[50] (2011, March). IEEE standard for local and metropolitan area networks - link aggregation. IEEE Std 802. 1AX-2008 [Online]. Available: http://standards.ieee.org/about/get/802/802.1.html.

[51] (2011, March). IEEE standard for local and metropolitan area networks - station and media access control connectivity discovery. IEEE Std 802. 1AB-2009 [Online]. Available: http://standards.ieee.org/about/get/802/802.1.html.

[52] D. Mills. (2011, March). Network time protocol version 4: Protocol and algorithms specification [Online]. 2010. Available: http://datatracker.ietf.org/doc/rfc5905/.

[53] M. Jones. (2011, March). Interfacing Fast Ethernet to processors [Online]. Available: http://www.micrel.com/_PDF/Ethernet/White%20Paper/Interfacing%20Ethernet%20to%20processors.pdf.

[54] Phoenix Contact. (2011, March). Ethernet basics (rev. 02) [Online]. Available: http://select.phoenixcontact.com/phoenix/dwl/dwlfr1.jsp?lang=es.

[55] MODBUS-IDA. (2011, March). Modbus users' Web site [Online]. Available: http://www.modbus-ida.org/.

[56] MODBUS-IDA. (2011, March). Modbus application protocol specification v1.1b [Online]. 2006. Available: http://www.modbus-ida.org/docs/Modbus_Application_Protocol_V1_1b.pdf.

[57] MODBUS-IDA. (2011, March). Modbus messaging on TCP/IP implementation guide v1.0b [Online]. 2006. Available: http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf.

[58] ODVA. (2011, Feb.). ODVA users' Web site [Online]. Available: http://www.odva.org/.

[59] Rockwell Automation. (2011, March). EtherNet/IP performance [Online]. 2004. Available: http://literature.rockwellautomation.com/idc/groups/literature/documents/ap/enet-ap001_-en-p.pdf.

[60] X. Qian, S. He, D. Guo, and Y. Jing, "On time-critical data transmission of EtherNet/IP," in 6th World Congr. Intelligent Control Automation (WCICA '06), Dalian, China, 2006, pp. 4623-4625.

[61] C. Rojas and P. Morell, "Guidelines for industrial Ethernet infrastructure implementation: A control engineer's guide," in 52nd IEEE-IAS/PCA Cement Ind. Tech. Conf., 2010, pp. 1-18.

[62] Wireshark Foundation. (2011, March). Wireshark network protocol analyzer [Online]. Available: http://www.wireshark.org/.

[63] A. Moldovansky, S. Balasubramanian, and B. Batke. (2011, Aug.). Introduction to device level ring topology for EtherNet/IP [Online]. pp. 35. 2009. Available: http://www.iebmedia.com/.


141 de 143 Rev. 1

[64] PI. (2011, March). PROFINET users' Web site [Online]. Available: http://www.profibus.com/.

[65] Micrel. (2011, March). Ethernet ICs [Online]. Available: http://www.micrel.com/page.do?page=product-info/ether_over.jsp.

[66] National Semiconductor. (2011, March). Ethernet solutions [Online]. Available: http://www.national.com/analog/interface/ethernet.

[67] Rockwell Automation. (2011, March). Stratix switch reference chart [Online]. 2010. Available: http://literature.rockwellautomation.com/idc/groups/literature/documents/qr/enet-qr001_-en-e.pdf.

[68] H. Kopetz, Real-Time Systems : Design Principles for Distributed Embedded Applications. Boston: Kluwer Academic Publishers, 1997.

[69] A. Soppelsa, A. Luchetta, and G. Manduchi, "Assessment of Precise Time Protocol in a prototype system for the ITER neutral beam test facility," IEEE Trans. Nucl. Sci., vol. 57, pp. 503-509, Apr., 2010.

[70] H. Weibel. (2011, March). Technology update on IEEE 1588: The second edition of the high precision clock synchronization protocol [Online]. 2009. Available: http://www.ines.zhaw.ch/fileadmin/user_upload/engineering/_Institute_und_Zentren/INES/Downloads/Technology_Update_IEEE1588_v2.pdf.

[71] H. Weibel. (2011, March). IEEE 1588 tutorial [Online]. 2006. Available: http://www.ines.zhaw.ch/fileadmin/user_upload/engineering/_Institute_und_Zentren/INES/IEEE1588/Dokumente/2006_Conference_IEEE_1588_Tutorial.pdf

[72] R. S. H. Piggin, "Developments in real-time control with Ethernet," in Int. Technology Innovation Conf. (ITIC '06), 2006, pp. 2161-2168.

[73] J. Jasperneite, J. Imtiaz, M. Schumacher, and K. Weber, "A proposal for a generic real-time Ethernet system," IEEE Trans. Ind. Informat., vol. 5, pp. 75-85, May 2009.

[74] SIEMENS. (2011, March). SIMATIC PROFINET system description [Online]. 2010. Available: http://support.automation.siemens.com/WW/llisapi.dll?query=A5E00298288-05&func=cslib.cssearch&content=adsearch%2Fadsearch.aspx&lang=en&siteid=cseus&objaction=cssearch&searchinprim=0&nodeid0=18881362&x=15&y=9.

[75] SIEMENS. (2011, March). ERTEC 200 data sheet v1.1.2 [Online]. 2010. Available: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&objid=26539425&treeLang=en.

[76] SIEMENS. (2011, March). ERTEC 400 data sheet v1.2.2. [Online]. 2010. Available: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&objid=26539425&treeLang=en.

[77] P. Ferrari, A. Flammini, S. Rinaldi, and E. Sisinni, "On the seamless interconnection of IEEE1588-based devices using a PROFINET IO infrastructure," IEEE Trans. Ind. Informat., vol. 6, pp. 381-392, Aug. 2010.

[78] ETG. (2011, Feb.). EtherCAT users' Web site [Online]. Available: http://www.ethercat.org/.


142 de 143 Rev. 1

[79] Beckhoff. (2011, March). EtherCAT slave controller ET1100 - Hardware data sheet v1.8 [Online]. 2010. Available: http://www.beckhoff.com/ethercat/.

[80] M. Rostan. (2011, March). Industrial Ethernet technologies [Online]. 2011. Available: http://www.ethercat.org/pdf/english/Industrial_Ethernet_Technologies.pdf.

[81] Beckhoff. (2011, March). EtherCAT slave controller PHY selection guide v1.7 [Online]. 2010. Available: http://www.beckhoff.com/ethercat/.

[82] EPSG. (2011, Feb.). Ethernet POWERLINK users' Web site [Online]. Available: http://www.ethernet-powerlink.org/.

[83] G. Cena, L. Seno, A. Valenzano, and S. Vitturi, "Performance analysis of Ethernet Powerlink networks for distributed control and automation systems," Comput. Standards & Interfaces, vol. 31, pp. 566-572, 2009.

[84] Meinberg. (2011, March). PTP / IEEE 1588 [Online]. Available: http://www.meinberg.de/english/products/timesource.htm#ptp.


143 de 143 Rev. 1

6 Anexos

6.1 Anexo I. Guía de fuentes documentales para la ingeniería

(Véanse páginas anexas).

6.2 Anexo II. Búsqueda y selección de artículos


6.3 Anexo III. Sitios Web analizados


Informe sobre el estado de la técnica.Ethernet Industrial. Protocolos e implementaciones de mercado

ANEXO I: GUÍA DE FUENTES DOCUMENTALES EN INGENIERÍA

Naturaleza básica Abstracts? Citas? Alertas? Full text?IEEExplore IEEE IEEExplore Índice analítico Sí No Sí Sí Journals, conference proceedings,

ANSI/IEEE standards, books,courses

Ingeniería eléctrica, electrónica eInformática

www.ieeexplore.ieee.org Publicaciones IEEE, IET (antiguamente IEE), AIP yAVS. La base de datos está indexada por INSPEC(IET)

CiberUned remoto http://poa5.uned.es/

INSPEC IET (antiguamenteIEE)

Engineering Villagey tambiénWeb of Knowledge(Thomson Reuters)

Índice analítico Sí No Sí No Journals, conference proceedings,books, reports, and dissertations

Física, Ingeniería eléctrica, de control eInformática

www.engineeringvillage2.com Campos adicionales con info evaluadora. Porejemplo: contenido práctico, teórico, etc.

La UNED no tienesubscripción. (LaUPC sí)

---

Compendex EI Engineering Village Índice analítico Sí No Sí No Journals and conference proceedings Ingeniería www.engineeringvillage2.com Prestigiosa sobre todo en ingeniería mecánica, civily química

La UNED no tienesubscripción. (LaUPC sí)

---

ACM Digital Library ACM ACM Portal Índice analítico Sí Sí No Sí Journals, magazines, proceedings Informática www.acm.org Publicaciones ACM a texto completo CiberUned remoto http://poa32.uned.es/portal.cfmACM Guide ACM ACM Portal Índice analítico Sí Sí No No Journals, magazines, proceedings Informática www.acm.org Publicaciones ACM y de otras editoriales. Cuando

corresponden a otras editoriales, sólo ofrecereferencia bibliográfica y abstract.

CiberUned remoto http://poa32.uned.es/portal.cfm

CC Connect ISI Web of Knowledge(Thomson Reuters)

Índice de sumarios Sí No ? No Journals and web sites Multidisciplinar www.isiwebofknowledge.com Su punto fuerte es la actualidad de la informaciónmostrada. Adecuada para detectar tendenciasemergentes y realizar vigilancia tecnológica

RedUned en CentroAsociado

www.accesowok.fecyt.es/ccc

SCI Expanded ISI Web of Knowledge(Thomson Reuters)

Índice de citas No Sí Sí No Journals Multidisciplinar www.isiwebofknowledge.com Su punto fuerte es el análisis de citas, que permiteevaluar relevancia / impacto de los artículos.Adecuado para búsquedas retrospectivas


www.accesowok.fecyt.es/wos

Conference Proceeding CitationIndex

ISI Web of Knowledge(Thomson Reuters)

Índice de citas ? Sí ? No Proceedings of conferences,symposia, seminars, colloquia,workshops and conventions

Multidisciplinar www.isiwebofknowledge.com A diferencia de Current Contents y Science CitationIndex Expanded, se centra en Actas (proceedings)de todo tipo de eventos. Por tanto, escomplementario a las fuentes mencionadas antes


www.accesowok.fecyt.es/wos

ISI Highly Cited ISI Web of Knowledge(Thomson Reuters)

Directorio N/A N/A N/A N/A Datos profesionales deinvestigadores

Multidisciplinar www.isihighlycited.com Útil para identificar investigadores de referencia,altamente citados

Acceso libre www.isihighlycited.com

Essencial Science Indicators ISI Web of Knowledge(Thomson Reuters)

Herramienta análisis N/A N/A N/A N/A Journals Multidisciplinar www.isiwebofknowledge.com Esta herramienta permite establecer un ranking decientíficos, instituciones, paises y revistasacadémicas (journals) en función de:- la cantidad de publicaciones- la calidad de las mismas (estimada a través de lacantidad de citas postieriores que reciben)


www.accesowok.fecyt.es/esi

Journal Citation Reports ISI Web of Knowledge(Thomson Reuters)

Herramienta análisis N/A N/A N/A N/A Journals Multidisciplinar www.isiwebofknowledge.com Herramienta de evaluación de revistas basándoseen el número de veces que han sido citados susartículos


www.accesowok.fecyt.es/jcr

Willey Interscience Willey Interscience Willey Interscience Índice analítico Sí Sí No Sí Journals, books, reference works Multidisciplinar http://www3.interscience.wiley.com/search/allsearch

Su alcance se limita a publicaciones de WilleyInterscience. Da acceso libre a las referenciasbibliográficas y los abstracts. Para acceder al textocompleto y al rastreo de citas, es necesariasubscripción

Acceso libre parcial http://www3.interscience.wiley.com/search/allsearch

ArticleFinder INFOTRIEVE INFOTRIEVE Índice analítico Sí No No Sí Journals Multidisciplinar www.corporate.infotrieve.com Da acceso libre a las referencias bibliográficas y losabstract. Para acceder al texto completo esnecesario previo pago

Acceso libre parcial http://www4.infotrieve.com/search/databases/newsearch.asp

ScienceDirect Elsevier Elsevier Índice analítico Sí No Sí Sí Journals and books Multidisciplinar www.info.sciencedirect.com Su alcance se limita a publicaciones de Elsevier.Da acceso libre a referencias bibliográficas yabstracts. Para la mayoría de los artículos derevista, da acceso al texto completo. Para el restode artículos de revista y los libros, el acceso esprevio pago

CiberUned remoto http://poa2.uned.es/science/publications/journal/

SpringerLink Springer Springer Índice analítico No No Sí Sí Journals and books Multidisciplinar www.springer.com Su alcance se limita a publicaciones de Springer.Da acceso libre a referencias bibliográficas. Para elresto de funcionalidades, es necesario el accesoinstitucional

RedUned en CentroAsociado http://www.springerlink.com/app/

home/main.asp?wasp=199be3112a9b4d588524da447747a1aa

SWETSWISE SWETSWISE SWETSWISE Índice de sumarios No No No A veces Journals and magazines Multidisciplinar http://poa14.uned.esAcademic Search Premier EBSCO EBSCO-Host Índice analítico Sí No Sí Sí Journals, magazines, proceedings Multidisciplinar www.ebscohost.com No parece muy fuerte en ingeniería CiberUned remoto http://poa1.uned.es/search/E-journals EBSCO EBSCO-Host Índice analítico Sí No Sí No Journals Multidisciplinar www.ebscohost.com No parece muy fuerte en ingeniería. Por otra parte,

no confundir con el servicio de subscripción arevistas electrónicas (EJS) de EBSCO-Host. E-journals es una base de datos que abarcaALGUNAS de las revistas de la lista de EJS y, entodo caso, no da acceso al texto completo

CiberUned remoto http://poa1.uned.es/search/

Greenfile EBSCO EBSCO-Host Índice analítico Sí Sí Sí Sí Diversos Medio ambiente www.ebscohost.com Relevante para energías renovables CiberUned remoto http://poa1.uned.es/search/The Serials Directory EBSCO EBSCO-Host Directorio N/A N/A N/A N/A Publicaciones periódicas Multidisciplinar www.ebscohost.com Útil para buscar publicaciones sobre un

determinado tema e información de contacto deeditoriales

CiberUned remoto http://poa1.uned.es/search/

UNED UNED UNED Directorio No No No Sí Journals Multidisciplinar http://poa11.uned.es/atoz/home.asp?id=uned

En algunas bases de datos, al intentar acceder altexto completo, pueden aparecer problemas deconnectividad si se utiliza un acceso externo a laUNED. En estos casos, una vez conocida lareferencia bibliográfica del artículo en cuestión,puede consultarse el directorio de revistas suscritaspor la UNED para ver si entre ellas se encuentra ladel artículo deseado. Esta vía alternativa sí daráacceso al texto completo

CiberUned remoto http://poa11.uned.es/atoz/home.asp?id=uned

ICYT CSIC CSIC Índice analítico Sí No No No Journals, conference proceedings Ciencia y tecnología http://bddoc.csic.es:8080/index.jsp

Ámbito de publicaciones en español CiberUned remoto http://poa26.uned.es

Accesibilidad Hiperlink CiberUNEDOrganización Plataforma proveedora Tipo de Fuente de Información Área de conocimiento Hiperlink abierto ComentariosTipo de Fuente DocumentalFuente documental

JOURNALS, CONFERENCE PROCEEDINGS, etc.

Anexo I. Pág. 1 de 2 Rev. 1


ANEXO I: GUÍA DE FUENTES DOCUMENTALES EN INGENIERÍA

Naturaleza básica Abstracts? Citas? Alertas? Full text?Accesibilidad Hiperlink CiberUNEDOrganización Plataforma proveedora Tipo de Fuente de Información Área de conocimiento Hiperlink abierto ComentariosTipo de Fuente DocumentalFuente documental

WorldCat OCLC WorldCat Catálogo No No No A veces Documentos de todo tipo Multidisciplinar www.worldcat.org Permite hacer búsquedas por palabras clave. En lalista de resultados, aparecen datos bibliográficos ybibliotecas donde se encuentran físicamenteejemplares del documento. Si es un recursoelectrónico, a veces da acceso al propio recurso.

Acceso libre www.worldcat.org

FirstSearch OCLC OCLC Índice analítico ? ? ? ? Documentos de todo tipo Multidisciplinar www.firstsearch.oclc.org Servicio de acceso a múltiples bases de datosdocumentales de diferente naturaleza: PapersFirst(Papers presentados conferencias),ProceedingsFirst (información sobre dichosencuentros), ArticleFirst, WorldCat, etc.

La UNED no tienesubscripción

---

OAISTER OCLC OCLC Índice analítico No No No Sí Sitios Web Multidisciplinar www.oaister.worldcat.org Permite acceder a documentos sobre temascientíficos y tecnológicos, pero no parece que seande primer nivel

Acceso libre www.oaister.worldcat.org/

SCIRUS SCIRUS SCIRUS Índice analítico No No No No Sitios Web Multidisciplinar www.scirus.com Adecuada para sondear páginas personales deinvestigadores, material de cursos, material enservidores web, etc.

Acceso libre www.scirus.com

TESIS DOCTORALES Y DEMASTER

Proquest Dissertation andThesis database

ProQuest ProQuest Índice analítico Sí No Sí No Doctoral dissertations and Master'sthesis

Multidisciplinar www.proquest.com/en-US/products/dissertations

La mayoría de las veces permite el acceso a lasprimeras páginas del documento (índice)

CiberUned remoto http://poa20.uned.es/login/ipauto

Derwent Innovation Index ISI Web of Knowledge(Thomson Reuters)

Índice de citas Sí Sí Sí Sí Solicitudes de patente Multidisciplinar www.isiwebofknowledge.com Muy potente RedUned en CentroAsociado

www.accesowok.fecyt.es/diidw

espacenet EPO espacenet Índice analítico Sí Sí No Sí Solicitudes de patente Multidisciplinar www.epo.org Solicitudes de patentes presentadas en la oficinaeuropea de patentes (EPO), en la oficinainternacional de patentes (WIPO) y en las oficinasnacionales de patentes de 80+ países("worldwide"). Para cada uno de los anterioresgrupos, hay una base de datos diferente, condiferentes grados de facilidad para realizarbúsquedas (abstracts, citas, clasificación depatentes, estado legal, etc). Es importante conocerlas peculiaridades de cada base de datos antes derealizar búsquedas.Para las patentes europeas, se utiliza laClasificación Europea de Patentes (ECLA), que seha construído y se actualiza en base a laClasificación Internacional de Patentes (IPC). LaECLA es más detallada que la IPC, y por tanto másprecisa.

Acceso libre http://ep.espacenet.com

INVENES OEPM OEPM Índice analítico Sí No No Sí Solicitudes de patente y modelos deutilidad

Multidisciplinar www.oepm.es Solicitudes de patentes y modelos de utilidad coninformación sobre fechas significativas detramitación (a nivel PCT, a nivel europeo) y a nivelnacional

Acceso libre http://invenes.oepm.es

APPFT USPTO USPTO Índice analítico Sí No No Sí Solicitudes de patente Multidisciplinar www.uspto.gov Solicitudes de patentes de EEUU a texto completo Acceso libre http://appft.uspto.gov

PATFT USPTO USPTO Índice analítico Sí Sí No Sí Patentes (ya concedidas) Multidisciplinar www.uspto.gov Patentes de EEUU a texto completo. El sistema declasificación de la USPTO no se basa en el sistemainternacional (IPC). Hay información sobre lasconcordancias en http://www.uspto.gov/web/patents/classification

Acceso libre http://patft.uspto.gov

PATENTES

SITIOS WEB

DIVERSOS

Anexo I. Pág. 2 de 2 Rev. 1


ANEXO II: BÚSQUEDA Y SELECCIÓN DE ARTÍCULOS

Título de publicación (revista académica) Comentarios sobre la orientación de la publicación IEEE Xplore ACM Science Direct ...SEARCH ...PRESELEC ...SELECCommunications Magazine, IEEE No relevante (orientado a multimedia más que a la industria) 4 4Computer No relevante 2 2

Computer CommunicationsRelevantes (los artículos encontrados son antiguos. Pueden servir para aclarar conceptosbásicos de Ethernet) 12 12 4

Computer NetworksRelevantes. Artículos sobre modificaciones sobre Ethernet para hacerla compatible contiempo real 3 3 3 1

Computer Networks and ISDN SystemsRelevantes. Artículos sobre modificaciones sobre Ethernet para hacerla compatible contiempo real 3 3 2

Computer Standards & Interfaces Muy relevante. Se proponen modificaciones de Ethernet para aplicaciones en tiempo real 7 7 5 2Computers in Industry No relevante 2 2Computers, IEEE Transactions on No relevante 2 2Computing & Control Engineering Journal Relevante. Orientada a la industria en general (tipo magazine) 18 18 8 3Consumer Electronics, IEEE Transactions on No relevante (orientado a diseño de dispositivos para el hogar) 4 4Control Engineering Practice Relevante 5 5 2Control Systems Magazine, IEEE Relevante 2 2 1Engineering Applications of Artificial Intelligence No relevante 2 2

Fusion Engineering and Design

No relevante. Artículos muy especializados en sistemas de adquisición de datos en centrosexperimentales en física de altas energías (p. ej. CERN). Aún así se ha seleccionado unartículo sobre IEEE 1588 25 25 1 1

IEE Review No relevante 2 2Industrial Electronics Magazine, IEEE Relevante 2 2 1 1Industrial Electronics, IEEE Transactions on Relevante 5 5 2 1Industrial Informatics, IEEE Transactions on Relevante. 14 14 8 4Industry Applications Magazine, IEEE No relevante 2 2

Instrumentation and Measurement, IEEE Transactions onNo relevante (se centran en instrumentación para motorizar comportamiento de redesEthernet 5 5

Integration, the VLSI Journal No relevante 2 2ISA Transactions No relevante 2 2Journal of Parallel and Distributed Computing No relevante 2 2Lightwave Technology, Journal of No relevante (se centran en comunicaciones Ethernet via fibra óptica) 8 8Manufacturing Engineer Relevante (artículos de visión panorámica) 2 2 2Mechatronics, IEEE/ASME Transactions on No relevante 2 2Network, IEEE No relevante 2 2Networking, IEEE/ACM Transactions on No relevante 2 2

Nuclear Science, IEEE Transactions on Relevante. Algunos artículos se centran en la problemática de Ethernet en tiempo real. Otrosse centran en experimentos de física nuclear 34 34 4 1

Parallel and Distributed Systems, IEEE Transactions on No relevante 3 3 1Power Delivery, IEEE Transactions on No relevante 3 3 1Power Systems, IEEE Transactions on No relevante 2 2Proceedings of the IEEE Relevante (orientado a artículos de visión panorámica) 3 3 3 2Review of Scientific Instruments No relevante 3 3Robotics & Automation Magazine, IEEE No relevante 2 2Robotics and Computer-Integrated Manufacturing No relevante 2 2Selected Areas in Communications, IEEE Journal on No relevante 3 3Visualization and Computer Graphics, IEEE Transactions on No relevante 2 2Otros Relevante. Algunos artículos 23 4 18 45 4

Subtotal: 156 4 85 245 52 16

IEEE Xplore ACM Science Direct --- --- ...SELEC1 11 11 11 11 11 11 11 11 11 11 11 1

Subtotal: 12 0 0 12

TOTAL: 28

Int. Technology Innovation Conf. (ITIC '06)

IEEE Int. Symp. Precision Clock Synchronization for Measurement, Control and Communication (ISPCS '07)Real-Time Syst. Symp. 2008SICE Annu. Conf. Sapporo, Japan, 2004Int. Joint Conf. SICE-ICASE, Bexco, Korea, 2006

Proc. IEEE Int. Workshop Factory Commun. Syst. 2004Industrial Electronics (ISIE), 2010 IEEE International Symposium on2nd IEEE Int. Conf. Inform. Manage. Eng. (ICIME '10)6th World Congr. Intelligent Control Automation (WCICA '06)

Título de publicación (acta de conferencia)8th IEEE Int. Symp. Object-Oriented Real-Time Distributed Computing (ISORC '05), 52nd IEEE-IAS/PCA Cement Ind. Tech. Conf. 2010Automation and Systems (ICCAS), 2010 International Conference on

Resultado de la búsqueda automática endiferentes fuentes documentales

Proceso de selección manual en diferentes carpetas de laherramienta RefWorks IND-ETH_PAPERS_...

Número de artículos (revista académica)

Identificación de artículos relevantes endiferentes fuentes documentales

Incorporación directa en la carpeta de la herramientaRefWorks IND-ETH_PAPERS_...

Número de artículos (acta de conferencia)

Anexo II. Pág. 1 de 1 Rev. 1


ANEXO III: BÚSQUEDA Y SELECCIÓN DE SITIOS WEB Y DOCUMENTOS ON-LINE

Sector Organización Tema URL del sitio Web Fecha de acceso Comentarios sobre el contenido del sitio Web Sitios Web Documentos Sitios Web Documentos

GENERAL

IEB Media Industrial Ethernet Book http://www.iebmedia.com/ 02/03/2011 Sitio Web con información multifabricante. Proporciona guías decompra, artículos técnicos, noticias del sector, etc. Muy adecuadopara estar al corriente de la evolución del mercado.

1 1 1 1

Siemens Industrial Communication -Product Overview

http://www.automation.siemens.com/mcms/automation/en/industrial-communications/Pages/Default.aspx

22/02/2011 Información comercial referente a toda la gama de productosSIEMENS en el ámbito de las comunicaciones industriales(Ethernet Industrial y PROFINET, entre otras tecnologías)

1 0 1 0

Siemens Industrial Communication -Product Support

http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&objid=10805878&treeLang=en

22/02/2011 Manuales técnicos de los productos SIEMENS en el ámbito de lascomunicaciones industriales (Ethernet Industrial y PROFINET,entre otras tecnologías)

1 5 1 4

Phoenix Contact Tecnología PROFINET http://www.phoenixcontact.es/tecnologia/40911.htm 21/02/2011 Divulgación sobre características técnicas de PROFINET y de losproductos relacionados de Phoenix Contact.

1 1 1 1

Rocwell Automation Industrial Switches http://www.ab.com/en/epub/catalogs/12762/2181376/214372/9142990/index.html

23/02/2011 Gama completa de switches industriales y de accesorios deconexión.

1 3 1 2

Rocwell Automation Networks and Communications http://www.ab.com/networks/architectures3.html 23/02/2011 Guías sobre Ethernet/IP y arquitecturas para la fabricación. 1 3 1 0

Beckhoff EtherCAT (Ethernet for ControlAutomation Technology)

http://www.beckhoff.com/ethercat/ 24/02/2011 Información comercial y técnica sobre todos los productos deBECKHOFF con protocolo EtherCAT.

1 4 1 2

B&R Product Overview http://www.br-automation.com/ 25/02/2011 Información comercial y técnica sobre todos los productos de B&Rcon protocolo Ethernet POWERLINK.

1 0 1 0

Schneider Electric Redes Ethernet y buses decampo

http://www.schneiderelectric.es/spain/es/productos-servicios/productos-servicios-intermediate.page?f=NNM1:Redes+Ethernet+y+buses+de+campo&p_function_id=12

28/02/2011 Información comercial y técnica sobre switches industriales ycontroladores con interface Ethernet.

1 2 1 1

Moxa Industrial Ethernet http://www.moxa.com/industrial_ethernet/index.htm 20/03/2011 Información comercial y técnica sobre una variedad decomponentes de red para Ethernet Industrial. Cabe destacar unaoferta especialmente dirigida a la automatización desubestaciones eléctricas conforme a 61850-3.

1 0 0 0

TTTech Time-Triggered Ethernet http://www.tttech.com/products/ttethernet/technology/ 02/03/2011 Información comercial sobre una gama de productos queincorporan el protocolo Time-Triggered Ethernet. Básicamenteson kits de desarrollo y material de laboratorio.

1 1 0 0

Korenix Korenix Web Site http://www.korenix.com/ 20/03/2011 Información comercial y técnica sobre una variedad decomponentes de red para Ethernet Industrial.

1 0 0 0

O-ring O-ring Web Site http://www.oring-networking.com/ 20/03/2011 Información comercial y técnica sobre una variedad decomponentes de red para Ethernet Industrial.

1 0 0 0

Hirshmann Industrial Ethernet ProductOverview

http://www.beldensolutions.com/en/Brands-Products/Hirschmann_Produkte/Industrial_Ethernet/index.phtml

20/03/2011 Información comercial y técnica sobre la gama de componentesde red para Ethernet Industrial.

1 1 1 0

Minberg PTP / IEEE 1588 http://www.meinberg.de/english/products/timesource.htm -ptp

20/03/2011 Información comercial y técnica sobre la gama de componentespara la sincronización horaria conformes con PTPv2(Grandmasters con fuente horaria vía GPS y tarjetas PCIe paraordenador).

1 2 1 0

National Semiconductor Ethernet Solutions http://www.national.com/analog/interface/ethernet 20/03/2011 Fabricante de circuitos integrados. Contiene información técnicasobre soluciones de hardware para implementar las capas PHYy/o MAC de Ethernet. Destaca el PHY compatible con IEEE1588v1 y v2.

1 1 1 1

Micrel Ethernet ICs http://www.micrel.com/page.do?page=product-info/ether_over.jsp

20/03/2011 Fabricante de circuitos integrados. Contiene información técnicasobre una amplia gama de soluciones de hardware paraimplementar las capas PHY y/o MAC de Ethernet.

1 1 1 1

...PRESELECEQ

UIP

OS

DE

AU

TOM

ATI

ZAC

IÓN

EQU

IPO

S A

CTI

VOS

DE

RED

Proceso de selección manual en diferentes carpetas de laherramienta RefWorks IND-ETH_ONLINE_...

...SELEC

Anexo III. Pág. 1 de 2 Rev. 1


ANEXO III: BÚSQUEDA Y SELECCIÓN DE SITIOS WEB Y DOCUMENTOS ON-LINE

Sector Organización Tema URL del sitio Web Fecha de acceso Comentarios sobre el contenido del sitio Web Sitios Web Documentos Sitios Web Documentos...PRESELEC

Proceso de selección manual en diferentes carpetas de laherramienta RefWorks IND-ETH_ONLINE_...

...SELEC

IEEE 1588 StandardizationGroup

IEEE 1588 - Precision TimeProtocol

http://ieee1588.nist.gov 01/03/2011 Información sobre la norma IEEE 1588 (versión 1). Se mencionaque está en proceso una revisión 2, pero no se da informaciónsobre ella, aunque en realidad ya fue aprobada en 2008. Pareceque no están actualizados los contenidos del sitio Web.

1 1 1 1

Dirk S. Mohl IEEE 1588 - Precision TimeProtocol

http://www.ieee1588.com/ 01/03/2011 Descripción somera de los principios de funcionamiento de IEEE1588. El autor es el responsable del departamento de EthernetIndustrial de Hirschmann Automation and Control.

1 0 0 0

Institute of EmbeddedSystems

IEEE 1588 - Precision TimeProtocol

http://www.ines.zhaw.ch/en/engineering/ines/ieee-1588.html

01/03/2011 El Institute of Embedded Systems es un centro de investigaciónvinculado a la Zurich University of Applied Sciences y quecolabora técnicamente con el fabricante Hirschmann. Este sitioWeb contiene diferentes papers y tutoriales sobre los principios defuncionamiento de IEEE 1588 v1 y v2.

1 2 1 2

NTP The Network Time Protocol http://www.ntp.org/ 01/03/2011 Sitio Web oficial de NTP y SNTP. Básicamente ofrece links a losRFCs de las versiones vigentes de NTP y SNTP y otros linksrelacionados.

1 1 1 1

IETF Internet Standards http://www.ietf.org/ 09/08/2011 Sitio Web oficial de IETF. Contiene todos los RFCs queespecifican estándares de Internet.

1 1 1 1

IEEE IEEE 802 Standards http://standards.ieee.org/about/get/index.html 02/03/2011 Sitio Web oficial de IEEE. En este apartado, están disponiblesgratuitamente las normas vigentes del programa IEEE 802.

1 11 1 8

PI PROFINET Users' Web Site http://www.profibus.com/ 22/02/2011 Sitio Web oficial de PROFIBUS y PROFINET. Contiene múltiplesdocumentos técnicos

1 5 1 0

ODVA ODVA Users' Web Site http://www.odva.org/ 23/02/2011 Sitio Web oficial de CIP y EtherNet/IP, entre otros. Contienemúltiples documentos técnicos

1 4 1 0

ETG EtherCAT Users' Web Site http://www.ethercat.org/ 24/02/2011 Sitio Web oficial de EtherCAT. Contiene múltiples documentostécnicos.

1 4 1 1

EPSG Ethernet POWERLINK Users'Web Site

http://www.ethernet-powerlink.org/ 25/02/2011 Sitio Web oficial de Ethernet POWERLINK. Contiene múltiplesdocumentos técnicos.

1 3 1 0

MODBUS-IDA MODBUS Users' Web Site http://www.modbus-ida.org/ 28/02/2011 Sitio Web oficial de Modbus. Contiene especificaciones Modbusserie y Modbus sobre TCP/IP.

1 2 1 2

SERCOS International SERCOS III http://www.sercos.com/technology/sercos3.htm 02/03/2011 Sitio Web oficial de SERCOS. Contiene explicaciones técnicasbastante completas en la propia Web y también presentacionessobre SERCOS III.

1 1 0 0

Fieldbus Foundation High-Speed Ethernet http://www.fieldbus.org/ 02/03/2011 Sitio Web oficial de Fieldbus Foundation. Contiene explicacionestécnicas sobre HSE, entre otros protocolos.

1 1 0 0

TTA-Group TTA-Group's Web Site http://www.ttagroup.org/ 02/03/2011 Sitio Web oficial del Time-Triggered Architecture Group. Contieneinformación sobre los procolos Time-Triggered Protocol (TTP) yTime-Triggered Ethernet (TTE).

1 0 0 0

Wireshark Foundation Wireshark Network ProtocolAnalyzer

http://www.wireshark.org/ 25/02/2011 Sitio Web oficial de la herramienta freeware Wireshark. Estaherramienta permite analizar el tráfico en una red Ethernet yfacilita la interpretación de las cabeceras de prácticamente todoslos protocolos del stack TCP/IP existentes.

1 0 0 0

TOTAL: 32 61 23 29

ESTÁ

ND

AR

ES D

E PR

OTO

CO

LOS

Anexo III. Pág. 2 de 2 Rev. 1

ethernet industrial. protocolos e implementaciones de mercado

Documents