ethernet industrial. protocolos e implementaciones de mercado
DESCRIPTION
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.TRANSCRIPT
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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)
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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)
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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)
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
16 de 143 Rev. 1
("realtime" OR "real time" OR "real-time" OR "industrial")
AND
("ethernet" OR "IEEE 802.3")
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:
("realtime" OR "real time" OR "real-time" OR "industrial")
AND
("ethernet" OR "IEEE 802.3")
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")
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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-
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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].
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
aplicaciones industriales.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
• Modulación: Banda base.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
36 de 143 Rev. 1
• Longitud máxima del segmento (sin repetidores): 185 m.
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.
• Tasa de transferencia: 10 Mbps
• Modulación: Banda base.
• Longitud máxima del segmento (sin repetidores): 100 m.
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.
• Permite modo half duplex, full duplex o ambos.
• Conectores RJ-45.
• Tasa de transferencia: 100 Mbps
• Autonegociación (opcional): Permite adaptarse automáticamente a 10 Mbps para
proporcionar compatibilidad con 10BASE-T.
• Modulación: Banda base.
• Longitud máxima del segmento (sin repetidores): 100 m.
1000BASE-T (Gigabit Ethernet over Twisted Pair)
• Topología punto a punto o bien en estrella.
• 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).
• Conectores RJ-45.
• Tasa de transferencia: 1000 Mbps
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
• Longitud máxima del segmento (sin repetidores): 100 m.
Implementaciones para fibra óptica 10BASE-F, 100BASE-FX, 1000BASE-X
• Topología punto a punto o bien en estrella.
• Cableado: cada enlace físico requiere dos fibras: una para transmisión y otra
para recepción.
• Permite modo half duplex, full duplex o ambos.
• Tasa de transferencia: 10, 100 y 1000 Mbps
• Modulación: Banda base.
• 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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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,...).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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”.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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]
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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).
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
aplicaciones industriales.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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:
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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/.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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/.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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.
Informe sobre el estado de la técnica. Ethernet Industrial. Protocolos e implementaciones de mercado.
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
(Véanse páginas anexas).
6.3 Anexo III. Sitios Web analizados
(Véanse páginas anexas).
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
RedUned en CentroAsociado
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
RedUned en CentroAsociado
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)
RedUned en CentroAsociado
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
RedUned en CentroAsociado
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
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?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
Informe sobre el estado de la técnica.Ethernet Industrial. Protocolos e implementaciones de mercado
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
Informe sobre el estado de la técnica.Ethernet Industrial. Protocolos e implementaciones de mercado
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
Informe sobre el estado de la técnica.Ethernet Industrial. Protocolos e implementaciones de mercado
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