Estudio Experimental del QoP del Controlador de un NCS Basado en CAN-Edición Única

(1)

Monterrey, Nuevo León a

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

PRESENTE.-Por medio de la presente hago constar que soy autor y titular de la obra denominada

, en los sucesivo LA OBRA, en virtud de lo cual autorizo a el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO) para que efectúe la divulgación, publicación, comunicación pública, distribución, distribución pública y reproducción, así como la digitalización de la misma, con fines académicos o propios al objeto de EL INSTITUTO, dentro del círculo de la comunidad del Tecnológico de Monterrey.

El Instituto se compromete a respetar en todo momento mi autoría y a otorgarme el crédito correspondiente en todas las actividades mencionadas anteriormente de la obra.

De la misma manera, manifiesto que el contenido académico, literario, la edición y en general cualquier parte de LA OBRA son de mi entera responsabilidad, por lo que deslindo a EL INSTITUTO por cualquier violación a los derechos de autor y/o propiedad intelectual y/o cualquier responsabilidad relacionada con la OBRA que cometa el suscrito frente a terceros.

Nombre y Firma AUTOR (A)

(2)

Estudio Experimental del QoP del Controlador de un NCS

Basado en CAN-Edición Única

Title Estudio Experimental del QoP del Controlador de un NCS Basado en CAN-Edición Única

Authors José Rodrigo Táger Penados

Affiliation ITESM-Campus Monterrey

Issue Date 2007-12-01

Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 10:13:59

(3)

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

(4)

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

(5)

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

(6)

A mis papás: Emilio y Anabella.

A mis hermanos y hermanas: Carlos, Emilio, Pablo,

Alenka y Claudia.

(7)

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

(8)

CONTENIDO

Contenido

Lista de Símbolos……… 8

1. Introducción………... 10

1.1Descripción del problema………... 10

1.2Antecedentes y Justificación………... 11

1.3Objetivos………. 12

1.4Hipótesis de trabajo………. 13

1.5Metodología……… 13

1.6Organización………... 13

2. Sistemas de control en red……… 15

2.1NCS básico……….. 15

2.2Limitantes 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.3La red y su efecto en un NCS………. 20

2.4Redes para control………... 22

2.5La 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.1Conceptos básicos………... 28

3.2La Trama CAN……… 30

3.3Tipos de tramas………... 31

3.4Proceso de Arbitraje……… 32

3.5Manejo de los errores……….. 32

3.6Consideraciones de la capa física……… 33

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

4. Plataforma Experimental………. 37

4.1Hardware………. 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.2Software………... 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

(9)

CONTENIDO

5. Resultados Experimentales……….. 62

5.1Modelo de suspensión activa de un cuarto de vehículo……….. 62

5.2Valores de operación………... 67

5.3Diseño de Experimentos………. 68

5.4Resultados de simulación……… 72

5.5Resultados a baja velocidad (125 kbit/s)………. 74

5.6Resultados a alta velocidad (500 kbit/s)………. 82

5.7Análisis de resultados……….. 83

6. Conclusiones y Trabajos Futuros……… 87

6.1Conclusiones………... 87

6.2Trabajos 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

(10)

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

t Tiempo

T Tiempo de muestreo

Tdelay Tiempo de retraso de transmisión

Tpre Tiempo de preprocesamiento

Twait Tiempo de espera para envío de mensaje

(11)

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

(12)

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.1Descripció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

(13)

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.2Antecedentes 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

(14)

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.3Objetivos

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

(15)

1.4Hipó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.5Metodologí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.6Organización

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

(16)

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

(17)

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 y(t) y u(t)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 y(t) y u(t) 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

(18)

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

(19)

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:

post tx wait pre

delay T T T T

T = + + + (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.

(20)

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

(21)

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

(22)

• 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

(23)

• 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].

(24)

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 punto a 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

(25)

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

(26)

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

(27)

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 del otro 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

(28)

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

(29)

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

(30)

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.

(31)

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

(32)

la forma en la que las señales son transmitidas, dejando las especificaciones de niveles

de señal y medio de transmisión para 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.

(33)

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.

(34)

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

(35)

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

(36)

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.

(37)

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.

(38)

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

(39)

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

(40)

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

(41)

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

(42)

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

(43)

Figura 4.5 Vista lateral izquierda de la maqueta Full CAN X3

(44)

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

(45)

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 conectarse a 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

(46)

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

(47)

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

(48)

Figura 4.11 Portada principal del nodo Proceso

(49)

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.

• 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