DocsTec-5734

•

ITESM

Todo para Aprender

1/11/2022

¡Este material tiene más páginas!

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN MECATRÓNICA Y
TECNOLOGÍAS DE INFORMACIÓN

ESTUDIO EXPERIMENTAL DEL QoP DEL CONTROLADOR DE UN NCS
BASADO EN CAN

T E S I S

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO
ACADÉMICO DE:

MAESTRO EN CIENCIAS CON ESPECIALIDAD EN
AUTOMATIZACIÓN

POR

JOSÉ RODRIGO TÁGER PENADOS

MONTERREY, N.L. DICIEMBRE DEL 2007
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

CAMPUS MONTERREY

DIVISIÓN DE MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN

PROGRAMA DE GRADUADOS EN MECATRÓNICA Y
TECNOLOGÍAS DE INFORMACIÓN

Los miembros del comité de tesis recomendamos que el presente proyecto de tesis
presentado por el Ing. José Rodrigo Táger Penados sea aceptado como requisito parcial
para obtener el grado académico de:

MAESTRO EN CIENCIAS CON ESPECIALIDAD EN
AUTOMATIZACIÓN

Comité de Tesis:

Dr. Ricardo A. Ramírez Mendoza
Asesor

Dr. Rubén Morales Menéndez M.C. Artemio Aguilar Coutiño
Sinodal Sinodal

APROBADO

Dr. Graciano Dieck Assad
Director del Programa de Graduados en Mecatrónica y Tecnologías de Información
Diciembre del 2007

ESTUDIO EXPERIMENTAL DEL QoP DEL CONTROLADOR DE UN NCS
BASADO EN CAN

POR:

JOSÉ RODRIGO TÁGER PENADOS

T E S I S

Presentada al Programa de Graduados en Mecatrónica y
Tecnologías de Información

Este trabajo es requisito parcial para obtener el grado de
Maestro en Ciencias con Especialidad en Automatización

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY

Diciembre del 2007

A mis papás: Emilio y Anabella.

A mis hermanos y hermanas: Carlos, Emilio, Pablo,
Alenka y Claudia.

A mis abuelos: Emilio, Magdalena, Julio y Any.

Agradecimientos

Agradezco al Tecnológico de Monterrey ya que a través de su programa de becas pude
realizar mis estudios de profesional y posgrado. Han sido 6 años de formación
académica de excelencia con visión humanística y de competitividad internacional.

Quiero agradecer a mi asesor, el Dr. Ricardo Ramírez, por haberme permitido trabajar
en el Laboratorio de Autotrónica y por sus consejos para el desarrollo de esta tesis.
Asimismo, agradezco a mis sinodales, el Dr. Rubén Morales y el M.C. Artemio Aguilar,
por el tiempo dedicado a la revisión de este proyecto.

A mis amigos de la maestría, Jorge Estuardo Castillo, Juan Antonio Balandrán, Adrián
Caleb González, Carlos García, Jorge Treviño y Jaime López, les agradezco por el
tiempo compartido dentro y fuera de las aulas. Gracias a ellos, las clases resultaron
divertidas.

Estoy agradecido también con los amigos con los que he compartido estos 6 años:
Mario Quant, Álvaro Garnés, Eduardo y Gerardo Morales, Román y Emmanuel
Sánchez, Jorge Rodríguez, Pablo Pérez, Ruthmaría Díaz, Fredimar y Fortino Carbajal,
Edgar Vásquez, Abdi Esquivel. A todos ellos los conozco desde mis primeros
semestres: cada aventura, cada personalidad, cada discusión sobre fútbol y demás, me
hicieron una mejor persona.

Quiero agradecer también a todas aquellas personas con las que compartí en mi
formación profesional, a mis profesores y demás amigos.

Por último, pero no menos importante, quiero darle gracias a mi familia quien desde
muy lejos siempre me apoyó, pero sobretodo, siempre creyó en que podía lograrlo.

CONTENIDO
Contenido

Lista de Símbolos……………………………………………………………… 8

1. Introducción……………………………………………………………...... 10
1.1 Descripción del problema…………………………………………………... 10
1.2 Antecedentes y Justificación………………………………………………... 11
1.3 Objetivos……………………………………………………………………. 12
1.4 Hipótesis de trabajo…………………………………………………………. 13
1.5 Metodología………………………………………………………………… 13
1.6 Organización………………………………………………………………... 13

2. Sistemas de control en red………………………………………………… 15
2.1 NCS básico………………………………………………………………….. 15
2.2 Limitantes y características de una red……………………………………... 16
2.2.1 Velocidad y ancho de banda de la red………………………………. 16
2.2.2 Retraso y jitter en la transmisión de un mensaje…………………… 17
2.2.3 Otros factores que afectan al QoS…………………………………... 18
2.2.4 Los protocolos de red……………………………………………….. 19
2.3 La red y su efecto en un NCS………………………………………………. 20
2.4 Redes para control…………………………………………………………... 22
2.5 La investigación en NCS……………………………………………………. 23
2.5.1 Estado del arte en el estudio de protocolos de red para NCS……….. 23
2.5.2 Estado del arte en el diseño de controladores digitales para NCS….. 26

3. Controller Area Network…………………………………………………. 28
3.1 Conceptos básicos…………………………………………………………... 28
3.2 La Trama CAN……………………………………………………………… 30
3.3 Tipos de tramas……………………………………………………………... 31
3.4 Proceso de Arbitraje………………………………………………………… 32
3.5 Manejo de los errores……………………………………………………….. 32
3.6 Consideraciones de la capa física…………………………………………… 33
3.7 CAN y su aplicación en los automóviles…………………………………… 34

4. Plataforma Experimental…………………………………………………. 37
4.1 Hardware……………………………………………………………………. 37
4.1.1 Descripción General………………………………………………… 37
4.1.2 Nodo CAN………………………………………………………….. 38
4.1.3 Tarjeta de comunicación USB MUX 4C2L………………………… 39
4.1.4 Maqueta Full CAN X3……………………………………………… 39
4.2 Software…………………………………………………………………...... 43
4.2.1 Programa base de cada nodo CAN…………………………………. 43
4.2.2 Nodo Proceso……………………………………………………….. 44
4.2.3 Nodo Controlador…………………………………………………... 54
4.2.4 Nodo Generador de Carga…………………………………………... 58
4.2.5 Aspectos prácticos de la comunicación……………………………... 61

CONTENIDO
5. Resultados Experimentales……………………………………………….. 62
5.1 Modelo de suspensión activa de un cuarto de vehículo…………………….. 62
5.2 Valores de operación………………………………………………………... 67
5.3 Diseño de Experimentos……………………………………………………. 68
5.4 Resultados de simulación…………………………………………………… 72
5.5 Resultados a baja velocidad (125 kbit/s)……………………………………. 74
5.6 Resultados a alta velocidad (500 kbit/s)……………………………………. 82
5.7 Análisis de resultados……………………………………………………….. 83

6. Conclusiones y Trabajos Futuros………………………………………… 87
6.1 Conclusiones…………………………………………………………........... 87
6.2 Trabajos Futuros……………………………………………………………. 88

Referencias Bibliográficas…………………………………………………….. 89

Apéndice A: Detallas sobre CAN……………………………………………... 93
A.1 Detalle de la estructura de una trama CAN………………………………… 93
A.2 Ejemplo del proceso de arbitraje en CAN………………………………….. 94
A.3 Descripción de los errores que se pueden presentar en CAN……………… 95

8
LISTA DE SÍMBOLOS
Lista de Símbolos

Símbolo Significado

C Matriz de salida de dimensión m x n.
cs Constante del amortiguador
cus Constante de amortiguamiento de la llanta
D Matriz de acople entrada – salida de dimensión m x r.
EXi Señal de error para variable de estado i
F Vector de perturbación de dimensión n.
G Matriz de estado de dimensión n x n.
H Matriz de entrada de dimensión n x r.
J Índice de desempeño
JXi Medida del QoP para variable de estado i
k Índice de tiempo discreto
K Ganancia de retroalimentación de dimensión r x n
ks Constante elástica del resorte entre el chasis y la llanta
kus Rigidez elástica de la llanta
ms Masa suspendida
mus Masa no suspendida
P Matriz de solución de Riccati de dimensión n x n
Q Matriz de peso para optimización de dimensión n x n
R Matriz de peso para optimización de dimensión r x r
r1 Parámetro 1 de ajuste de suspensión
r2 Parámetro 2 de ajuste de suspensión
r3 Parámetro 3 de ajuste de suspensión
t TiempoT Tiempo de muestreo
Tdelay Tiempo de retraso de transmisión
Tpre Tiempo de preprocesamiento
Twait Tiempo de espera para envío de mensaje
Ttx Tiempo que toma a una trama viajar por el medio físico

9
LISTA DE SÍMBOLOS
Tpost Tiempo de postprocesamiento
τsc Tiempo de retraso de la señal del sensor al controlador
τca Tiempo de retraso de la señal del controlador al actuador
U Señal de control del actuador en modelo de suspensión
u(t) Entrada del bloque actuador – proceso – sensor en un NCS
u (k) Vector de entrada de dimensión r.
)t(u Salida del controlador en un NCS
w(k) Escalar que representa la perturbación.
x (k) Vector de estado de dimensión n.
y(t) Salida del bloque actuador – proceso – sensor en un NCS
y (k) Vector de salida de dimensión m.
)t(y Entrada del controlador en un NCS
Zs(t) Desplazamiento de la masa suspendida
Zus(t) Desplazamiento de la masa no suspendida
Zo(t) Irregularidades del terreno

10
Capítulo 1 INTRODUCCIÓN
1. Introducción

El gran avance que se ha logrado en los últimos años en el campo de los sistemas
embebidos y las tecnologías de red ha dado lugar a una nueva área conocida como
Sistemas de Control en Red (NCS por sus siglas en inglés). Este término se refiere a un
tipo de sistema en el que los sensores, los actuadores y los elementos de cómputo (i.e.
controladores) están conectados vía una red o algún otro tipo de medio compartido. Ello
implica que la red pasa a ser un elemento del sistema de control y dadas las limitantes
que posee (e.g. velocidad de transmisión, retraso en comunicación), hace que los
problemas clásicos de la teoría de control (e.g. estabilización, estimación, regulación,
optimización, robustez) tengan que ser reevaluados dando lugar a una amplia área de
investigación [1].

El incorporar una red de comunicación en el lazo de control implica muchas ventajas.
En primer lugar, al ya no existir conexiones punto a punto en los sistemas de control
(i.e. se comparte ahora un mismo medio de comunicación), se reduce el volumen del
cableado. Asimismo, se minimizan los puntos potenciales de falla por ruptura del canal
de comunicación, lo que supone un incremento en la confiabilidad del sistema. Otras
ventajas son que permite que se distribuya el procesamiento, incrementa la capacidad
para detección de fallas y mantenimiento, mejora la intercambiabilidad e
interoperabilidad de los dispositivos y aumenta la reconfigurabilidad de los sistemas de
control [2].

1.1 Descripción del problema

La investigación en los NCSs se divide en dos áreas: protocolos de comunicación y
diseño de controladores digitales. La primera busca analizar los distintos protocolos de
red que existen, desde el punto de vista del parámetro calidad de servicio (QoS por sus
siglas en inglés), y con ello determinar su factibilidad de implementación dentro de un
lazo de control. Se busca que un protocolo específico cumpla con características de
garantía de transferencia de mensajes y retraso de transmisión mínimo asegurando una
calidad de desempeño del controlador (QoP por sus siglas en inglés) aceptable. En

11
Capítulo 1 INTRODUCCIÓN
cuanto al diseño de controladores, se trata de un área de investigación en la que se
proponen leyes de control que tomen en cuenta los efectos de la red en un NCS.

Controller Area Network (CAN) es un protocolo de red propuesto por Robert Bosch con
la intención de intercomunicar las distintas unidades de control del motor (ECU por sus
siglas en inglés) dentro de los automóviles. Su bajo costo, robustez y sus diferentes
mecanismos para detección de fallas lo han hecho lo suficientemente atractivo como
para dominar el mercado automotriz e incursionar en otras áreas, como los sistemas de
manufactura [3].

El presente trabajo de tesis es un estudio experimental del QoP del controlador para un
NCS basado en CAN. El análisis se hace creando distintas condiciones de QoS a partir
de tres variables: velocidad de transmisión, carga de la red y prioridad de los mensajes.
Estos tres parámetros, para el caso específico de CAN, afectan directamente el retraso
de transmisión y en consecuencia, al QoP del controlador del NCS.

1.2 Antecedentes y Justificación

Existen diversos protocolos de red que han sido propuestos para control. Un estudio de
comparación entre tres de los protocolos más utilizados en la industria es el que realiza
[4]. En dicha investigación se analiza, ante dos casos de simulación y diversas
condiciones, la eficiencia de la red, utilización y tiempo de retraso de transmisión de
cada uno de los protocolos: Ethernet, DeviceNet (que está basado en CAN) y
ControlNet. Dicho estudio arroja conclusiones acerca de las condiciones en las cuales
cada protocolo garantiza un QoS aceptable para utilizarse en un NCS y además hace un
análisis detallado de cada uno de los componentes del retraso de transmisión.

[5] hace un análisis del QoP de un PID en un NCS. Nuevamente, el estudio se hace para
Ehernet, DeviceNet y ControlNet. El proceso que se utiliza es una herramienta de
máquina donde se controla el posicionamiento en tres ejes. El QoP es cuantificado
utilizando criterios ITAE e IAE para distintas condiciones de red y haciendo énfasis en
el efecto de la selección del tiempo de muestreo. Los resultados que obtiene marcan las
condiciones de red y control para un QoP óptimo del PID para el proceso utilizado.

12
Capítulo 1 INTRODUCCIÓN
Otro estudio del QoP de un PID para un NCS lo hace [6]. En dicho trabajo se hace una
comparación del desempeño del controlador para dos protocolos de red: Ethernet y
Switched Ethernet. La plataforma experimental supone como proceso un servomotor y
el análisis se hace únicamente variando la carga de la red. El desempeño del PID se
cuantifica a partir del sobretiro y del tiempo de establecimiento en lazo cerrado. Los
mejores resultados que se obtienen son aquellos donde se utiliza Switched Ethernet ya
que, dado el determinismo que supone debido a su condición de protocolo que utiliza
multiplexaje por división en el tiempo, se ve poco afectado por la carga de red.

Un estudio más completo de los antecedentes de este trabajo de investigación se
presenta en el capítulo 2.

Considerando que actualmente CAN es el protocolo más utilizado en el ámbito
automotriz y que su uso se ha extendido a otros campos, es preciso realizar un análisis
que mida el efecto que dicho protocolo supone en un lazo de control. Los resultados de
tal estudio servirán para sentar las bases para trabajos futuros en el diseño de
controladores para NCSs basados en CAN.

1.3 Objetivos

Los objetivos de este trabajo de investigación son los siguientes:

• Hacer un análisis del QoP de controlador para un NCS basado en CAN. Se pretende
mostrar las condiciones de configuración de red (i.e. velocidad de transmisión, carga
de la red y prioridad de mensaje) para las cuales se obtiene un QoP de controlador
aceptable.

• Desarrollar una plataforma experimental de NCSs basada en CAN. Esta plataforma
debe ser de carácter general permitiendo especificar modelo del proceso, ley de
control y configuración de la red.

13
Capítulo 1 INTRODUCCIÓN
1.4 Hipótesis de trabajo

El QoP del controlador de un NCS basado en CAN se ve afectado por la configuración
de red utilizada: velocidad de transmisión, carga de la red y prioridad de mensaje.
Aquellas condiciones que impliquen un mayor tiempo de retraso de transmisión de
mensajes entre los sensores, controladores y actuadores, afectarán negativamente al QoP
del controlador y, en los casos más críticos, harán inestable al sistema.

1.5 Metodología

El primer paso de este trabajo de investigación consistió en el diseño e implementación
de la plataforma experimental.Se trata de un esquema básico de NCS en el que el
bloque actuador – proceso – sensor se encuentra en un nodo de la red, mientras que el
controlador en otro. Es una plataforma de carácter general donde el usuario tiene la
posibilidad de ingresar el modelo del proceso a utilizar, la correspondiente ley de
control, así como la configuración de red deseada. Para ser más real el problema, el
NCS especificado se encuentra conectado a una maqueta que simula una red automotriz.

El siguiente paso correspondió a la experimentación. Se trabajó como proceso un
modelo de suspensión de un cuarto de vehículo y se utilizó control LQ basado en
retroalimentación completa de estados. Se realizaron diversos experimentos ante
distintas configuraciones de la red buscando variar el retraso de transmisión y con ello,
el QoP del controlador.

Una vez realizada la experimentación, se procedió a realizar su correspondiente análisis,
se obtuvieron conclusiones al respecto y se propuso trabajos a futuro.

1.6 Organización

En este capítulo se definió el problema de investigación, sus objetivos, la hipótesis y la
metodología que se siguió.

14
Capítulo 1 INTRODUCCIÓN
En el capítulo 2 se define el marco teórico de los sistemas de control en red. En él se
explica los efectos que supone introducir la red en un lazo de control. Asimismo se hace
una revisión del estado del arte de esta área de investigación.

En el capítulo 3 se presenta las características, especificaciones y aplicaciones del
protocolo CAN.

En el capítulo 4 se hace una descripción detallada del diseño e implementación de la
plataforma experimental.

En el capítulo 5 se muestran los resultados experimentales que se obtuvieron.
Asimismo, se definen las pruebas realizadas y se hace un análisis de ellas.

Por último, en el capítulo 6 se presentan las conclusiones de este trabajo de
investigación y se definen los trabajos a futuro.

15
Capítulo 2 SISTEMAS DE CONTROL EN RED
2. Sistemas de control en red

Un sistema de control en red (NCS por sus siglas en inglés) es aquel en el que los
sensores, actuadores, procesos y controladores comparten un mismo medio de
comunicación. La red pasa a ser un elemento del sistema y sus efectos obligan el
nacimiento de una nueva área de investigación [1].

En el presente capítulo se hace una descripción de los principios básicos de un NCS, los
retos que se encuentran en su diseño y una revisión del estado del arte.

2.1 NCS básico

La figura 2.1 muestra el diagrama a bloques de un Sistema de Control en Red básico.
En dicha figura, y(t) ∈ Rn y u(t) ∈ Rm representan la salida y entrada del bloque
actuador – proceso – sensor respectivamente. Por su parte )t(y y )t(u denotan la
entrada y salida del controlador respectivamente. La comunicación entre ambas partes
se da a través de una red con un protocolo específico (e.g. Ethernet, CAN, WiFi), en la
cual pueden estar conectados uno o más sistemas de control.

Figura 2.1 Diagrama a bloques de un NCS básico

Las señales )t(y y )t(u en general difieren de y(t) y u(t) debido a la presencia de la red
en el sistema de control. Dichos efectos, relacionados con las limitantes y características
de un tipo específico de red, se detallan en el siguiente apartado.

16
Capítulo 2 SISTEMAS DE CONTROL EN RED
2.2 Limitantes y características de una red

La función principal de una red es transmitir información de un nodo a otro. Su
desempeño de operación se mide a través del parámetro conocido como Calidad del
Servicio (QoS por sus siglas en inglés). Esta variable depende del protocolo específico
de red utilizado y se debe tomar en cuenta en el diseño del NCS. El QoS está
determinado principalmente por dos factores: velocidad y ancho de banda de la red, y el
retraso y jitter en la transmisión de un mensaje.

2.2.1 Velocidad y ancho de banda de la red

El ancho de banda de una red industrial está dado en términos del número de bits que se
pueden transmitir por segundo. La velocidad se refiere al inverso de dicha tasa de
transmisión (i.e. tiempo de transmisión de un bit). Sin embargo, se debe considerar que
en una trama de mensaje, no todos los bits enviados representan información importante
a ser procesada por el nodo destino: además de dicha información, una trama debe
contener un encabezado donde de algún modo se encapsule la dirección del transmisor y
del receptor, así como muchas veces se incluye algún checksum o algún otro dato que
permita detectar errores. Debido a esto, existe el concepto de ancho de banda efectivo,
que se refiere al número de bits “útiles” que se transmiten por segundo (i.e. quitando
encabezados, bits de stuffing, checksum, etc.). Además, hay que tener en cuenta que
entre el envío de una trama y otra, para poder distinguirlas, debe existir un tiempo
mínimo conocido como interframe time y varía de acuerdo al protocolo de red. Por
último, a lo anterior hay que sumarle el tiempo que se pierde cuando existen colisiones
(si es que el protocolo lo permite) [4].

Para ilustrar lo anterior, considerar el siguiente ejemplo: para enviar un bit de datos a
través de una red CAN a 500 kbit/s, se requieren 48 bits de mensaje (47 bits de la trama
más uno por el interframe), lo que implica 96 μs; para enviar el mismo bit a través de
una red Ethernet a 10 Mbit/s, se requieren 84 bytes de mensaje (64 bytes de la trama
más 20 por el interframe), lo que implica 67.2 μs. De este modo, a pesar de que la tasa
de transmisión bruta de Ethernet es 20 veces más grande que CAN, el tiempo de
transmisión del mismo bit no es más que 30% menor [2].

17
Capítulo 2 SISTEMAS DE CONTROL EN RED
2.2.2 Retraso y jitter en la transmisión de un mensaje

El tiempo de retraso en una red se refiere al tiempo total que existe entre el momento en
que un nodo desea enviar un mensaje, hasta el momento en que el nodo receptor lo
recibe y decodifica. El jitter es el término acuñado a la variabilidad de dicho retraso. La
figura 2.2 muestra el diagrama de tiempo que se sigue para enviar mensajes a través de
una red entre dos nodos. El tiempo de retraso para comunicar un mensaje entre el nodo
A y el nodo B, está dado por:

posttxwaitpredelay TTTTT +++= (2.1)

Este tiempo puede dividirse a su vez en tres partes: tiempo de retraso del nodo fuente
(i.e. Tpre + Twait), tiempo de retraso del canal (i.e. Ttx) y tiempo de retraso del nodo
destino (i.e.Tpost). Tpre se refiere al tiempo de preprocesamiento que necesita el nodo
fuente para realizar el cómputo del dato y para encapsularlo (i.e. convertirlo en trama de
acuerdo al protocolo de red utilizado). Si la red se encuentra ocupada (i.e. algún otro
nodo está enviando un mensaje), se debe esperar entonces un tiempo Twait para enviar el
mensaje. En cuanto al retraso del canal, Ttx es el tiempo que le toma al mensaje viajar
por el medio físico (e.g. par trenzado, por medio inalámbrico, fibra óptica). Por último,
en el nodo destino, antes de que éste puede utilizar el dato recibido, debe ocupar un
tiempo Tpost para el postprocesamiento en donde se incluye la decodificación de la trama
y el cómputo del dato.

Figura 2.2 Diagrama de tiempo de la comunicación entre dos nodos en una red [2]

18
Capítulo 2 SISTEMAS DE CONTROL EN RED
En cuanto a los tiempos de preprocesamiento (i.e. Tpre) y postprocesamiento (i.e. Tpro),
hay que apuntar que en la mayoría de los casos se asume como constante y despreciable.
Sin embargo, [2] apunta que en general eso no es cierto ya que varía de acuerdo al
dispositivo utilizado (e.g. microcontrolador, DSP, PLC). Por esta razón, al momento de
la selección de los componentes a utilizar en el diseño de una red industrial, es
importante hacer una revisión de las especificaciones de tiempo.El tiempo de retraso del canal (i.e. Ttx) incluye el tiempo total de transmisión de un
mensaje a través del medio y su tiempo de propagación. Se ve afectado por diversos
factores: tamaño del mensaje, velocidad de transmisión y el largo del cable de red o
distancia de separación entre los nodos. Para ilustrar esta situación, en el caso de
Ethernet, utilizando un cable de 2500 metros el tiempo de propagación es de 25.6 μs [4].

De acuerdo a [2], el tiempo de espera (i.e. Twait) es el parámetro que más influye en la
variabilidad del retraso (i.e. jitter). El Twait se debe a dos factores: el tiempo de cola, que
se refiere al lapso que un mensaje debe esperar en el buffer del transmisor en caso de
que tramas previas no se hayan enviado; y el tiempo de bloqueo, que se refiere al
momento que la trama debe esperar a que la red se desocupe. De este modo, el Twait
depende mayormente en el protocolo de red utilizado (e.g. Ethernet, CAN), en el tipo de
conexión de mensaje (e.g. maestro – esclavo, consumidor – proveedor) y en la carga o
tráfico de la red.

2.2.3 Otros factores que afectan al QoS

Además del ancho de banda, velocidad de transmisión, el retraso y el jitter, el QoS se ve
afectado por otros factores. Uno de ellos tiene que ver con la confiabilidad en la
transmisión de datos. Algunos medios físicos de transmisión son más vulnerables que
otros a la corrupción en los datos por interferencia electromagnética. Asimismo, algunos
protocolos poseen mecanismos de detección de errores, mientras que otros no. El
utilizar dichos procedimientos aumenta la confiabilidad de la red, pero al mismo tiempo
disminuye el ancho de banda efectivo.

19
Capítulo 2 SISTEMAS DE CONTROL EN RED
Otro factor a considerar en el QoS es el referente a la seguridad. Algunas redes pueden
estar vulnerables al ataque de virus basados en internet. Por lo general, los buses
industriales no fueron diseñados para ser altamente seguros por lo que se protegen
únicamente por aislamiento físico. Sin embargo, existen algunos que utilizan técnicas
sofisticadas de encriptamiento [2].

2.2.4 Los protocolos de red

Los distintos parámetros que afectan al QoS dependen del protocolo de red que se
utiliza. Específicamente, la diferencia se encuentra en la subcapa MAC (de Medium
Access Control) que es la que describe la forma en la que el protocolo obtiene el acceso
a la red. Este factor afecta específicamente al Twait descrito anteriormente. En las redes
utilizadas para control, existen tres tipos principales de MAC [2]:

• Multiplexaje por división en el tiempo (TDM): Este tipo se puede implementar de
dos modos: maestro – esclavo y por paso de token. En el caso del maestro – esclavo,
los nodos esclavos pueden enviar datos a través de la red únicamente cuando el nodo
maestro se los pide; por lo tanto, no existen colisiones ya que el maestro es quien se
encarga de controlar el acceso. Por otro lado, en el caso del paso de token, el único
nodo que puede enviar un mensaje a través de la red es el que posee el token en
dicho momento; una vez que haya enviado su trama, o bien se le haya terminado el
tiempo máximo de retención del token, debe pasar éste al nodo vecino. Este tipo de
implementación resulta muy eficiente en carga alta, ya que no existen colisiones y
ningún nodo monopoliza la red; sin embargo, en carga baja es ineficiente ya que se
pierde tiempo en el paso del token.

• Acceso aleatorio con prioridad para evitar colisiones: Cualquier nodo puede enviar
un mensaje en el momento en que desee siempre y cuando la red se encuentre
desocupada. Por dicha razón, antes de empezar a transmitir su trama, el nodo
“escucha” la red y al detectar su inactividad, empieza a enviar el mensaje. En caso
de que dos nodos quieran transmitir al mismo tiempo, existe un método de arbitraje
por prioridad que evita que existan colisiones, de tal forma que el mensaje del nodo
con mayor prioridad prevalece.

20
Capítulo 2 SISTEMAS DE CONTROL EN RED
• Acceso aleatorio con retransmisión al momento de colisiones: Similar al anterior,
con la diferencia que en éste, al existir colisiones (i.e. uno o más nodos quieren
transmitir al mismo tiempo), los nodos dejan de transmitir y después de un tiempo
aleatorio vuelven a intentar enviar su mensaje.

De cada uno de éstos existen muchos ejemplos de protocolos. La tabla 2.1 muestra los
más populares en la industria de acuerdo con [2]. En dicha tabla, RA significa acceso
aleatorio; CD, detección de colisión; CA, evasión de colisión; AMP, arbitraje en la
prioridad del mensaje; TDM, multiplexaje por división en el tiempo; TP, paso de token;
MS, maestro esclavo.

Tabla 2.1 Protocolos de red más populares en aplicaciones industriales [2]
Protocolo de Red Tipo Usuarios Máxima
Velocidad
No. máximo de
dispositivos
Ethernet TCP / IP RA/CD 78% 1 Gb/s 1024
Modbus TDM/MS 48% 35 Mb/s 32
DeviceNet (CAN) RA/AMP 47% 500 kb/s 64
ControlNet TDM/TP 39% 5 Mb/s 99
WiFi RA/CA 35% 11 Mb/s ??
Modbus TCP TDM/MS 34% 1 Gb/s 256
PROFIBUS –DP TDM/MS y TP 27% 12 Mb/s 127
AS-I TDM/MS 17% 167 kb/s 31

Como se puede observar, existen muchos protocolos que son combinaciones de los tipos
de MAC descritos. Además, la suma total de los usuarios da más del 100% ya que
muchas compañías utilizan más de un tipo de red.

2.3 La red y su efecto en un NCS

Incorporar la red en el sistema de control supone diversas consecuencias dada sus
limitantes; entre ellas las más importantes son [1]:

21
Capítulo 2 SISTEMAS DE CONTROL EN RED
• Retraso en la transmisión de la señales entre los componentes (e.g. del sensor al
controlador; del controlador al actuador). Estos retrasos pueden ser constantes o
variantes en el tiempo, determinísticos o estocásticos.

• Posibilidad de que la información falle en alcanzar su destino o bien que llegue de
forma errónea. Este tipo de situación se da mayormente en aquellos NCSs
implementados con un protocolo de red con un sistema de detección de errores de
pobre desempeño o nulo.

• Cuellos de botella que ocurren en las situaciones donde existe alta carga de la red o
bien que la tasa de transferencia de mensajes no es la adecuada. Además, se presenta
esta situación cuando los elementos de cómputo (e.g. CPU, microcontrolador) no
tienen el suficiente poder de cálculo para cumplir con los requerimientos de tiempo
y diseño.

La magnitud de estos efectos depende del QoS del protocolo de red utilizado. Hay que
destacar que el efecto más notorio en un NCS es el referente al retraso que sufren la
señales, ya que los otros dos efectos se ven contrarrestados con la selección de un
protocolo de red robusto y seguro. De este modo, si se añade el efecto del retraso al
NCS de la figura 2.1, se obtiene el NCS de la figura 2.3, donde τsc se refiere al retraso
de la señal del sensor al controlador, mientras que τca corresponde al retraso del
controlador al actuador. Este esquema de NCS es el que se encuentra como problema
clásico de investigación y reto de diseño en esta área ya que el retraso en un lazo de
control afecta en el desempeño de éste y en su estabilidad [1].

Figura 2.3 NCS que incorpora el efecto del retraso en la transmisión de las señales

22
Capítulo 2 SISTEMAS DE CONTROL EN RED
2.4 Redes para control

Las redes de control son distintas a las redes de datos (e.g. internet). Estas últimas están
caracterizadas por la transmisión de grandes paquetes de datos, alta velocidad y por lo
general su desempeño no se ve afectado por el efecto del retraso en la transmisión. Por
su parte, las redes que se utilizan para control sobresalen por la transmisión de tramas
pequeñas (i.e. el campo de datos no es muy grande) a alta velocidad tratando de cumplir
con criterios de tiempo críticos dado el efecto que el retraso supone en un lazo de
control.

Otro puntoa remarcar es que en un NCS las señales se dividen en dos categorías: de
tiempo real y basadas en evento. Las primeras se refieren a aquellas que deben ser
recibidas en un monto específico de tiempo para asegurar la correcta operación del
sistema. Este tipo de señales son las que usualmente se manejan para la
retroalimentación sensor – controlador (e.g. posición, velocidad, aceleración) en el caso
de servosistemas y reguladores. Dado que se trata de control en tiempo real, el protocolo
de red que se utilice debe contar con un alto nivel de determinismo, es decir, debe
garantizar que la señal llegue a su destino en un cierto límite de tiempo. Por otro lado,
las señales basadas en evento son las que usualmente utiliza el controlador para tomar
decisiones y no tienen un tiempo límite. Para este tipo de señales, el sistema espera
hasta que se reciba la señal (e.g. de un sensor) e inmediatamente envía la señal de
control. Usualmente se encuentran estas señales en líneas automatizadas de ensamble y
manufactura basadas en control lógico.

En el diseño de un NCS se debe especificar el tipo de conexión de mensaje que se
utilizará: tipo strobe, tipo poll y de cambio de estado (COS) / cíclico. En la primera de
ellas, que es una variante del tipo maestro – esclavo, el nodo maestro envía una señal de
petición a todos los nodos esclavos quienes responden con el valor de su condición
actual. En el caso del tipo poll, el maestro envía señales individuales a los nodos
esclavos y éstos responden. Por último, en el caso del cambio de estado (COS) / cíclico,
los dispositivos envían mensajes cuando su estatus cambia o bien lo hacen
periódicamente. Este último tipo es el más común en las aplicaciones de control; sin
embargo, los otros dos tipos también son utilizados [2].

23
Capítulo 2 SISTEMAS DE CONTROL EN RED
Por último, es importante destacar que la selección del tiempo de muestreo en un NCS
afecta en la calidad del desempeño del controlador (QoP por sus siglas en inglés).
Normalmente, se sabe que entre más pequeño sea el tiempo de muestreo, mejor será el
desempeño; sin embargo, en un NCS, al hacer más pequeño ese tiempo, se aumenta la
carga de la red, lo que implica un mayor retardo en transmisión y en consecuencia, en
algunos casos, una disminución del QoP. Por esta razón, se debe seleccionar un tiempo
que optimice el QoP tomando en cuenta el QoS del protocolo de red utilizado y los
requerimientos del sistema [5].

2.5 La investigación en NCS

La investigación en los Sistemas de Control en Red se centra en dos áreas: protocolos
de comunicación y diseño de controladores. El objetivo de dicha investigación es el
estudio de protocolos que garanticen una buena calidad del servicio de la red (QoS) y el
diseño de controladores digitales que permitan una buena calidad del desempeño del
controlador (QoP) ante los efectos de la red [7].

2.5.1 Estado del arte en el estudio de protocolos de red para NCS

Esta área recae en la teoría de la información y redes de comunicación, donde se busca
que los mensajes en una red se transmitan con la mayor precisión posible evitando la
pérdida de paquetes y garantizando un tiempo de retraso aceptable. Antes del
surgimiento de los NCSs, las redes de comunicación se utilizaban únicamente para
transmitir grandes cantidades de datos entre diversos dispositivos conectados por un
mismo medio (i.e. redes de datos). A partir del momento en que se decidió incluir la red
como elemento del lazo de control, se empezaron a proponer nuevos protocolos (e.g.
ControlNet, CAN) así como adecuaciones a los otros para su uso en el área (e.g.
Ethernet). La investigación en esta área se ha enfocado principalmente en modelar y
analizar el desempeño de estos protocolos, así como en el diseño de métodos que
permitan incrementar el QoS al reducir tiempos de transmisión.

En [4] se hace una comparación de la utilización para NCS de tres de los protocolos más
utilizados: Ethernet, ControlNet y DeviceNet (CAN). Se realizan dos casos de

24
Capítulo 2 SISTEMAS DE CONTROL EN RED
simulación en distintas condiciones donde para cada protocolo se hace un análisis de
eficiencia de la red, utilización y tiempo de retraso en transmisión. El estudio se hace
considerando que las características principales de un protocolo para control es la
comunicación de pequeños paquetes de datos periódicos requiriendo garantía de
transmisión y tiempo de retraso acotado. Los resultados indican que DeviceNet presenta
el mejor desempeño para el caso de sistemas de control con mensajes cortos y basados
en prioridad. Por su parte, ControlNet, dado el determinismo en su transmisión, se hace
atractivo para situaciones donde los tiempos son críticos. Por último, los autores de [4]
concluyen que Ethernet resulta adecuado en el caso de transmisión de grandes
cantidades de datos, por lo que no lo recomiendan para el diseño de NCSs.

[8] presenta un compendio de 12 artículos que se divide en tres partes: estado del arte de
la tecnología de NCSs, fundamentos de los sistemas de control en tiempo real y en red,
y el estatus de las redes inalámbricas en este campo. [2] es uno de los artículos de [8] en
el que se trata el influjo que los NCSs están teniendo en los procesos de manufactura. Se
señala que en los últimos cinco años la tendencia es a tener redes en todos los niveles.
Asimismo se menciona que los parámetros que afectan al QoS de una red son el ancho
de banda y velocidad, el retraso de transmisión y jitter, la confiabilidad de los datos y la
seguridad. Se hace una descripción de las características de los protocolos más
utilizados y se señala que Ethernet, a pesar de no ser un protocolo recomendado para
control, se está adoptando como tal debido a la tendencia a tener dicho protocolo en
todos los niveles: redes para control, para diagnosis y para seguridad. Por último [2]
concluye que, ya que en los últimos años se han logrado grandes avances en las redes
inalámbricas, el futuro en los procesos de manufactura está en incorporar dichas redes.
Señala que entre las diversas ventajas que ello supone, las más claras son la reducción
del cableado y la posibilidad de colocar sensores en posiciones difíciles y en partes
móviles. Sin embargo, cree que no todo será inalámbrico debido a las necesidades de
transmisión de potencia que regularmente existen en dichos procesos.

[9] es un estudio del desempeño del protocolo CAN en una aplicación automotriz,
específicamente en autobuses. Como plataforma experimental se modela una red CAN
con 10 ECUs. El modelo de la red sigue un esquema de diagrama de estados en donde
se simula la capa física, las subcapas de transferencia y objeto, de acuerdo a la

25
Capítulo 2 SISTEMAS DE CONTROL EN RED
especificación del protocolo, [10]. Cada uno de los ECUs tiene diferente prioridad,
todas las tramas son de 8 bytes y la velocidad del bus es de 250 kbit/s. El desempeño de
la red se evalúa a partir de tres parámetros: tiempo de transmisión, carga de la red y
repeticiones de mensaje (i.e. número de veces que se tiene que retransmitir una trama
debido a errores). Para las condiciones presentadas, el tiempo de retraso máximo
encontrado es de 2.5 ms, valor que [9] señala como menor al recomendado por la
especificación SAE J1939, lo que supone que CAN cumple con los requerimientos para
control en tiempo real. Por último, [9] menciona como trabajo a futuro el modelado y
análisis del desempeño de un sistema multiredes ya que normalmente los vehículos
tienen más de una red.

Un método para reducir el jitter en los tiempos de retraso de transmisión en CAN es el
que presenta [11]. Este procedimiento se basa en la manipulación de la trama y lo que se
busca es reducir los bits de stuffing (i.e. en CAN cuando 6 o más bits consecutivos
tienen el mismo nivel lógico, se añade un bit delotro nivel lógico cada 5 bits). Para ello
se plantean dos pasos: eliminación de aquellos identificadores que provoquen bits de
stuffing; y un método de manipulación del campo de datos a partir de operaciones XOR.
[11] hace un análisis en una aplicación de manufactura en la que a partir de la reducción
de dichos bits, se reduce el retraso de transmisión y el jitter.

[12] es un estudio relacionado con [11] en donde se busca minimizar el jitter utilizando
algoritmos genéticos. El método propuesto se aplica a protocolos que utilicen técnicas
de multiplexaje por división en el tiempo y los experimentos se llevan acabo en
TTCAN. Se plantea como problema de optimización, reducir el jitter global del sistema
al variar las fases iniciales (i.e. tiempo en que inicia la transmisión) de cada una de las
tramas. Los alelos de cada elemento de la población contienen todas las fases iniciales
en una codificación por entero (no codificación binaria). Se utiliza el cruce de un punto
con probabilidad del 100% y el operador de mutación con probabilidad del 3%. Los
experimentos se llevan acabo en casos de estudio automotrices obteniendo resultados
satisfactorios. Las desventajas del método propuesto por este estudio radican en que
sólo es aplicable en redes con protocolo basado en TDM y en el enorme cómputo que se
debe llevar acabo.

26
Capítulo 2 SISTEMAS DE CONTROL EN RED
Los retos a futuro en esta área recaen en la búsqueda de algoritmos que optimicen el uso
de la red buscando mejorar el QoS, como los estudios [11] y [12]. Ello supone tomar los
protocolos de red ya existentes y proponer diferentes topologías y otros mecanismos de
agenda de transmisión de mensaje (scheduling), [7].

2.5.2 Estado del arte en el diseño de controladores digitales para NCS

En el diseño de controladores para NCSs, los retrasos son de mucha importancia,
incluso más que la precisión del dato que se transmite ya que la robustez de los
controladores permite ese tipo de imprecisiones. El retraso afecta directamente al QoP y
en el caso más crítico puede causar la inestabilidad [7]. La investigación en esta área
que se ha realizado hasta el momento comprende el diseño de controladores ante
distintas condiciones del retraso y análisis de estabilidad.

En cuanto al diseño de controladores, existe una amplia variedad en la literatura que ha
atacado el problema en base a los supuestos que se hace sobre el retraso en la
comunicación. Así, [13] y [14] presentan el diseño de un controlador estocástico LQG
óptimo para servosistema y regulador en donde existen diferentes tiempos de retraso. Se
trata de una variante del Predictor de Smith en la que se utiliza un filtro de Kalman
como observador. Además, se asume que el ruido en las mediciones puede estar
correlacionado, así como ser blanco o coloreado. Los resultados que se obtienen son
aceptables pero están sujetos a la alta sensibilidad ante errores en el modelado del
proceso.

[15] utiliza control óptimo estocástico asumiendo que los retrasos son aleatorios y
menores al tiempo de muestreo. [16] utiliza las mismas técnicas de [15] para el caso de
retrasos grandes (i.e. mayores al tiempo de muestreo). Asimismo, [17] usa el operador δ
y técnicas de control estocástico asumiendo retrasos siempre mayores al tiempo de
muestreo. Los resultados de estos tres últimos trabajos son buenos pero tienen el
inconveniente de requerir mucha memoria del controlador, lo que resulta inaceptable en
algunos casos prácticos.

27
Capítulo 2 SISTEMAS DE CONTROL EN RED
Otras técnicas como SMC y diseño de controladores solucionando un set de LMIs han
sido utilizadas por [18] y [19], con resultados satisfactorios en simulación pero no
tomando en cuenta las restricciones del protocolo de red en la práctica.

El análisis de estabilidad de los NCSs se ha hecho utilizando diversas técnicas. Algunos
como [20] han basado su trabajo en los métodos de Lyapunov – Krasovskii. Otros han
asumido el retraso de comunicación como un modelo markoviano y utilizando la teoría
de estabilidad de Lyapunov; tal es el caso de [21] y [22]. Asimismo, se ha utilizado la
técnica de análisis de estabilidad estocástica [23].

[7] señala que la investigación en esta área se ha centrado demasiado en un sistema de
control de lazo simple y su análisis de estabilidad. Remarca que es preciso que se
empiece a trabajar en estudio de diseño de NCSs en ambientes más reales donde
muchos sistemas estén interconectados en una novedosa distribución buscando
objetivos comunes. Además menciona que actualmente se está trabajando en sistemas
donde los actuadores tienen restricciones, en buscar la viabilidad de implementación de
los diversos algoritmos complejos propuestos, en detección de fallas y robustez ante
dichas, en control reconfigurable y en maneras de incrementar los grados de autonomía
en los sistemas de control en red. Todos esos tópicos, [7] los señala como áreas de
oportunidad de investigación.

28
Capítulo 3 CONTROLLER AREA NETWORK
3. Controller Area Network

A mediados de los 80’s del siglo pasado Robert Bosch desarrolló el bus de
comunicación conocido como Controller Area Network (CAN por sus siglas en inglés).
El propósito de su invención era lograr una comunicación multiplexada entre las
diferentes unidades de control del motor (o unidades de control electrónico) de los
carros (ECU por sus siglas en inglés) y así lograr una reducción en el cableado. Su bajo
costo, robustez (i.e. alta tolerancia al ruido) y sus diferentes mecanismos para detección
de errores, lo han convertido en el bus más utilizado por la industria automotriz desde
los 90’s [3]. CAN resultó ser tan atractivo que su aplicación fue más allá del automóvil:
actualmente es muy utilizado como protocolo de control en los procesos de manufactura
y se le encuentra en dispositivos médicos, así como en otros medios de transporte como
barcos, trenes, aviones, camiones y motocicletas, [24].

En el presente capítulo se hace una revisión del bus CAN enfatizando en sus
características y aplicaciones.

3.1 Conceptos Básicos

CAN es un protocolo de comunicación serial del tipo broadcast (i.e. la información es
enviada a todos los nodos) con las siguientes características de acuerdo a [10]:

• Velocidad de transmisión de hasta 1 Mbit/s.
• Prioridad en los mensajes.
• Garantía en los tiempos de latencia (i.e. retrasos).
• Flexibilidad en la configuración.
• Recepción multicast con sincronización de tiempo.
• Sistema tipo multimaestro.
• Detección de errores.
• Retransmisión automática de los mensajes erróneos.
• Distinción entre errores temporales y daños permanentes de los nodos con el
consecuente apagado autónomo de dichos.

29
Capítulo 3 CONTROLLER AREA NETWORK
En la especificación de CAN por Bosch [10] se detalla la estructura de un nodo en base
a una estructura de capas (Figura 3.1). Como puede observarse, solamente se describen
dos de las 7 capas del modelo OSI (Open Systems Interconnection Basic Referente
Model) para un protocolo de comunicación de red. Estas corresponden a las capas física
y la de enlace. Las restantes capas no descritas pueden ser definidas por el diseñador del
sistema o bien utilizando otros protocolos basados en CAN como el KVASER’s CAN
Kingdom, DeviceNet™ de Allen – Bradley y Smart Distributed System™ de
Honeywell, [24].

Figura 3.1. Estructura en capas de un nodo CAN y su relación con el modelo OSI.

La especificación de CAN solamente describe totalmente la subcapa de Transferencia y
su efecto en las capas que la rodean. Con respecto a la capa física, únicamente se define

30
Capítulo 3 CONTROLLER AREA NETWORK
la forma en la que las señales son transmitidas, dejando las especificaciones de niveles
de señal y medio de transmisiónpara el diseñador del sistema.

De las diferentes características de CAN vale la pena resaltar la referente a la
flexibilidad en la configuración del sistema. Esto porque se pueden agregar o quitar
nodos sin necesidad de cambiar el software o hardware de los otros nodos. Ello es
posible debido a que un nodo CAN, dada su característica de multicast, no hace uso
alguno de información acerca de la estructura del sistema. Los mensajes entonces no
son enviados a un destinatario específico, sino más bien se etiquetan con un
identificador (ver sección 3.2) que representa el contenido del mensaje y no una
dirección. En consecuencia, todos los nodos reciben todas las tramas enviadas y
depende de un filtrado de mensajes la información a utilizar por la capa de Aplicación.

3.2 La Trama CAN

Existen dos versiones del protocolo CAN: CAN estándar o CAN 2.0A, y CAN
extendido o CAN 2.0B. La diferencia entre ambos radica en el número de bits utilizados
para el campo del identificador de la trama; 11 para el estándar y 29 para el extendido.
La figura 3.2 muestra la estructura de una trama del CAN estándar, mientras que la
figura 3.3 muestra la de CAN extendido.

Figura 3.2 Estructura de una trama CAN estándar.

Figura 3.3 Estructura de una trama CAN extendido

31
Capítulo 3 CONTROLLER AREA NETWORK
La descripción de cada una de las partes constitutivas de las anteriores estructuras se
presenta en el apéndice A.

Como se puede notar, la estructura de una trama CAN extendido es similar a la de CAN
estándar con la diferencia de que ahora el identificador consta de 29 bits (i.e. mayor
número de identificadores; 229). Estos 29 bits se distribuyen en dos campos: un campo
base de 11 bits, similar al CAN extendido y para hacerlos compatibles, y un campo
extra de 18 bits.

3.3 Tipos de tramas:

Existen cuatro tipos de tramas dentro del bus CAN, [10]:

• Trama de datos (data frame): Se trata del tipo de trama más común y su uso es para
intercambiar información entre los diferentes nodos. En este tipo de trama, el bit
RTR (ver sección 3.2) debe tener valor dominante, es decir un “0” lógico.

• Trama de solicitud (request frame): Se trata de una trama utilizada para solicitar el
envío de información de un identificador específico. De este modo, para
diferenciarse de la trama de dato, el bit RTR debe tener valor recesivo o bien “1”
lógico. Además, en el campo de dato no hay información y se envía como
identificador el valor de aquel del que precisamente se requiere información.

• Trama de error (error frame): Corresponde a un tipo especial de trama que no sigue
el formato presentado en la anterior sección y que es enviada por cualquier nodo al
detectar un error en el mensaje previamente enviado. Funciona de tal modo que al
iniciarse el envío de la trama por parte de un nodo específico, los otros contestan y
contribuyen a formarla. De esta forma, esta trama está compuesta por dos partes: las
banderas de error y el delimitador del error. La primera está constituida por 6 bits
del mismo valor, mientras que la segunda, por 8 bits recesivos.

• Trama de sobrecarga (overload frame): Esta trama es enviada por cualquier nodo
para provocar un retraso en el envío de tramas de tipo dato o solicitud. De esta

32
Capítulo 3 CONTROLLER AREA NETWORK
forma, cuando un nodo se considera “muy ocupado” y necesita tiempo, es cuando
este tipo de trama es utilizado. Su formato es similar al de una trama de error.

3.4 Proceso de Arbitraje

Antes de explicar el proceso de arbitraje que se sigue dentro del bus CAN, es preciso
mencionar que este protocolo utiliza una codificación de bit de no – retorno a cero
(NRZ). Asimismo los bits considerados dominantes son aquellos de valor “0” lógico;
mientras que los recesivos son los “1” lógico.

CAN utiliza un esquema de CSMA/CD + AMP (i.e. carrier – sense multiple – access
con detección de colisión y arbitraje en la prioridad del mensaje). Esto significa
entonces que cada nodo debe esperar un determinado período de inactividad del bus
para intentar enviar un mensaje y que las colisiones se resuelven a partir de un método
de arbitraje bit a bit (i.e. AND alambrado) basado en prioridad. Esta prioridad se
localiza en el identificador del mensaje (ver sección 3.2) y funciona del siguiente modo:
cuando dos nodos compiten por el uso del bus, son los bits dominantes los que
prevalecen, de modo que si un nodo detecta que no ha ganado el proceso de arbitraje,
deja de transmitir y se espera hasta que se de cuenta que el bus se encuentra desocupado
para intentar enviar de nuevo su trama. Un ejemplo de este proceso se ilustra en el
apéndice A.

A partir de lo descrito anteriormente, se puede deducir entonces que la prioridad va en
orden decreciente conforme crece el valor del identificador. En otras palabras, los
identificadores de menor valor son los de mayor prioridad.

3.5 Manejo de los errores

Existen 5 tipos de errores que pueden ser detectados por la subcapa Transferencia del
protocolo CAN [10]: error de bit, de stuffing, de CRC, de forma y de Acknowledgment,
apéndice A. Existe un tipo especial de trama cuando se produce cualquiera de los
errores mencionados. Esta trama de error se genera de la siguiente forma: cuando
cualquiera de los nodos conectados a la red detecta una condición que viole el protocolo

33
Capítulo 3 CONTROLLER AREA NETWORK
CAN, envía una bandera de error que es contestada por todos los demás nodos. De este
modo, la trama es construida por todos.

El protocolo CAN especifica además un tipo especial de confinamiento de errores [10].
Se trata de un sistema en el cual los nodos dentro de la red van distinguiendo entre fallas
permanentes y parciales. Cada nodo posee un contador de errores que es incrementado
gradualmente conforme se van detectando violaciones. De esta forma, si un nodo, a
partir del valor de dicho contador, considera que se encuentra en estado permanente de
falla, decide desconectarse del sistema.

3.6 Consideraciones de la capa física

La capa física del protocolo CAN se encuentra especificada en el estándar ISO 11898.
En dicho estándar se establece el uso de par trenzado como medio de comunicación, lo
que supone dos líneas: CANH y CANL. El uso de este tipo de cable trae como
consecuencia robustez ante la incidencia de campos electromagnéticos y señales
parásitas ya que las dos líneas se encuentran en oposición de fase y lo que se mide es la
diferencia de voltaje entre dichas. De [10] se sabe que CAN especifica dos estados
lógicos: dominante (“0” lógico) y recesivo (“1” lógico). ISO 11898 establece entonces
la diferencia de tensión que debe existir entre las dos líneas para representar dichos
estados, figura 3.4, [25].

Figura 3.4 Niveles de Voltaje Nominales de bus establecidos por ISO 11898 [25]

34
Capítulo 3 CONTROLLER AREA NETWORK
Asimismo, el ISO 11898 especifica la topología de bus como la propia de la red CAN.
Se establece además el uso de dos resistencias de terminación de 120 Ω para mantener
la tensión en el circuito del bus. De esta forma, la figura 3.5 muestra la configuración
común que se puede encontrar de una red CAN tal como especifica el estándar
mencionado.

Figura 3.5 Configuración de bus de la red CAN especificada por ISO 11898

3.7 CAN y su aplicación en los automóviles

Debido a las diferentes operaciones con diferentes requerimientos que llevan acabo los
ECUs, existe más de una red de comunicación dentro de los carros. De acuerdo a [3], el
sistema dentro de un vehículo puede dividirse en varios dominios: powertrain, chasis,
cuerpo, telematics y seguridad.

El dominio powertrain supone principalmente el control del motor y la transmisión. Por
su parte, el dominio chasis se refiere al control de suspensión, manejo y frenado,lo que
conjunta las funciones de ABS, ESP, ASC (i.e. Automatic Stability Control), 4WD (i.e.
4 Wheel Drive). Debido a que todas estas operaciones implican un alto desempeño de
los diferentes sistemas de control, estos dominios se implementan en una red CAN de
alta velocidad (i.e. 500 kbit/s a 1 Mbit/s).

El dominio del cuerpo reúne todo lo referente al confort como vidrios, luces, tablero de
instrumentos, asientos y aire acondicionado. El dominio telematics conjunta las
diferentes funciones de multimedia (e.g. CD, DVD) y comunicación inalámbrica (e.g.
GPS, teléfono móvil). Estos dos dominios, debido a sus características se pueden

35
Capítulo 3 CONTROLLER AREA NETWORK
encontrar implementados en redes de baja velocidad (e.g. CANLS de 125 kbit/s,
MOST). Asimismo, algunas funciones pueden implementarse con otros tipos de redes
de bajo costo como LIN (i.e. Local Interconnect Network) ya que no requieren de una
red tan robusta como CAN, por lo que es común encontrar subredes.

Figura 3.6 CAN y su aplicación en los automóviles [26]

36
Capítulo 3 CONTROLLER AREA NETWORK
Por último, el dominio referente a seguridad incluye diferentes funciones como el
control de las bolsas de aire, monitoreo de la presión de las llantas y ACC (i.e. Adaptive
Cruise Control).

La figura 3.6 muestra un ejemplo de las diferentes funciones que llevan acabo los ECUs
dentro del automóvil y que se distribuyen en varias redes [26].

37
Capítulo 4 PLATAFORMA EXPERIMENTAL
4. Plataforma Experimental

A partir del esquema general de un sistema de control en red (ver figura 2.1), se diseñó
e implementó una plataforma experimental que permitiera evaluar el desempeño de un
controlador en un ambiente de red. El presente capítulo hace una descripción detallada
de dicha plataforma dividiéndola en dos partes: hardware y software.

4.1 Hardware

4.1.1 Descripción General

El esquema general de la plataforma experimental se detalla en la figura 4.1. Es un
sistema de control en red en donde el proceso y el controlador se encuentran ubicados
en dos nodos distintos y se comunican entre sí por medio del protocolo CAN

Figura 4.1 Esquema general de la plataforma experimental

Para poder evaluar el desempeño del controlador ante distintas condiciones (i.e. carga
de la red, velocidad de transmisión, prioridad), se conectó el proceso y el controlador a
un ambiente de red real. Este ambiente corresponde al de un automóvil y se representa
en la maqueta FULL CAN X3. Sin embargo, la carga de red que se induce por la
adición de dicha maqueta resulta de valor constante y muy pequeño (i.e. 10% en baja

38
Capítulo 4 PLATAFORMA EXPERIMENTAL
velocidad, 14% en alta). Por esta razón y para poder variar dicho parámetro, se agregó a
la red un generador de carga; tal como muestra la figura.

4.1.2 Nodo CAN

En la figura 4.1 se puede notar la implementación de tres nodos de red CAN: el
correspondiente al proceso, el del controlador y el del generador de carga. La
implementación de cada uno de ellos se llevó acabo de acuerdo a la figura 4.2. Cada
nodo consta de una computadora y una tarjeta de comunicación USB MUX 4C2L.

Figura 4.2 Implementación de un nodo CAN

El esquema de funcionamiento de este nodo es el siguiente: la computadora, según sea
su caso (i.e. proceso, controlador o generador de carga), recibe y envía información a la
red CAN a través de la tarjeta de comunicación USB MUX 4C2L.

Otra opción de implementación pudo haber sido utilizar un microcontrolador con puerto
CAN (i.e. con un módulo de comunicación para este protocolo). Sin embargo, se optó
por la opción de la figura 4.2 dadas las facilidades de interfase visual con el usuario que
una computadora puede tener.

39
Capítulo 4 PLATAFORMA EXPERIMENTAL
4.1.3 Tarjeta de comunicación USB MUX 4C2L

La figura 4.2 muestra a la tarjeta USB MUX 4C2L como un elemento de cada uno de
los nodos CAN implementados. Básicamente se trata de un periférico que permite a una
PC conectarse a la red CAN high speed, CAN low speed / fault tolerant, CAN single
wire y LIN. Sus vistas frontal y posterior se muestran en la figura 4.3.

Figura 4.3 Vista frontal y posterior de la tarjeta USB MUX 4C2L [27]

De [27] se sabe que esta tarjeta dispone de las siguientes conexiones:

• 1 conexión CAN high speed (Norma ISO 11898) ó 1 conexión CAN low speed fault
tolerant. La elección de esta conexión se hace por software.
• 1 conexión CAN high speed.
• 1 conexión CAN low speed.
• 1 conexión CAN low speed ó 1 conexión CAN single wire.
• 2 conexiones LIN / ISO9141.

La tarjeta dispone de 4 conexiones CAN y 2 LIN. La comunicación entre la tarjeta y la
computadora se realiza por USB. (De estos dos datos viene el acrónimo USB MUX
4C2L).

4.1.4 Maqueta Full CAN X3

Esta investigación se realizó en una maqueta didáctica Full CAN X3 de la marca
Exxotest, [28]. Es un prototipo con componentes reales de un automóvil Peugeot 807 e
integra 3 tipos de redes CAN. Cuenta con doce módulos: Interfase de sistema (Built – In
System Interface, BSI), módulo de fuente de poder (Built – In Supply Module, BSM),

40
Capítulo 4 PLATAFORMA EXPERIMENTAL
aire acondicionado, puerta de conductor, puerta de pasajero, luces frontales, luces
traseras, tablero de instrumentos, radio, módulo AFIL (i.e. sistema de alarma para salida
del camino), módulo de remolque y alarma.

Figura 4.4 Distribución por redes de los distintos módulos de la maqueta Full CAN X3

Los módulos de la maqueta se encuentran distribuidos en tres redes CAN: una red
intersistema, cuya velocidad es de 500 kbit/s (i.e. CAN high speed); una red de chasis y
una de confort, ambas de 125 kbit/s (i.e. CAN low speed). La figura 4.4 muestra la
distribución de los distintos módulos de la maqueta en las tres redes mencionadas. Por
su parte las figuras 4.5 – 4.7 presentan diferentes vistas de la maqueta en cuestión.

41
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.5 Vista lateral izquierda de la maqueta Full CAN X3

Figura 4.6 Vista lateral derecha de la maqueta Full CAN X3

42
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.7 Vista frontal de la maqueta Full CAN X3

El módulo BSI (i.e. Built – In System Interface) cuenta con diferentes conexiones tipo
banana hembra para cada una de las tres redes CAN de la maqueta. Agregar nodos a la
maqueta resulta sencillo, pues basta con conectarse a las conexiones banana de la red
CAN deseada:

• CAN1HS: red intersistema con velocidad de transmisión de 500 kbit/s.
• CAN2LS: red de chasis con velocidad de transmisión de 125 kbit/s.
• CAN3LS: red de confort con velocidad de transmisión de 125 kbit/s.

Para lograr la conexión de la figura 4.1 es necesario que los tres nodos estén conectados
a la misma red CAN.

43
Capítulo 4 PLATAFORMA EXPERIMENTAL
4.2 Software

Para cada uno de los tres nodos CAN se desarrolló el software necesario para cumplir
con las funciones correspondientes.

4.2.1 Programa base de cada nodo CAN

El software se desarrolló en LabWindows CVI 7.0 de National Instruments™. Se partió
de un programa base proporcionado por el personal de Exxotest. Uno de dichos
productos es un paquete de librerías para programas basados en C que permiten la
conexión con las tarjetas de comunicación de redes multiplexadas (e.g. USB MUX
4C2L). El esquema para el desarrollo de una aplicación de PC desarrollada en C (e.g.
LabWindows CVI) que se comunique con una tarjeta y así a un protocolo de
comunicación multiplexado (e.g. CAN) es el mostrado en la figura 4.8, [29].

Figura 4.8 Esquema para el desarrollo de una aplicación de PC capaz de conectarsea una red multiplexada [29]

Se trata de un programa que permite la conexión a 4 tipos de redes CAN, una a la vez y
seleccionando la velocidad correspondiente. El resultado es una aplicación de monitoreo
de la red seleccionada donde se pueden observar todas las tramas que viajan en el bus.

El software mencionado está formado por tres archivos (*.c) y sus correspondientes
(*.h): MuxCom.c, Thread.c, y WinMain.c; así como el archivo de interfase de usuario
WinMain.uir. De los archivos mencionados los únicos que se modificaron para el
desarrollo de cada uno de los tres nodos CAN de la plataforma experimental son el
WinMain.c y el WinMain.uir.

44
Capítulo 4 PLATAFORMA EXPERIMENTAL
Los archivos MuxCom.c y Thread.c son código fuente necesarios para establecer la
comunicación con la tarjeta de red y quedaron sin cambios para los tres nodos CAN.

Figura 4.9 Diagrama de flujo común para el código fuente de cada nodo CAN

La figura 4.9 muestra el diagrama de flujo común del código fuente de cada nodo CAN.
El proceso de cada nodo pasa primero por una rutina de inicialización que es diferente
para cada uno. Después se abre el canal de comunicación y mientras esté abierto, se
realizan las rutinas de proceso así como de comunicación a través de CAN. Para dar por
terminada la aplicación, se cierra el canal.

4.2.2 Nodo Proceso

Este nodo emula el bloque actuador – proceso – sensor de un sistema de control en red
(ver figura 2.1). Se trata de un bloque que recibe como entrada la señal de manipulación
del controlador y envía como salida, en cada tiempo de muestreo, el valor actual de las
variables de estado.

45
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.10 Diagrama de entradas y salidas del nodo Proceso

El diagrama de flujo del funcionamiento de este nodo es el mostrado en la figura 4.9. De
este modo, los siguientes apartados detallan cada uno de los bloques de dicho diagrama.

Inicialización:

La figura 4.11 muestra la pantalla inicial de este nodo. La rutina de inicialización
consiste en dos operaciones:

• Establecimiento de parámetros de comunicación: Mediante esta operación, el
usuario establece el valor de las distintas variables referentes a la comunicación a
través de CAN. La primera de ellas consiste en establecer la tarjeta de comunicación
a utilizar. Esto se logra al presionar el botón “INIT” (marcado como B) de tal forma
que la aplicación reconoce el dispositivo conectado al puerto USB de la PC y coloca
su acrónimo (e.g. USB MUX 4C2L) en el campo de “Available devices” (marcado
como A).

Una vez que se ha establecido la tarjeta de red a utilizar, se especifica la red CAN a
accesar, así como su velocidad (i.e. CAN 1 – 500 kbit/s, CAN 2 – 125 kbit/s, CAN 3 –
125 kbit/s). Esto se logra en los campos marcados como C en la figura 4.11.

El último paso de esta rutina de inicialización trata del establecimiento de los
identificadores de las tramas a utilizar para el desarrollo de la comunicación, tanto para
enviar datos (i.e. al controlador) como para recibirlos (i.e. del controlador). Este paso se
efectúa al presionar el botón “Identifiers” (marcado como D) que lleva a la pantalla de
la figura 4.12.

46
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.11 Portada principal del nodo Proceso

Figura 4.12 Panel de pantalla para el establecimiento de los identificadores de las tramas

47
Capítulo 4 PLATAFORMA EXPERIMENTAL
Para establecer los identificadores a utilizar en la transmisión de datos hay que recordar
que la salida del nodo Proceso es el vector de variables de estado (figura 4.10). Es
importante mencionar que una trama CAN puede transmitir dos valores de punto
flotante a lo mucho. La razón de ello se explica en el apartado 5 de esta sección. Por
cada dos variables de estado se tiene una trama CAN por enviar y un identificador. De
este modo, en el campo “No. de X” (marcado como A en la figura 4.12) se establece el
número de variables de estado del sistema con lo que en la tabla denotada como
“Identifiers:transmitter” se colocan los identificadores a utilizar (e.g. si se tratara de 4
variables de estado, se utilizarían dos identificadores).

El número de identificadores a utilizar para recibir datos viene dado por el número de
variables de manipulación. Tal como en el caso anterior, por cada dos de estas variables,
se tiene un identificador. El número de variables de manipulación se establece en el
campo “No. de U” (marcado como B) y los identificadores a utilizar en la tabla
“Identifiers: receiver”.

Los identificadores a utilizar se relacionan directamente con la prioridad. Tal como se
mencionó en el capítulo 3 en el protocolo CAN la prioridad de los mensajes viene dada
por el valor del identificador: entre menor sea su valor, mayor será la prioridad. De tal
forma que el usuario establece los identificadores teniendo en cuenta la prioridad que le
desee dar a sus mensajes. Para ello en la List Box “Identifiers in the nerwork” (marcada
como C), al momento de correr la aplicación, se presentan los identificadores existentes
en la red previamente seleccionada (e.g. CAN1HS). Dichos valores se presentan de
menor a mayor, lo que implica prioridad de mayor a menor.

En la figura 4.12 en el campo “Network Load” (marcado como D), al momento de
correr la aplicación, se muestra el valor de la carga de la red a la que se esté accediendo.
Este dato es importante pues es una de las variables a modificar para el desarrollo de las
pruebas experimentales.

48
Capítulo 4 PLATAFORMA EXPERIMENTAL
el panel de pantalla de la figura 4.13. Se trata de un sistema de espacio de estado
discreto dado por:

x(k + 1) = G x (k) + H u (k) + F w (k) (4.1)
y(k) = C x (k) + D u (k) (4.2)

donde:

x (k): vector de estado de dimensión n.
y (k): vector de salida de dimensión m.
u (k): vector de entrada de dimensión r.
w(k): escalar que representa la perturbación.
G: matriz de dimensión n x n.
H: matriz de dimensión n x r.
F: vector de dimensión n.
C: matriz de dimensión m x n.
D: matriz de dimensión m x r.

Figura 4.13 Panel de pantalla para el establecimiento del modelo del proceso

49
Capítulo 4 PLATAFORMA EXPERIMENTAL
De esta forma, el usuario establece las dimensiones de los vectores y matrices a partir de
los campos numéricos “No. de X” (dimensión n), “No. de U” (dimensión r) y “No. de
Y” (dimensión m) de la figura 4.13 (marcados como A). Por otro lado, los valores de
cada uno de los elementos de las matrices G, H, C, D y F se especifican en las
correspondientes tablas del mismo nombre de la figura.

Ahora bien, la estrategia de control que se utiliza en este estudio es la de control óptimo
cuadrático para un regulador en donde el vector de entrada está dada por:

u (k) = -K x (k) (4.3)

y donde se busca minimizar el índice de desempeño dado por:

[ ]∑
∞
=
+=
0
(k)(k)(k)(k)
2
1
k
** RuuQxxJ (4.4)

donde

Q: matriz Hermítica (o matriz real simétrica) definida positiva o semidefinida positiva
de dimensión n x n.
R: matriz Hermítica (o matriz real simétrica) definida positiva de dimensión r x r.

El resultado de dicha minimización es [30]:

( ) PGHPHHRK ** -1+= (4.5)

donde P es la solución de la ecuación de Riccati:

( ) PGHPHHRPHGPGGQP *** *1- −++= (4.6)

En la aplicación desarrollada, el usuario tiene la opción de ingresar manualmente los
valores de la matriz de ganancia K o bien puede pedir al programa que resuelva las

50
Capítulo 4 PLATAFORMAEXPERIMENTAL
ecuaciones (4.5) y (4.6) al pulsar el botón “LQ DESIGN” de la figura 4.13 (marcado
como C). Los valores de los elementos de Q y R se establecen en las tablas del mismo
nombre.

Para resolver la ecuación de Ricatti (ecuación 4.6) se sigue un método de solución
iterativa que se muestra en el diagrama de la figura 4.14, [30]. Este procedimiento
plantea la ecuación (4.6) como una ecuación de diferencias, es decir:

( ) GPHHPHRHPGGPGQP *** (k)(k)(k)-(k)1)(k *1−++=+ (4.7)

Figura 4.14 Diagrama de flujo para la solución iterativa de la ecuación de Riccati

51
Capítulo 4 PLATAFORMA EXPERIMENTAL
Se empieza con un valor inicial de P = 0 (i.e. todos los elementos de la matriz P son
cero) y se evalúa la ecuación (4.7) por 20 iteraciones. Luego se observa si los elementos
de la última matriz P no han cambiado con respecto a los elementos de la penúltima
matriz P. De no ser así, se vuelve a evaluar por 20 iteraciones hasta que se cumpla dicha
condición, lo que supone que P ha alcanzado el estado estable. Es este último valor de P
la solución de la ecuación de Riccati. Posteriormente se calcula K a partir de la ecuación
(4.5).

Por último, el usuario debe especificar, como parámetro de proceso, el valor del tiempo
de muestreo a utilizar. Este se establece en el campo “Sampling Time” (marcado como
B en la figura 4.13).

Abrir comunicación:

El siguiente paso en el diagrama de la figura 4.9 es abrir la comunicación. Esto se hace
al pulsar el botón “OPEN” de la figura 4.11 (marcado como E) lo que provoca que se
despliegue el panel de pantalla de la figura 4.15. A partir de dicho momento, la
aplicación se encuentra conectada al bus CAN y es capaz de recibir y enviar
información.

Figura 4.15 Panel de pantalla de monitoreo del proceso en el nodo Proceso

52
Capítulo 4 PLATAFORMA EXPERIMENTAL
Rutinas de Proceso – Rutinas CAN:

Siguiendo el diagrama de la figura 4.9, una vez que se haya abierto el canal de
comunicación la aplicación empieza a ejecutar las distintas rutinas de proceso y de
CAN. Se mantendrá en dicho estado hasta que el usuario decida cerrar el canal. La
figura 4.16 muestra el diagrama de flujo de las rutinas de proceso (lado izquierdo) y las
de CAN (lado derecho) del nodo Proceso. El modo en el que están colocados los dos
diagramas atiende al hecho de que se trata de dos tipos de operaciones que se realizan
en paralelo.

Figura 4.16 Diagrama de flujo de las operaciones de proceso y CAN en el nodo Proceso

En cuanto a las rutinas de proceso, este nodo se encarga de simular un proceso de
acuerdo a las ecuaciones 4.1 y 4.2 cuyos parámetros fueron especificados (i.e. en la
etapa de inicialización). De este modo, cada tiempo de muestreo, se realizan tres
operaciones básicas:

• Cálculo de los valores actuales de x(k) y y(k) de acuerdo a las ecuaciones (4.1) y
(4.2).
• Se grafica x(k), y(k) y u(k) en las pantallas correspondientes de la figura 4.15.

53
Capítulo 4 PLATAFORMA EXPERIMENTAL
• Se envía el valor de x(k) a través de CAN y utilizando los identificadores
especificados en la etapa de inicialización.

En las rutinas de CAN, cada vez que se recibe una trama del bus al que se está
conectado sucede lo siguiente: si el identificador de la trama que se recibió pasa por el
filtro (i.e. tiene el mismo valor que el especificado como identificador de recepción en
la etapa de inicialización), entonces se ha recibido el nuevo valor de u(k), por lo que se
actualiza dicho dato. El utilizar un filtro de recepción permite hacer más eficiente la
aplicación desde el punto de vista de cómputo, pues dicho filtro se aplica directamente
en la tarjeta USB MUX 4C2L, lo que implica que ésta interrumpe a la aplicación
solamente en caso de haber recibido un dato que interese (i.e. que haya pasado el filtro).
Cabe destacar que dichas tramas que la aplicación recibe se van mostrando en el campo
“CAN Frames” de la figura 4.15 (marcado como C).

Tal como muestra la figura 4.15, la aplicación desarrollada no sólo trabaja en tiempo
real, sino además permite que se trabaje en modo simulación (campo A). Esto resulta
útil para comprobar el funcionamiento del sistema completo y se activa al pulsar el
botón “SIMULATION” de la figura 4.11 (marcado como F). Otra de las características
del programa, es que permite trabajar tanto en modo automático, como en modo
manual. Ello se elige en la manija marcada como B de la figura 4.15.

El usuario tiene la opción de ingresar perturbaciones tipo escalón a través del numérico
“Disturbance” (marcado como D).

Cerrar comunicación:

El nodo se desconecta del bus CAN a partir de que el usuario pulse el botón “CLOSE”
de la figura 4.15 (marcado como F). Éste es el último paso del diagrama de flujo
presentado en la figura 4.9 e implica que el nodo Controlador deja de recibir valores de
entrada (i.e. el valor actual de las variables de estado).

54
Capítulo 4 PLATAFORMA EXPERIMENTAL
4.2.3 Nodo Controlador

Este nodo implementa el bloque controlador de un sistema de control en red (ver figura
2.1). Es un bloque que recibe como entrada el valor actual de las variables de estado y
envía como salida la señal de manipulación.

Figura 4.17 Diagrama de entradas y salidas del nodo Controlador

El diagrama de flujo del funcionamiento de este nodo es el mostrado en la figura 4.1. De
este modo, los siguientes apartados detallan cada uno de los bloques de dicho diagrama.

Inicialización:

La figura 4.18 muestra el panel de pantalla que aparece al momento de iniciar la
aplicación de este nodo. La rutina de inicialización consiste en dos operaciones:

• Establecimiento de parámetros de comunicación: Mediante esta operación, el
usuario establece el valor de las distintas variables referentes a la comunicación a
través de CAN. La primera de ellas consiste en establecer la tarjeta de comunicación
a utilizar. Esto se logra al presionar el botón “INIT” (marcado como B en la figura
4.18) de tal forma que la aplicación reconoce el dispositivo conectado al puerto USB
de la PC y coloca su acrónimo (e.g. USB MUX 4C2L) en el campo de “Available
devices” (marcado como A).

Una vez que se ha establecido la tarjeta de red a utilizar, el siguiente paso consiste en
especificar la red CAN a la que se accederá, así como su correspondiente velocidad (i.e.
CAN 1 – 500 kbit/s, CAN 2 – 125 kbit/s, CAN 3 – 125 kbit/s). Esto se logra en los
correspondientes campos marcados como C en la figura.

55
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.18 Portada principal del nodo Controlador

El último paso de esta rutina de inicialización trata del establecimiento de los
identificadores de las tramas a utilizar para el desarrollo de la comunicación, tanto para
enviar datos (i.e. al nodo Proceso) como para recibirlos (i.e. del nodo Proceso). Este
paso se efectúa al presionar el botón “Identifiers” (marcado como D) y despliega el
mismo panel de pantalla de la figura 4.12.

• Establecimiento de los parámetros del proceso: Mediante esta operación el usuario
especifica el modelo del proceso a controlar. Este procedimiento se realiza al pulsar
el botón “PROCESS MODEL” de la figura 4.18 (marcado como F), y se despliega
el panel de pantalla de la figura 4.19. Tal como se mencionó en el apartado
correspondiente al nodo Proceso, se trata de un sistema en espacio de estado discreto
definido por las ecuaciones 4.1 y 4.2. De este modo, el usuario especifica el orden
del sistema, número de entradas y salidas, a partir de los numéricos “No. de X”,
“No. de U” y “No. de Y” englobados en la marca A de la figura. Además, los
elementos de cada unas de las matrices G, H, C, D y F se especifican en las tablas
del mismo título.

56
Capítulo 4 PLATAFORMA EXPERIMENTAL

Figura 4.19 Panel de pantalla