acoplador de bus.

Por otro lado, el termino Gateway algunas veces define a un accesorio que conecta a un PLC o PC a un
bus de campo.

6.1.2 Estructuras de interconexión

La primera clasificación es realizada en cuanto al orden de nivel de las redes interconectadas. Una estructura par-a-par
ocurre cuando dos redes interconectadas intercambian comandos y respuestas a través de un acoplador de bus en ambas
direcciones de manera que ninguna de las redes puede ser distinguida en un nivel jerárquico mayor, como se observa en
la Figura núm. 30.

M2 M1
Bus de campo 1 Bus de campo 2
1 1
1 I
S2 S1

Figura núm. 30.- Estructura Peer-to-peer.

En el caso de maestros/esclavos, los sistemas interconectados son dos maestros o configuración de maestro simple (dos
esclavos interconectados pueden realizar aplicaciones muy especificas). Si dos redes interconectadas se presentan en
orden jerárquico, ver Figura núm. 31, la configuración maestro/esclavo aparece en forma usual al menos en la red de
menor jerarquía.

Bus de campo 1

Bus de campo 2

Figura núm. 31.- Configuración de interconexión jerárquica.

La segunda clasificación esta basada en los perfiles de los protocolos que son utilizados por las recles a interconectar. En
este caso, la clasificación estándar utiliza la terminología general mencionada antes: puente, ruteador y gateway.
También, las redes base (backbone) y "tunneling" pueden ser distinguidas de una manera estándar. Sin embargo la
arquitectura mas común para realizar la interconexión es la de un gateway debido a que usualmente existen diferentes
capas de aplicación de los buses interconectados. En este caso, el también llamado gateway completo tiene que traducir
los mensajes de protocolo apropiados en lo que respecto al perfil completo de los protocolos de las redes interconectadas.
Por otro lado, un gateway medio permanece en un bus común con las capas inferiores comunes y traduce solamente entre
diferentes protocolos de aplicación

La otra clasificación esta relacionada con la arquitectura lógica interna de un acoplador, como lo son la estrategia de
ruteo (fuente o adaptable) y los algoritmos de ruteo y retransmisión (distancia-vector, estado del enlace, propósito
especial) embebidas en la tareas de comunicación, drivers de las Entradas / Salidas, sincronización de tareas y servicios
de comunicación de un kernel de sistema operativo de tiempo real. Similarmente, el numero de procesadores y el tipo de
su interconexión (serial directo, o paralelo, indirecto por colas FIFO por RAM de puerto dual) describe las propiedades
de la arquitectura física interna principal del acoplador.

Todo esto puede ser detallado siempre como es de esperarse, con una implementación concreta.

6.1.3 Acoplamiento Bus de campo-Intranet

Para unir un bus de campo o un sistema interconectado de buses a ethernet es necesario desarrollar un gateway completo,
según la definición mencionada en las páginas anteriores. La función de este es agregar en por un "lado" los protocolos
referentes a 1 bus o buses de campo y por el otro el perfil de protocolo de Internet seleccionado, y tiene que traducir
mensajes entre los mensajes de los protocolos de las capas de aplicación en ambos dominios.

Mientras que el suite del protocolo ya esta usualmente determinado por el lado del Gateway del bus de campo, la
tecnología de una intranet ofrece diversas soluciones basadas en las tecnologías WWW.

Evidentemente, las interconexiones de sensores con intranets / Internet utilizando buses de campo puede resultar en una
cantidad enorme de soluciones propietario. Esas interconexiones actualmente no pueden ser estandarizadas. Por lo tanto,
esta metodología parece funcional solo para aquellas aplicaciones especiales o para cumplir ciertos requerimientos de
implementación.

116
Vi:

6.1.4 Integración basada en Gateway

Puesto que no es deseable el desarrollar nuevos protocolos de conversión en los Gateways, las aplicaciones específicas
propias de las RSI's requieren este tipo de solución en la actualidad. De acuerdo a [Zuñiga], gateways múltiples o uno
solo son utilizados en redes homogéneas, donde todos los nodos tienen la misma capacidad en términos de recursos de
energía, procesamiento, y comunicación. Por otro lado, además de gateways, puede existir una red que utilice el
protocolo TCP / IP convirtiendo a la red homogénea en una red heterogénea, donde algunos nodos presenten mas
capacidad que la mayoría de los nodos (computadoras portátiles o sensores nodo que realizan mas funciones).

Puesto que el interés esta basado en redes de sensores inalámbricos, donde cada sensor nodo posea características
similares en recursos y funcionamiento y solo exista una estación base que permita el acceso a otros sistemas, a
continuación es presentado el funcionamiento de una integración basada en Gateway para una red homogénea.

6.1.5 Red homogénea de sensores inalámbricos

La solución básica para la integración en el caso de una red homogénea de sensores inalámbricos es utilizar un gateway
de nivel de aplicación (en referencia al modelo OSI) para comunicar la red de sensores con el Internet.

La solución ideal es aquel gateway que permite interactuar con la RSI en forma de terminal, la cual por medio de
instrucciones y mensajes, los usuarios (ya sean humanos o sistemas) utilicen la información para tomar decisiones. Una
buena aproximación de este tipo es la utilización de consultas y ejecución de tareas utilizando lenguaje SQL, el cual
utiliza procesamiento en red y acceso basado en datos, no en nodos. Obviamente esto es aplicable para recles de sensores
muy grandes, donde la resolución de sensado es muy grande (gran numero de sensores por metro cuadrado). Un punto
negativo para este esquema es que los sensores nodo mas próximos a la estación base, estarán mas propensos a agotar su
energía (si no son tienen generadores de energía) debido al alto trafico de datos, como lo menciona [Zuñiga].

También [Zuñiga], menciona que en las RSI homogéneas, donde todos los nodos tienen la misma capacidad, a excepción
del gateway, la flexibilidad para comunicación con otras arquitecturas es limitada. Pero la aplicación de las redes de
sensores por lo general, en sus aplicaciones industriales, estará siempre enfocada hacia la comunicación con un solo
protocolo o bus de campo. Para eliminar algún error por falla en el único gateway, seria posible poner disponibles otros
gateway con asignaciones de responsabilidades balanceadas y en topología mesh.

M; 117
6.2 Interconexión de una red de sensores inalámbricos con un PLC

6.2.1 Red de sensores inalámbricos interconectados con un PLC por medio de Ethernet Industrial

La utilización de Ethernet en conjunto con sensores inalámbricos brinda la ventaja de que esta solución proporciona una
gran cantidad de herramientas de software que permite una gama amplia de soluciones en plataformas de programación
abiertas. Este tipo de acoplamiento interconecta el backbone de Ethernet a un bus de campo de bajo nivel como lo es una
red de sensores. Este acoplador esta basado en el concepto de "tunneling": los mensajes del bus de campo (en este caso,
red de sensores inalámbricos) son transportados desde el sensor hasta la estación base o procesador de comunicaciones y
este a su vez, lo envía a un cliente que usualmente reside en Ethernet, por medio de paquetes TCP / IP.

Las aplicaciones que pueden utilizar este tipo de interconexión están ubicadas en aquellas que no son en tiempo real y
aquellas que si exigen alguna certidumbre de entrega de información pero sus retardos (debido a la naturaleza no
determinística de Ethernet) no afectarían el rendimiento del sistema o aplicación final, es decir, los sistemas no críticos
de tiempo real. También ofrece la ventaja de que la información puede ser utilizada por controladores lógicos
programables con capacidad de ethernet, ya sea para realizar la actuación en la etapa de potencia o para tomar
decisiones basadas en la información proporcionada.

A continuación son enumeradas cada una de ellas. Las aplicaciones de tiempo no real son:

• Control remoto
• Monitoreo de estado de maquinas
• Supervisión de procesos
• Configuración de sistema e intercambio de información
• Conectividad con Internet

Y para las aplicaciones de tiempo real no criticas, son:

• Registro de eventos
• Mediciones
• Control de lazos con constantes de tiempo grandes

118
6.2.2 Red de sensores inalámbricos interconectados con un PLC por medio de un Bus de Campo

La utilización de buses de campo en conjunto con sensores inalámbricos permite asegurar un comportamiento
determinístico de nuestra aplicación final. Para realizar esta interconexión, una configuración maestro-esclavo aparece en
forma usual, donde la red esclavo será la red de sensores inalámbricos y la red maestro será el bus de campo.

Las aplicaciones finales de este tipo de interconexión pudieran ser los sistemas de tiempo real consideraros críticos, ya
que el grado de determinismo debe de ser muy alto y la probabilidad de entrega de información desde la RSI hasta el bus
de campo en un lapso de tiempo determinado por diseño debe de ser del 100 por ciento.

6.2.3 Implementación del Hardware y Software para lograr una comunicación exitosa e interoperable

En un desarrollo llamado Web Automation, realizado por [Buhler], es mostrada la utilización de una red CAN manejada
en forma remota a través de un explorador WEB utilizando JAVA. En este desarrollo, las soluciones de software
ofrecidas por JAVA para interconectar Internet con una red CAN y ofrecer el control remoto por medio de un explorador
Web estándar tuvieron mucho éxito y fue una solución que ofreció una flexibilidad de diseño importante. La
programación JAVA es embebida en el hardware de una tarjeta de comunicación CAN y extrae la información necesaria
para ser utilizada en el middleware y otros componentes de software estándar. Empleando esta ingeniería de software fue
posible, por medio de una base flexible y escalable, la integración de dispositivos reales (robots, sensores) a un ambiente
de escritorio y permitiendo la manipulación de ellos. El protocolo CANOpen (protocolo automotriz adoptado para el
control de procesos industriales) sirvió como la plataforma de hardware permitiendo la comunicación con dispositivos de
campo. Para lograrlo se aplicaron técnicas estándar de para la implementación de software como lo son el análisis y
diseño orientado a objetos usando el diseño de patrones gráficos y una estructura Cliente - Servidor similar a la utilizada
por los sistemas de información modernos.

Tomando como base, la aplicación recién mencionada, se plantea que para lograr una comunicación exitosa e
interoperable entre un PLC y una RSI, se deben de contar con los siguientes conocimientos y herramientas:

o Diseño orientado a objetos: la complejidad de bajo nivel en la aplicación puede permanecer oculta por medio de
la utilización de interfases de clase y pueden ser utilizadas selectivamente para propósitos específicos.

o Arquitectura Cliente - Servidor: permite la ejecución de clientes en forma remota o local por medio de
exploradores de datos. Un servidor: que controla el acceso a los clientes y filtra e interpreta los comandos de
cada uno de ellos. Por el lado del cliente, su funcionamiento es muy similar a un sistema de información común

119
VI,

o Base de Datos: La base de datos que usualmente usan los sistemas de información y que comúnmente es
proporcionada por un software administrativo o de otro tipo similar, debe ser reemplazado por la información
ordenada sistemáticamente que proporciona el la RSI con sus dispositivos.

o Lenguaje de programación orientado a objetos: que permitan realizar clientes con la especificación deseada sin
necesidad de contar con licencias que a veces son demasiado costosas. Así mismo estos lenguajes permiten
tener acceso a servidores de bases de datos y manipular cualquier base de datos para extraer información de la
manera más conveniente.

6.2.4 Modelos de comunicación RSI - PLC

Basados en la implementación exitosa recién mencionada, son planteados varios modelos de comunicación. La
nomenclatura usada para nombrar estos modelos es "Configuración (NCTR - No tiempo real o no critica en tiempo real
y CTR - Critica en tiempo real) (Plataforma de software RSI) - (Plataforma de software PLC) (letra consecutiva).

6.2.4.1 Configuración NCTR Propietaria - Estándar A

Esta estructura permite una mayor interoperabilidad y escalabilidad, dada la naturaleza de las unidades y módulos de
software estándar, así como el gasto en hardware es mínimo. Para implementar esta estructura es necesario que la
arquitectura de los sensores nodo y del gateway utilice un sistema operativo de plataforma abierta que utilice lenguajes
estándares de programación en la capa de aplicación para utilizar en forma transparente una aplicación Client. La
principal desventaja, para aquellos proyectos que necesiten una rápida implementación, es que la programación de la red
de sensores inalámbricos puede llevar un proceso largo de depuración y rediseño, entonces la planeación de este punto es
clave para el éxito y la operabilidad de la aplicación final. Esta configuración puede ser implementada en la actualidad.
En la Figura núm. 32 es mostrado el modelo de comunicación.

A continuación se realiza una descripción breve de la función de cada modulo en modelo de comunicación utilizado.

• PLC. Es un controlador lógico programable modularizado, por lo tanto su capacidad de comunicación esta en
función de los procesadores de comunicación que tenga instalados. En forma general, los módulos de
procesadores de comunicación comunes en la actualidad son de para Ethernet Industrial, Buses de dispositivos,
Buses de Actuadores / Sensores y Buses de Control, todos estos considerados buses de campo.

• LAN. Es la capa física del Ethernet industrial.

120
 Controlador Lógico Programable con capacidad en Tecnología de la
PLC información

LAN TCP/IP Conexión por sockets

B i. .""-B'k^jj;"

Servidor OPC el cual es un programa responsable de la recolección

OPC Server de datos en forma eficiente desde un dispositivo hasta una base de
datos con formato estándar
1 1
COM ->DLL Librería dinámica que provee el servidor OPC

PC 1 •
Cliente Interfase hacia OPC, su función es comunicarse con la librería
OPC dinámica de enlace (DLL) del OPC
1 • .,:,„ _| ::.:,.
Aplicación Aplicación final que administra realiza los comandos y mensajes
RSI hacia la red de sensores inalámbricos
| |
LAN TCP/IP Conexión por sockets

I Estación base que realiza la función de gateway entre las capas

Gateway inferiores de las dos redes que son una LAN y una RSI

I
Sensores y
Sensores y actuadores inalámbricos esparcidos en campo
actuadores

Figura núm. 32.- Modelo de comunicación entre una red de sensores y actuadores inalámbricos con un PLC
industrial utilizando Ethernet Industrial.

• OPC - Enlace y compartimiento de datos y objetos para el control de procesos. OPC (por sus siglas en ingles
OLE for Process Control) Es una tecnología de Microsoft la cual permite enlazar elementos desde diferentes
aplicaciones o dispositivos para el control de procesos.

OPC ofrece una conectividad abierta por medio de estándares abiertos, la fundación OPC adapta y crea
especificaciones que cumplen con las necesidades especificas de la industria.

El primer estándar fue llamado la especificación OPC, ahora es llamado Especificación OPC para acceso a
datos, resultado de la colaboración de un conjunto de proveedores líderes en automatización trabajando en

121
M.i

cooperación con Microsoft. La especificación define un conjunto estándar de objetos, interfaces y métodos para
ser utilizados en aplicaciones de control de procesos y automatización de la manufactura facilitando la
interoperabilidad. Las tecnologías de modelo de objetos componentes y modelo de objetos distribuidos de
Microsoft proporcionan un marco para que productos de software sean desarrollados. En la actualidad existen
cientos de Servidores y Clientes OPC de acceso a datos en el mercado. [OPC], El ciclo de diseño del proyecto
es mas corto usando componentes estándar de software, así como también su costo es menor. Debido a que los
estándares OPC son basados en estándares industriales, la confiabilidad técnica es asegurada.

Función del Servidor OPC. Su función principal es comunicarse por medio de un bus de campo o LAN con los
dispositivos físicos (controladores) y obtener / enviar toda la información concerniente al proceso que controla
el dispositivo. Además de comunicarse, toda la información es configurada a un formato estándar basado en
objetos, el cual puede ser accesado para utilizarlo y ejercer acciones sobre dispositivos físicos o requerir
información de ellos. Los servidores OPC son proporcionados por varias marcas de automatización, y cada una
de ellas cubre la confiabilidad y comunicación con los dispositivos. [OPC]

• Librería de enlace dinámico DLL. Es una librería de funciones ejecutables o datos que pueden ser usados por
una aplicación de Windows. Típicamente, un DLL (por sus siglas en ingles, Dynamic Link Library)
proporciona una o mas funciones particulares y un programa accede a las funciones creando un enlace dinámico
o estático hacia el DLL. Un enlace estático permanece constante durante la ejecución del programa mientras
que el enlace dinámico es creado por el programa según sea necesario. Los DLL's usualmente terminan con las
extensiones .dll, .exe, .drv o .fon. Un DLL puede ser utilizado por varias aplicaciones a la vez al mismo tiempo.
Algunos DLL's son proporcionados con el sistema operativo de Windows y están disponibles para cualquier
aplicación. En otros casos, los DLL's son escritos para escribir aplicaciones más particulares y son cargados con
la aplicación. El servidor OPC que es desarrollado por un fabricante utiliza un archivo de esta naturaleza como
base de su funcionamiento, entonces, el contenido de este archivo en ele esquema planteado para lograr la
comunicación es vital, ya que a través será la interacción del PLC con la RSI.

• Cliente OPC. El cliente OPC se comunica con el servidor OPC por medio de la tecnología COM. Si el lenguaje
de programación no fuera de Microsoft, entonces debería de existir una capa que realizaría el enlace entre la
tecnología del lenguaje y la tecnología COM. Un ejemplo seria la aplicación Java Com que crea un enlace
dinámico con el DLL del OPC Server, logrando extraer e inyectar la información necesaria para lograr la
comunicación.

• Aplicación RSI. Es la aplicación que esta conectada directamente al gateway de la red de sensores. La conexión
con el gateway es a través de sockets TCP/IP, y sus funciones son inyectar y recibir información hacia / desde la
red de sensores. La programación es en un lenguaje abierto.

M; 122
 • Gateway y redes de sensores /actuadores inalámbricos. El gateway es el punto de acceso de la red de sensores
inalámbricos entre el estándar de RF y Ethernet industrial. Los sensores y actuadores inalámbricos se
encuentran esparcidos en campo en diferentes locaciones, por ejemplo, instalados en una celda de manufactura.

En la Figura núm. 33 es mostrada la arquitectura de la comunicación PLC-RSI. En la figura se muestra una computadora,
que es la unidad procesadora para el OPC Server y el Client OPC, es decir, es el hardware de orquestación entre las dos
aplicaciones. Tenemos también el Gateway (G) de la RSI, así como dispositivos inalámbricos de función completa
(FFD) funcionando como ruteadores y terminales (sensores / actuadores) tamben llamados RFD's. En este esquema se
plantea una topología híbrida mesh-estrella y cumple con el estándar ZigBee / IEEE 802.15.4. Se asume que tocios los
sensores están embebidos en un proceso de manufactura A, que en este caso es una celda de soldado de dos robots. El
bus al que se encuentran conectados la computadora, el Gateway y el PLC es ethernet industrial. El PLC, como se
planteo, debe ser modularizado y tener módulos procesadores de comunicaciones, en este caso, como ya se menciono,
utiliza un módulo procesador de comunicaciones en ethernet industrial y para interactuar y controlar el medio físico
(proceso de manufactura A) utiliza un módulo procesador de comunicaciones en un bus de campo.

PLC Industrial
Computadora Bus de
Campo

Ethernet Industrial

Proceso de manufactura A

Red ZigBee / IEEE 802.15.4

Figura núm. 33.- Arquitectura de la comunicación entre una red de sensores inalámbricos y un PLC con una
configuración NTR propietaria - estándar A.

123
 6.2.4.2 Configuración NCTR Propietaria - Estándar B

Una variación de la configuración anterior sería en el caso de que un proveedor de hardware proporcionará su propio
software, es decir, una aplicación propietaria. En la actualidad existen proveedores que ya ofrecen esta opción
(plataforma), y que permiten la configuración total de la red de sensores / actuadores inalámbricos por medio de una
inferíase amigable y con un conjunto de comandos muy completos (consulta y ejecución). En la Figura núm. 34 se
muestra el modelo de comunicación.

Controlador Lógico Programable con capacidad en Tecnología de la

PLC información

LAN TCP/IP Conexión por sockets

' 1 1
Servidor OPC el cual es un programa responsable de la recolección
OPC Server de datos en forma eficiente desde un dispositivo hasta una base de
datos con fórmalo estándar
1 1

pe
COM ->DLL
1 1 i Librería dinámica que provee el servidor OPC

Cliente Inferíase hacia OPC, su función es comunicarse con la librería

OPC dinámica de enlace (DLL) del OPC
1 1 Aplicación final que administra realiza los comandos y mensajes
Software hacia la red de sensores inalámbricos y que por lo general permite
propietario configurar la funcionalidad de la red (interfases) pero posee una
1 1 estructura de datos propietaria

LAN TCP/IP Conexión por sockets

Estación base que realiza la función de gateway entre las capas

Gateway inferiores de las dos redes que son una LAN y una RSI

Sensores y
Sensores y actuadores inalámbricos esparcidos en campo
actuadores

Figura núm. 34.- Modelo de comunicación con configuración propietario - estándar B.

El único aspecto negativo es que la especificación de las funciones de cada sensor / actuador nodo se vería delimitada
por el conjunto de comandos y opciones de configuración que proporciona el fabricante del hardware, perdiendo así
capacidad de diseño.

124
\Í!

Por otro lado, su principal ventaja es que al utilizar la interfase de programación amigable por parte del fabricante sobre
la red de sensores inalámbricos el tiempo de arranque y configuración de la aplicación disminuiría en gran manera y el
único aspecto de programación mas detallada sería el Cliente OPC para interactuar con el DLL del servidor OPC. Otra
ventaja muy notoria es que probablemente ofrezca un comportamiento global benevolente en la respuesta dinámica de la
RSI.

En la actualidad, este modelo de comunicación puede ser implementado, con lo que existe en el mercado.

6.2.4.3 Configuración Estándar - Estándar

Este modelo de comunicación engloba las tendencias actuales de la estandarización de lo sensores inteligentes. Si los
fabricantes desarrollan plataformas e interfases de software con estructuras de datos estándar entonces podríamos tener
un modelo de comunicación como lo muestra la Figura núm. 35.

La disponibilidad de los módulos de este modelo de comunicación es en la actualidad la meta de todos los esfuerzos
hacia la uniformidad en el mercado de las redes de sensores inalámbricos.

La ventaja principal que presenta este modelo de comunicación es que la plataforma de software e interfase de
programación que proporcionaran los fabricantes será estándar, y por lo tanto, el tiempo de diseño gastado en diseñar el
enlace entre OPC y la red de sensores inalámbricos es disminuido a una expresión no significativa. Es ideal que exista
una opción de este tipo y que permita a su vez realizar una configuración especifica de los sensores nodo sin perder la
estandarización.

Este tipo de implementación en la actualidad no puede ser implementada, debido a la variedad de soluciones propietario
así como también otras opciones demasiado abiertas existentes en el mercado.

Estas son las soluciones que se plantean para interconectar una red de sensores inalámbricos con un PLC industrial
utilizando Ethernet Industrial. Ahora vamos a observar las opciones que se podrían implementar utilizando un bus de
campo.

125
\]

Controlador Lógico Prograrnable con capacidad en Tecnología de la

PLC información

LAN TCP/IP Conexión por sockets

Servidor OPC el cual es un programa responsable de la recolección

OPC Server de datos en forma eficiente desde un dispositivo hasta una base de
datos con formato estándar

Aplicación final que administra realiza los comandos y mensajes

Software hacia la red de sensores inalámbricos y que por lo general utiliza un
estándar marco estándar para la estructura de los datos, sin importar el
proveedor del hardware, es decir, se comunica directamente por
¡nterfases con el OPC servidor.

LAN TCP/IP Conexión por sockets

Estación base que realiza la función de gateway entre las capas

Gateway inferiores de las dos redes que son una LAN y una RSI

Sensores y
actuadores Sensores y actuadores inalámbricos esparcidos en campo

Figura núm. 35.- Modelo de comunicación estándar - estándar

196
6.2.4.4 Configuraciones CTR Propietaria - Estándar A y B y CTR Estándar - Estándar

La única variante a diferencia a los esquemas planteados en las páginas anteriores es que el OPC Server estará en
comunicación con el PLC por medio de un bus de campo. En la Figura núm. 36 se muestra el modelo de comunicación
planteado.

Controlador Lógico Programable con capacidad en Tecnología de la

PLC información
I
Bus de campo Protocolo de bus de campo

lii
Servidor OPC el cual es un programa responsable de la recolección
OPC Server de datos en forma eficiente desde un dispositivo hasta una base de
datos con formato estándar
J.
COM ->DLL Librería dinámica que provee el servidor OPC

Cliente Interfase hacia OPC, su función es comunicarse con la librería

OPC dinámica de enlace (DLL) del OPC

Aplicación Aplicación final que administra realiza los comandos y mensajes

RSI hacia la red de sensores inalámbricos

LAN TCP/IP Conexión por sockets

I I
Estación base que realiza la función de gateway entre las capas
Gateway inferiores de las dos redes que son una LAN y una RSI

Sensores y Sensores y actuadores inalámbricos esparcidos en campo

actuadores

Figura núm. 36.- Modelo de comunicación con una configuración de CTR propietario - estándar A

En estos esquemas las ventajas y desventajas que presentan son las que presenta las configuraciones NRT propietario -
estándar A y B así como la NRT Estándar - Estándar, además de que el tiempo de respuesta del sistema se espera sea
mejorado por la característica determinística del bus de campo escogido. En la Figura núm. 37 es mostrada la
arquitectura de la comunicación RSI - PLC utilizando un bus de campo para comunicarse con el servidor OPC. El bus al
que se encuentran conectados la computadora y el Gateway es ethernet industrial. La computadora debe de tener una
tarjeta especial que cumple con el protocolo del bus de campo especificado y que le permite ser un nodo mas, dentro de
esa red, así puede tener comunicación con el PLC y con otros dispositivos maestros o esclavos de esa red.

VI; • 127
 PLC Industrial ¿r Bus de Campo

u Computadora

Ethernet Industrial

Proceso de manufactura A

Red ZlgBee / IEEE 802.15,4

Figura núm. 37.- Arquitectura de comunicación de un modelo CRT Propietario - Estándar A.

6.2.4.5 Configuración CTR Propietaria - Estándar C

Existe una configuración más que puede utilizarse para implementar una comunicación efectiva entre un PLC y una red
de sensores inalámbricos. El modelo de comunicación para la configuración CTR Propietaria - Estándar C es mostrado
en la Figura núm. 38.

Este modelo propone realizar un acoplamiento físico y lógico entre el gateway de la red de sensores y un circuito
integrado de aplicación específica (ASIC, por sus siglas en ingles Application-Specific Integrated Circuit) en una
estructura peer-to-peer para convertir al gateway en un esclavo mas del bus de campo especificado. Por lo tanto toda la
información que genera la red de sensores es vista como la información de un esclavo de gran capacidad

Explicando en forma más amplia, un ASIC es un microchip diseñado para una aplicación en especial. Enfocándonos en
el tema de interés, un ASIC es un circuito integrado que posee de forma embebida desde su fabricación el protocolo de
un bus de campo y que es utilizado para "crear" esclavos o maestros de ese bus de campo y generalmente esta orientado
a fabricantes que quieren producir controladores o dispositivos capaces de comunicarse en ese bus y cumplir con el
estándar especificado.

128
 Controlador Lógico Prograrnable con
capacidad en Tecnología de la
información

Protocolo de bus de campo

Circuito integrado que posee en forma

embebida la comunicación con el protocolo
del bus de campo

Estación base que realiza la función de

gateway entre las capas inferiores de las
dos redes que son una LAN y una RSI

Sensores y actuadores inalámbricos

esparcidos en campo

Figura núm. 38.- Modelo de comunicación para la configuración CTR Propietaria - Estándar C

Desde el punto de vista de esclavo, esta configuración estaría orientada a redes de sensores / actuadores inalámbricos
pequeñas, puesto que, dependiendo del bus de campo seleccionado, la información generada en este "esclavo" no debe
sobrepasar la capacidad del bus de campo. Entonces podríamos hablar de una aplicación sencilla con sensores
inalámbricos binarios o analógicos de poca resolución y una frecuencia de muestreo que no produzca información que
"inunde" el ancho de banda del bus. En la Tabla núm. 10 observamos los ASIC más populares para cada una de los buses
de campo más utilizados.

Tabla núm. 10.- ASIC comúnmente utilizados en los buses de campo más populares.
Componentes de Hardware especifico de Red
Red ASIC(s) Comunes
Modbus RTU/ASCII Ninguno
Redes basadas en CAN (por elemplo, DeviceNet, SJA1000, 82C251,yotras
CANOpen, J1939)
Profibus DP & PA Múltiples ASICs, de Siemens y Profichip
Ethernet, Web server, Industrial Ethernet, Foundation AM79C960 es el mas popular
Fieldbus, HSE
LonWorks Toshiba Neuron Chip
HART CybermeticPSl
Interbus Phoenix Contact IPMS (master), SmPI II (slave)
Foundation Fieldbus H1 SMAR FB3050
Arcnet Una variedad extensa que proporciona la Cia. Standard Micro
Systems Corp.
Sercos ST Microelectronics SERCON410B
ControlNet Rockwell CNA 10 ControlNet ASIC

Fuente: Sensors Magazine, Julio 2001

129
Como puede notarse, la solución propuesta tiene las características de una solución propietaria y de aplicaciones muy
específicas, por lo tanto conlleva las desventajas de depuración y diseño que tanto tiempo consumen. Por lo tanto si una
opción como esta es considerada, la etapa de depuración y diseño del acoplamiento lógico y físico del gateway y ASIC
debe estar en las manos correctas durante un tiempo bien definido para lograr el éxito de la aplicación.

En la Figura núm. 39 es mostrada la arquitectura de la comunicación RSI - PLC utilizando un acoplamiento de RSI-
ASIC de bus de campo en el que la comunicación es directamente con el módulo procesador de comunicaciones del
PLC. El bus al que se encuentran conectados la computadora y el PLC es ethernet industrial. El acoplamiento realizado
en el gateway se comportará como un nodo más del bus de campo.

Esta configuración puede implementarse en la actualidad, con la tecnología disponible.

Computadora PLC Industrial

Bus de
Campo

Proceso de manufactura A Proceso de manufactura A

RedZ¡gBee/IEEE802.15.

Figura núm. 39.- Arquitectura de comunicación de un modelo CRT Propietario - Estándar C.

130
6.2.4.6 ¿Como decidir entre una configuración del acoplamiento Maestro o esclavo?

En el contexto de un sistema de control, un maestro, o servidor lee entradas, escribe en las salidas, pide información de
otros dispositivos y realiza control secuencial. Por otro lado, un esclavo, o cliente, proporciona información al sistema y
usualmente solo envía información cuando le es requerida.

Enfocándonos al interés, si el acoplamiento Gateway-ASIC requiere del manejo de mucha información (valores
analógicos y muchos sensores inalámbricos esparcidos) y además juega un rol importante dentro del sistema al que da
servicio, es preferible darle un perfil de maestro en vez de esclavo y disminuir costos por el lado de alguna unidad
procesadora extra.

De acuerdo a [Sink], un maestro debe tener una base de datos de parámetros de configuración (los cuales cada uno de
ellos debe de ajustar a la configuración de los esclavos) y administrar el tráfico en la red sin problemas de
interoperabilidad. Esto significa que un maestro es 10 veces, al menos, más complejo que un esclavo. Su firmware
(sistema operativo) debe soportar todas las tareas de comunicación básica, y debe de ofrecer también herramientas de
software que permitan realizar la configuración de la manera más directa posible. Estas herramientas de software elevan
el costo de desarrollo del maestro por encima del esclavo. El software de configuración también realiza un rastreo de los
datos de una red hacia el software de aplicación.

6.2.4.7 Obstáculos en el desarrollo de un acoplamiento funcional

Según [Sink], la mayoría de los protocolos son sofisticados y pueden ser implementados en varios grados de
complejidad. El firmare para el hardware puede ser implementado en dos o tres semanas; un maestro completamente
funcional puede tomar de 2 a 3 años de programación. De manera que es importante definir el alcance general del
proyecto.

El tener la disponibilidad de estándares abiertos, no necesariamente quiere decir que no sean complejos. Por lo que al
momento de realizar una decisión en la elección de la tecnología, el grado de complejidad debe de estar muy claro para
evitar atrasos en el proyecto global. El diseñar el acoplamiento con capacidad de escalabilidad y herramientas que
permitan implementarlo en forma transparente es ideal para no tener problemas de rediseño en un futuro.

Ahora, el siguiente paso es obtener un panorama general de los pasos que hay que seguir para obtener una aplicación
funcional de una red de sensores / actuadores inalámbricos en comunicación con un PLC.

131
.Yh:

Capítulo 7 -Metodología para la implementación de la comunicación

entre una RSI y un CPU industrial

En este capítulo se planteara una metodología que permita implementar con éxito la comunicación de una red de
sensores inalámbricos (RSI) y un CPU industrial. En forma general, los pasos a seguir son: definición de la función final
de la RSI para definir la configuración del modelo de comunicación, una vez definida la función final de la RSI, entonces
se definen las características funcionales de esta red, después se definen las características del interlocutor de la red de
sensores inalámbricos. Entonces se realiza un esquema de comunicación desde el campo de RSI hasta el campo de
actuación del CPU industrial (PLC) utilizando el modelo de referencia OSI. Una vez que se tiene claro la capacidad del
sistema a implementar, entonces se realiza una evaluación del proveedor de la RSI, que se ajuste de mejor manera a la
función final. Ya conociendo el hardware y software a utilizar, se realiza el modelo de comunicación específico para el
hardware y software, así como también se plantean las rutas críticas en cada uno de esos aspectos y la requisición de
recursos humanos para lograrlo. Por ultimo se realiza la implementación del sistema de acuerdo a las rutas criticas y la
documentación necesaria para una operación confiable. Después de la implementación, solo queda el funcionamiento
continuo, es decir, el mantenimiento, mientras menos mantenimiento sea necesario, entonces podemos decir que es un
diseño exitoso.

7.1 Metodología

Metodología es un cuerpo de prácticas, procedimientos, y reglas usadas por aquellos que trabajan dentro de una
disciplina o empiezan una investigación. A menudo, una metodología es implementada como un conjunto de pasos o
bien definidos o fases, cada uno de los cuales termina con criterios de éxito transparentes y mesurables. El propósito
clave de una metodología es asegurar que nada sea dejado de lado en el proceso de resolver un problema complejo
(como lo es un sistema de información).

7.2 El método cascada

La base de la mayoría de las metodologías de diseño y análisis es el Desarrollo del ciclo de vida del sistema ó SLDC (por
sus siglas ingles System Development Life Cycle) como se muestra en la Figura núm. 40. Es algunas veces llamado el
método cascada debido a que el modelo visualmente sugiere un trabajo en cascada paso a paso como en series de caída
de agua. (Debe de existir retroalimentación entre cada fase)

132
El primer paso es la definición del problema. La idea es identificar el problema, determinar su causa, y preparar una
estrategia para resolverlo. Una vez que se ha definido el problema, el análisis comienza. El objetivo del análisis es
determinar exactamente que debe de ser realizado para resolver el problema. Típicamente, los elementos lógicos del
sistema (sus límites, procesos y datos) son definidos durante el análisis.

El objetivo de diseño es determinar como el problema debe de ser resuelto, durante el diseño el analista se enfoca en
enlazar la estructura lógica planteada con la estructura física factible. Los procedimientos son convertidos a
procedimientos manuales o programas de computadora. Los elementos de dato son agrupados para formar estructuras
físicas de datos, pantallas, reportes, archivos y bases de datos. Los componentes de hardware que soportan los programas
y los datos son definidos.

El sistema es creado durante el desarrollo. (Debido a que el proceso entero es llamado el ciclo de vida del desarrollo de
un sistema, algunos expertos prefieren usar otras etiquetas para esta etapa, tales como creación del sistema, por ejemplo)

Los programas son escritos, codificados, documentados y probados. El hardware nuevo es seleccionado y ordenado. Los
procedimientos son escritos y probados. La documentación de usuario final es preparada. Las bases de datos son
inicializadas. Usuarios entrenados. Una vez que el sistema es desarrollado, es probado para asegurar que realiza lo
especificado en su diseño original. Después de que el sistema pasa su prueba final y algunos problemas son resueltos, el
sistema es implementado y liberado para proporcionar el servicio al usuario. Después de que el sistema es liberado, el
mantenimiento comienza. El objetivo del mantenimiento es mantener en funcionamiento el sistema en un nivel
aceptable.

Desarrollo
ItV j

Prueba

Implementación

Mantenimiento

Figura núm. 40.- El método cascada

133
7.3 Método cascada aplicado a la implementación de la comunicación entre una
red de sensores inalámbricos y un PLC industrial

Para desarrollar un sistema de información por mas sencillo que pudiera ser, es necesaria la ejecución metódica de pasos
ajustados al entorno de desarrollo. En base a todo lo que se ha descrito a lo largo de los capítulos anteriores, se propone
una metodología general para la implementación de la comunicación de una RSI con las características de la arquitectura
general del sistema de la Figura núm. 41.

PLC Industrial
Pre-procesamlento de
Información Bus de
Campo B

Proceso Industrial A

Red ZigBee / IEEE 802.15.4

Figura núm. 41.- Arquitectura general del sistema.

134
\h>

7.3.1 Observaciones sobre red de sensores:

La red de sensores debe de cumplir con el estándar Industrial IEEE 802.15.4 / ZigBee, que es el estándar para el
monitoreo y control utilizando dispositivos electrónicos de sensado y actuación llamados motes.

7.3.2 Observaciones sobre buses de campo

Los buses de campos pueden ser cualquiera de los mencionados en el capítulo número uno así como también puede ser
Ethernet industrial.

7.3.3 Observaciones sobre pre-procesamiento de información

Este procesador puede ser una PC o un ASIC, y realizara funciones de comunicación con el PLC. Será una PC si el
gateway de la red de sensores inalámbricos realiza su comunicación a través de Ethernet industrial, hacia un software
proporcionado por el proveedor de la RSI, y por lo general los PLC's poseen software de comunicación PC - PLC,
entonces esta PC será utilizada como puente entre RSI y PLC. Será un ASIC, si no se desea incluir un pe industrial, y si
la red de sensores es de baja escala.

7.3.4 Observaciones sobre PLC Industrial

El PLC industrial recibirá / enviara desde / hacia la red de sensores inalámbricos información y comandos y la utilizara
para tomar decisiones sobre los dispositivos que controla. Puede poseer uno o mas procesadores de comunicación hacia
diferentes buses de campo, así como módulos de entradas / salidas análogas o digitales.

7.3.5 Observaciones sobre Gateway

El gateway recibe la información de la red de sensores y la canaliza hacia un sistema usuario. En la actualidad es común
que el gateway se comunique vía Ethernet o RS-232. Por otro lado, si este tiene capacidad de procesamiento, se puede
implementar una aplicación capaz de direccionar la información hacia el procesador de comunicaciones de un PLC
industrial, sin la necesidad de un dispositivo de pre-procesamiento de información siempre y cuando este cumpla con la
estructura de comunicación del PLC.

A continuación se plantean una serie de pasos que garantizan el éxito de la implementación deseada basado en la
arquitectura general expuesta.

\h: 135
 Características funcionales

Definición de interlocutor

Esquema de comunicación

Interconexión específica

Especificación de Hardware, software y recurso humano

Equipo o Tiempo? Ruta critica de implementacion Desarrollo

Pruebas en campo
Pruebas

Implementacion
Implementacion
Documentación y mantenimiento
Mi

En la Figura núm. 42, se muestra el diagrama completo que indica cuales son los pasos a seguir para lograr con éxito la
implementación. En todos los pasos existe retroalimentación natural pero en el análisis de la tecnología comercial de RSI
y en las pruebas en campo, es evidente que si estas no son llevadas a cabo en forma analítica, se puede convertir en un
lazo sin fin. A continuación son descritas cada una de estas tases.

7.3.6 Fases del método

7.3.6.1 Fase 1 - Identificación de la necesidad real y definición de la aplicación final de la red de sensores
industriales

En este paso es necesario, partiendo de la necesidad real, determinar cual es la aplicación final de la red de sensores
inalámbricos dentro de la función, ya que como existe una gran variedad de aplicaciones con necesidades especificas, la
RSI debe de ser especificada para resolver objetivamente la función, y puesto que es una red que puede ser versátil en su
funcionamiento como fue comentado en el capítulo cuarto, tiene capacidad de acoplarse a un sin fin de aplicaciones. A
continuación se mencionan las necesidades más comunes en el ámbito industrial de forma general y que han sido
identificadas a lo largo de la investigación:

• Monitoreo de variables (energía, vibraciones, humo, luz, presencia física) en instalaciones físicas de la fábrica,
para realizar diagnostico e historiales.

• Monitoreo de temperatura y humedad en instalaciones físicas de la fábrica, para realizar el control con la
información proporcionada, ya que la instalación de estos sensores nodo es fácil de realizar.

• Monitoreo de variables especificas de una maquinaria, en la cual la instalación de sensores comunes (cableado
común o en red) se dificulta.

• Monitoreo de variables especificas de una maquinaria, en la cual la instalación de sensores comunes (cableado
común o en red) se dificulta, con el fin de controlar algún proceso en la maquina.

• Rastreo de activos dentro de un área como pueden ser: grúas, montacargas, los componentes de una celda de
manufactura flexible.

A continuación se muestran en la Tabla núm. 11 la variedad de aplicaciones de una red industrial de sensores
inalámbricos y que actualmente están disponibles en el mercado. La clasificación es de acuerdo a la dimensión en el

137
tiempo (Consulta y monitoreo, No crítico en tiempo real, y critico en tiempo real) que es una de las mas comunes, de
fácil identificación y que fueron comentadas en el capítulo tercero.

Tabla núm. 11.- Tipos de aplicaciones actuales para redes de sensores inalámbricos en ambientes industriales
clasificadas en base a la función.

Función final de la red de sensores inalámbricos Aplicaciones dentro de cada función

• Alumbrado, cualquier aplicación en control
Control Remoto
secuencia!
• Monitoreo de maquinas
Monitoreo del estado de la maquina • Indicadores de uso de equipo
• Mantenimiento predictivo
• Rastreo de activos
Supervisión de procesos • Inventario en proceso
• Rastreo de inventario de producto terminado
Configuración de sistema e intercambio de • Celdas de manufactura flexible
información • Recolección móvil de datos
• Cualquier proceso puede tener conectividad con
Conectividad con Internet.
Internet si el gateway de acceso lo permite
Registro de eventos • Registro de presencia en áreas restringidas
• AMR (Automatic Meter Reading), de variables de
suministro tales como energía eléctrica, agua, gas,
fluidos
Mediciones • Nivel de líquido en tanques distribuidos
• Monitoreo de procesos como motores, temperatura
presión
• Manufactura Automotriz
• Manejo de materiales
• Control continuo de procesos
Control de lazos con constantes de tiempo grandes • Control discreto de procesos
• Control de lazos de temperatura y humedad
• Control de flujo
Criticas en tiempo real
• Sistemas de distribución de vapor

Estas necesidades están día a día presentes en la industria, y por muchos años han sido la raíz de dolores de cabeza de
integradores y departamentos de ingeniería debido a que las soluciones tecnológicas presentes en el momento de tratar de
cubrirlas no eran las más adecuadas o no eran las más baratas. En base a la tabla anterior es definida la aplicación.

Vil! 138
M;

7.3.6.2 Fase II - Definición de las características funcionales de la red de sensores basándonos en los atributos
del fenómeno y sistema

En esta fase definimos las características funcionales de la red industrial de sensores inalámbricos en base a la aplicación
objetiva dentro de la función que cubre la necesidad real. A continuación es mencionada cada una de las características
que deben de definirse.

1. Escala.- La escala temporal y espacial esta enfocada en el intervalo de muestreo y la cobertura total del sistema.
a. Muestreo. Los fenómenos físicos a medir definen la escala de muestreo espacial y temporal. La escala
de muestreo es definida en función de la aplicación y el fenómeno de interés.
I. Muestreo temporal. Definir el tiempo de muestreo de la(s) variable(s) física(s), es decir, el
intervalo de tiempo en que la variable será registrada.
II. Muestreo espacial. Define el número de nodos por fenómeno de interés.
III. Muestreo asincrono. Detección de eventos
b. Extensión. Área física de cobertura de sensado de la RSI.
2. Variabilidad en el sistema. Se refiere el comportamiento del sistema en tres dimensiones diferentes:
a. Estructura. Se refiere a la variabilidad en la composición del sistema.
I. Ad Hoc. Define si la estructura de la RSI será dinámica, es decir, los sensores nodo cambiaran
de lugar y no estarán fijos. La movilidad puede ser realizada en forma autónoma o por el usuario
de la RSI.
II. Determinística. La estructura de la RSI es definida como fija, es decir, una vez que los sensores
nodo han sido esparcidos en campo, no volverán a ser movido dentro de su vida útil.
b. Tareas. Se definen las funciones que el sensor nodo debe de realizar antes de enviar la información a
la estación base.
c. Espacio. La variabilidad en el espacio, aplica a los sistemas y a los fenómenos. En este caso se
especifica si va a ser variable el sistema en el área debido a la movilidad de los nodos. En cuanto a los
fenómenos, es necesario tomar en cuenta que tan rápido pueden variar para realizar un diseño o
aplicación final tomando en cuenta el rango de variación.
3. Autonomía del sistema. Consiste en definir la autonomía de la aplicación. Mientras mayor sea la autonomía del
sistema, menor la intervención del humano y mayor la necesidad de procesamiento sofisticado dentro del
sistema. Dentro de la autonomía del sistema son consideradas los siguientes aspectos:
a. Modalidades, donde los sistemas verdaderamente autónomos dependen de múltiples modalidades
sensoriales. Diversas modalidades proporcionan resistencia a una otra con respecto a la incertidumbre
y pueden combinarse para eliminar ruido e identificar anomalías en las mediciones.
b. Complejidad. La autonomía de sistemas grandes conlleva también gran complejidad en el modelo
computacional.

139
 Basados pues en los conceptos expuestos tenemos tres tipos de sistemas dependiendo de sus modalidades y
complejidad:
a. Sistema de monitoreo caracterizado: Autonomía Baja, ya que solo posee una modalidad sensorial y la
función de enviar solo las señales adquiridas sin procesar por medio de la transducción en forma
síncrona.
b. Sistema de monitoreo y detección de eventos caracterizado: Autonomía Media, ya que sus
modalidades sensoriales se incrementan desde el momento de detectar eventos y enviar señales en
forma síncrona y asincrona, por lo que la complejidad de cómputo en cada nodo aumenta. Este
esquema de control es propio de redes de sensores de gran escala (gran cantidad de sensores nodo)
para desempeñar funciones de recopilación de información, monitoreo y ejecución de tareas
complicadas.
c. Sistema de monitoreo y detección de eventos variable: Autonomía Alta, ya que posee varias
modalidades sensoriales además de capacidad de autoconfíguración para adaptarse al entorno con el fin
de realizar con éxito la aplicación, la complejidad de cómputo en cada nodo es mayor aun. Este
esquema de control es propio de redes de sensores de gran escala (gran cantidad de sensores nodo)
para desempeñar funciones de recopilación de información, monitoreo y ejecución de tareas
complicadas
4. Propagación de información. Consiste en definir en que forma será propagada la información desde las
terminales o sensores nodo, hasta la estación base o gateway. Existen dos opciones que pueden ser:
a. Sistemas single-hop: La información solo puede ser transmitida a otra terminal, y la terminal receptora
no tiene capacidad de transmitir la señal a otra terminal. Por lo general las terminales transmiten hacia
la estación base o gateway.
b. Sistemas multi-hop: La información puede ser propagada de terminal en terminal hasta llegar a un
punto deseado, y como se percibe, puede ser en todas direcciones. En general la rutas de propagación
son: desde gateway hasta una terminal, y desde una terminal hasta un gateway, obviamente pasando
por muchas estaciones multihop cuya función es rutear hasta el destino.
5. Fusión de datos. Consiste en especificar si la aplicación debe de realizar fusión de ciatos a lo largo de la red de
sensores inalámbricos. A continuación se mencionan las dos opciones:
a. Fusión de datos: Es una opción apropiada para sistemas a gran escala con sensores nodo distribuidos
densa y masivamente. Es necesario puntualizar que el usuario final esta interesado en la información
colectiva con una precisión suficiente y aceptable. Los costos son la complejidad de cómputo en casi
todos los nodos y las ventajas son un gran ancho de banda disponible debido al procesamiento de
información en red y ahorro de energía debido a la disminución de información en la comunicación.
b. No fusión de datos: Es apropiada para sistemas que tienen una densidad pequeña de nodos y en donde
la precisión de las mediciones es critica para el usuario final. También se considera que si la red debe
incrementarse en algún momento en cantidad de nodos, los problemas en throughput y colisiones se
harán presentes.

140