EL PROTOCOLO FLEXRAY
Francisco Javier Moreno
Rivas
MK5
N.C. 828815
MK5
N.C. 828815
-Introducción.
1. Capa física
1.1. Arquitectura de un nodo
1.2. Topologías de red.
1.2.1. Topologías básicas
1.2.1.1 Linear passive bus
1.2.1.2 Topologías con Active Stars
1.2.2. Topologías híbridas
1.3. Morfología de datos a nivel
físico
1.3.1. Datos a nivel eléctrico.
1.3.2. Datos a nivel lógico.
1.3.3 Trama física
1.4. Algoritmos Majority Voting y de
Bit Strobing.
1.4.1 Majority Voting
1.4.2. Bit Strobing
1.5. Concepto de Active Star.
1.6. Concepto de Bus Guardian.
2 Capa lógica
2.1. Protocol Operation Control
(POC)
2.1.1 Coding and decoding
2.1.1.1 Channel idle detection
2.1.2. Frame and Symbol Processing
2.1.3. Media Acces Control
2.1.3.1. Unidades de tiempo en
Flexray
2.1.4. Clock Synchronization
2.1.4.1. Clock Synchronization
Process.
2.1.4.2. Macrotick Generation
Process
2.2. Wake Up del Bus Flexray
2.3. Startup del bus Flexray
-Conclusión
-Bibliografía
-Resumen
-Conclusión
-Bibliografía
-Resumen
-Mapa mental
OBJETOVO
El objetivo de este informe es dar a conocer
el funcionamiento, la estructura, ventajas y desventajas de utilizar el
protocolo Flexray. Todo esto nos servirá a personas que nos desarrollamos en el
área automotriz, ya que hoy en dia este protocolo tiene suma importancia en
marcas tan importantes como son Audi, BMW y Volkswagen. Y al paso en que va
creciendo la tecnología es solo cuestión de tiempo par que más marcas comiencen
a utilizar el protocolo ya antes dicho.
INTRODUCCIÓN
FlexRay es
un nuevo protocolo de comunicaciones para buses de datos en el automóvil
actualmente en desarrollo por el consorcio "FlexRay". Se considera
más avanzado que el CAN y el MOST en lo relativo al precio y a las
prestaciones.
El BMW X5 fue el primer coche del mercado en aplicar el
sistema FlexRay. El FlexRay es un nuevo estándar para la transmisión de datos
de forma eficiente, rápida y segura. El X5 hace uso de este estándar para la
transmisión de datos entre una centralita central y 4 centralitas satélites
colocadas en los amortiguadores. Con este sistema se permite una reacción y equilibrio
extremadamente rápido a baches o agujeros en el camino. La tecnología FlexRay
se esta asentando en la industria del autómovil (BMW, Audi, Volkswagen).
1. Capa física
En este
apartado vamos a describir los puntos más importantes y relevantes de la capa
física del protocolo Flexray.
1.1. Arquitectura de un nodo
Un nodo
Flexray está formado esencialmente por un microcontrolador, un periférico
llamado Communication Controller, 2 transceivers y una fuente de alimentación.
El
microcontrolador es el propio de la ECU, el cual seguramente realiza otras
funciones externas propias de la ECU y que cada cierto tiempo envía y recibe
una trama de información al bus Flexray. Para ello se comunica con el
Communication Controller (CC), que no es más que un periférico hardware que
gestiona en todo momento el protocolo. Es decir, el microcontrolador no se
encarga de la pila del protocolo, si no que lo gestiona todo el CC.
Así pues,
el CC se comunica a su vez con los transceivers que se encargan de transformar
los datos lógicos a niveles eléctricos de Bus. Flexray dispone de 2 canales de
comunicación, lo que requiere un transceiver para cada canal.
Entre los
diferentes bloques mencionados existen líneas optativas de señalización para
determinadas situaciones. Esto será explicado más adelante con más detalle.
Por tanto el hardware que se espera de un
nodo o ECU responde al siguiente esquema:
Fig. 2.1 Arquitectura hardware de un nodo Flexray
1.2. Topologías de red.
Flexray
permite un amplio abanico de topologías de red. El hecho de tener 2 canales
independientes aporta además otro grado de libertad, pudiendo hacer para cada
canal una configuración de nodos diferente.
La
interconexión básica entre dos nodos responde al siguiente esquema:
Fig. 2.2 Interconexión básica entre dos nodos Flexray
Como
podemos apreciar, es similar a cualquier protocolo diferencial como podría ser
CAN. En el capítulo 3 entraremos en más detalle en el hardware asociado a la
terminación de los nodos.
En el caso
que conectemos más nodos podemos hacerlo de manera pasiva o de manera activa.
Veamos antes de empezar a ver diferentes ejemplos de topologías otro elemento
de red importante en Flexray como es el Active Star. El siguiente esquema nos
da una idea:
Fig. 2.3 Interconexión básica usando Active Stars
Como vemos,
podemos asociar el concepto de Active Star (AS) al de un hub repetidor de bus.
En el apartado 2.1.5. se describe el concepto de AS con más detalle.
Así pues
combinando estos elementos entre sí y para cada canal obtenemos una
flexibilidad substancial de crear diferentes topologías de red, ya sean básicas
o híbridas.
Para cada una de
ellas existen algunas limitaciones que hay que cumplir para el correcto
funcionamiento del bus tales como longitud máxima del bus, número máximo de
stubs, número máximo de Active Stars... Estos parámetros son típicos de todos
los buses y tienen como causa principal los retardos que se producen en el bus.
1.2.1. Topologías básicas
1.2.1.1 Linear passive bus
Es la topología
más básica y una de las más usadas. Se puede apreciar como es posible que un
nodo se conecte a los dos canales (por ejemplo en el caso que este nodo
representara una función crítica del sistema) mientras que otros nodos se
conectan a uno de los dos canales.
Las
limitaciones más importantes a tener en cuenta en esta topología son:
Longitud del bus
|
24m
|
Número máximo
de nodos conectados al bus mediante stubs
|
22
|
Mínima
distancia entre stubs
|
15cm
|
Tabla 2.1. Limitaciones de la topología linear passive
bus
Fig. 2.4 Topología linear passive bus
Cabe recalcar
que existe una variante del Passive Bus que es la Passive Star la cual tiene
las mismas limitaciones que el anterior. Eso sí se limita el uso de la Passive
Star a un máximo de 1 ‘splice’ (empalme). La idea de la Passive Star es que
todos los nodos se unen en un solo punto. Veamos un ejemplo:
Fig. 2.5 Topología Passive Star
1.2.1.2 Topologías con Active Stars
Estas topologías hacen uso del elemento repetidor
Active Star. Este elemento de bus es capaz de desacoplar eléctricamente las
diferentes ramas a las cual está conectado, además de regenerar la señal aunque
por otro lado introduce retardos. Se les puede dotar de cierta inteligencia
consiguiendo un ruteado del mensaje, todo y que esto acumularía aún más
retardo. También pueden desconectar una rama de la red si detectan un mal
funcionamiento. Las limitaciones en este caso son:
Distancia
máxima de un nodo al Active Star
|
24m
|
Longitud
máxima entre dos AS
|
24m
|
Número
máximo de AS en cascada
|
2
|
Tabla 2.2. Limitaciones de las
topologías con Active Stars
Fig. 2.6 Topología clásica con Active
Stars
Fig. 2.7 Topología custom con Active
Stars
1.2.2. Topologías híbridas
Es posible crear una red a base de la unión
de topologías básicas, todo y que no es muy recomendable ya que son topologías
no estándar y poco probadas. En estos casos, las limitaciones son una mezcla de
las topologías básicas que entrañe. La gran ventaja de estas topologías es su
versatilidad.
Fig. 2.8 Topología híbrida bus
Flexray
1.3. Morfología de datos a nivel físico
Flexray es un
bus diferencial, lo que quiere decir que se basa en la diferencia de señales
del bus para determinar el dato enviado. Las salidas del transceiver son BP y
BM y la información relativa uBus = BP-BM.
El transceiver
es el encargado de gestionar la trama lógica que le llega del Communication
Controller y traducirla a los niveles eléctricos correspondientes del bus y
viceversa.
1.3.1. Datos a nivel eléctrico.
Los diferentes símbolos que podemos encontrar
en el bus son:
Fig. 2.9 Símbolos a nivel eléctrico del bus Flexray
• Idle_LP: Estado del bus
en baja energía cuando no circula corriente por el mismo y el transceiver
fuerza un 0 a la salida.
• Idle: Estado del bus cuando no circula corriente
por el bus pero el transceiver fuerza un determinado voltaje para BP y BM.
• Data_1: La información lógica 1 se traduce a una
diferencia positiva entre BP y BM (uBus>0)
• Data_0: La información lógica 1 se traduce a una
diferencia negativa entre BP y BM (uBus<0)
Los estados
Idle_LP y Idle sirven para determinar que el canal está libre. Más adelante,
veremos como se gestiona este aspecto ya que en ello intervienen elementos de
protocolo de capa superior. Además de estos estados, por el Bus pueden circular
lo que en el protocolo Flexray se llaman Símbolos y que realizan funciones
especificas. Los veremos en el siguiente apartado.
1.3.2. Datos a nivel lógico.
El transceiver traduce de niveles eléctricos
a niveles lógicos en ambos sentidos. Para eso, dispone de una entrada Vdig
(Voltaje digital) para adecuarse a la tensión de operación del CC. Veámoslo en
el siguiente ejemplo:
Fig. 2.10 Símbolos lógicos del bus
Flexray
Si la
diferencia entre BP y BM (uBus) es positiva se traducirá como un uno lógico
mientras que si es negativa en un cero lógico. Si detecta el bus libre (uBus
cercano a 0) lo traducirá como un uno lógico. Una capa superior será la
responsable de interpretar esta información. Finalmente, el tiempo de bit
dependerá de la velocidad a la que esté transmitiendo los datos, que en el caso
de Flexray puede ser de 1 a 10Mbps.
Además de
éstos, existen en Flexray 3 símbolos especiales:
• WUS (Wake Up Symbol): Sirve
para despertar los nodos de una red. Morfológicamente es una sucesión de ceros
determinada seguida de otra de unos. Los Wake Up Symbols suelen ir en
secuencias de Wake Up Patterns. Su función la describiremos más adelante cuando
hablemos de la capa lógica Flexray. Veamos su morfología:
Fig. 2.11 Wake Up Pattern formado por 2 Wake Up Symbols
• MTS (Media Access Test
Symbol): Este símbolo sirve para realizar procesos de depuración y su
morfología es la misma que el WUS.
• CAS (Collision Avoidance
Symbol): Sirve para sincronizar una red y evitar colisiones en la fase de
establecimiento de la conexión. Su morfología es un conjunto de ceros seguidos
durante un tiempo determinado. Veremos su función cuando hablemos de la capa
lógica del protocolo.
Fig. 2.12 CAS (Collision Avoidance
Symbol)
1.3.3 Trama física
La trama Física en Flexray sigue la siguiente
morfología:
Fig. 2.13 Trama física del bus Flexray
• TSS (Transmission Start
Sequence): Antes de iniciar la comunicación se inserta un periodo de ceros
determinado de manera de aviso al resto de nodos. La TSS es un parámetro
importante, sobre todo en el uso de Active Stars, ya que les ayuda a configurar
sus entradas y salidas antes de iniciar la comunicación.
• FSS (Frame Start Sequence): Posteriormente
a la TSS se inserta un bit a 1 para compensar posibles errores de cuantización.
• BSS (Byte Start Sequence): Al
principio de cada Byte enviado se inserta un 1 lógico seguido de un 0. Esto nos
sirve para sincronizar así como también nos ayuda a determinar si el canal está
libre o se están enviando datos.
Cuando el canal está libre, el
receptor lo interpreta como un seguido de unos. Si una capa superior detecta
que hay muchos unos seguidos determinará que el canal está libre, ya que en el
caso contrario cada 8 unos seguidos se tendría que encontrar forzadamente un
cero debido al BSS.
• FES
(Frame End Sequence): Es el indicador de final de trama. Como veremos en la
capa lógica del protocolo, en Flexray existen tramas estáticas y tramas
dinámicas con longitud variable. En el caso de que la trama sea dinámica, se
añade posteriormente al FES lo que se denomina el DTS (Dynamic Trailing
Sequence) y que sirve para evitar una prematura detección de canal libre.
Los datos
pues se envían denotando el principio de trama, el final y en grupos de Bytes
empezando por el MSB (Most significant bit) y acabando en el LSB (Least
significant bit).
Finalmente,
veamos algunas capturas de tramas reales del Bus para apreciar con más detalle
toda esta información:
En esta captura podemos apreciar una trama
estática clásica perteneciente a la línea BP. Empieza con un TSS y cada 8 bits
se incluye un BSS. Finalmente acaba en un FES. Podemos apreciar también los
niveles eléctricos. Vidle= 2.5V y BP varía entre máximo y mínimo 1200mV.
Fig. 2.14 Trama estática del bus Flexray
En esta otra trama podemos apreciar el final
de trama con el FES y como después, al cabo de un número prefijado de unos se
queda el canal libre.
Fig. 2.15 Detalle del final de una
trama estática Flexray
Finalmente, vemos en este caso una trama
dinámica y como justo después del FES encontramos el DTS que evita que el canal
quede libre prematuramente.
Fig. 2.16 Detalle del final de una
trama dinámica Flexray
En el anexo 1
“Capturas y estadísticas del bus Flexray” se pueden encontrar un gran conjunto
de capturas interesantes del bus.
1.4. Algoritmos Majority Voting y de Bit Strobing.
Las señales
eléctricas del bus son traducidas a niveles lógicos por el transceiver y éste
los envía al CC. Para muestrear correctamente estos datos y evitar errores el
CC efectúa dos operaciones importantes antes de pasar los datos a una capa
superior: son el Majority Voting i el Bit Strobing.
1.4.1 Majority Voting
Su funcionamiento es sencillo de entender.
Como su propio nombre indica se basa en una votación por mayoría.
Fig. 2.17 Funcionamiento del algoritmo
Majority Voting
El CC toma 8
muestras por cada bit proveniente del transceiver. En una ventana de 5 muestras
guarda los últimos resultados y la salida zVotedVal es igual a la mayoría de
unos o ceros acumulado en la ventana en ese momento.
Esto tiene 2
consecuencias. Sí que es cierto que introducimos un retardo de 3 muestras a la
salida. No obstante, el beneficio es grande. Gracias a este método se eliminan
glitches de hasta 2 muestras de duración, haciendo pues la señal más robusta.
1.4.2. Bit Strobing
Una vez los datos han pasado por el mecanismo
de Majority Voting, pasan al mecanismo de Bit Strobing. Su función es la de
sincronizarse con la trama de entrada y muestrear en el instante óptimo de
muestreo.
Fig. 2.18 Funcionamiento del algoritmo Bit Strobing
El CC tiene un contador de muestreo que
cuenta en módulo 8. Parece lógico e intuitivo pensar en que de las 8 muestras
que toma de cada bit que le llega, el instante óptimo de muestreo esté en la 4
o 5 posición, asegurando así que un pequeño jitter no produzca un muestreo
erróneo.
Otro
punto a considerar es la sincronización del contador para que empiece a contar
al inicio del bit. Así pues, en cada flanco de bajada se resetea este contador.
Como hemos comentado anteriormente, la trama física Flexray tiene cada 8 bits
un BSS el cual fuerza un flanco de bajada. De esta manera al inicio de cada bit
se resetia el contador y se toma la 5 muestra a partir de ese momento. Ésta
será la muestra que se pasará a la capa superior.
1.5. Concepto de Active Star.
En el apartado
1.2.1. (Topologías de red) hemos visto por encima las Active Star. En concreto
hemos visto como podemos crear una red con elementos activos funcionando como
repetidores. Esto implica 2 ventajas esenciales:
• Aislamos las diferentes ramas
de bus conectadas a la estrella, con lo que si se genera un fallo en una rama
no se transmite al resto de ramas.
• Regenera la señal eléctrica.
Los dos
principales inconvenientes serían:
• Estos elementos introducen
retardos.
• Supone un coste extra de
hardware y de espacio.
Así pues,
todo dependerá de la solución requerida en cada caso.
Otro aspecto importante es que las Active
Star pueden incorporar o no un CC. Es decir, podemos encontrar que un nodo se
comportara como Active Star. Esto dotaría de este elemento de red de una cierta
inteligencia, pagando el precio de un elevado retardo. Veamos una solución
usando esta idea:
Fig. 2.19 Arquitectura hardware de una
Active Star usando un CC
Otra solución sin CC es la que propone
Phillips con su transceiver TJA1080. Su gran ventaja es la facilidad de uso.
Fig. 2.20 Arquitectura hardware de una
Active Star sin CC
Como vemos, el
transceiver incorpora unos pines llamados TRXD0 y TRXD1 los cuales uniéndolos
con los del resto de transceivers forman la Active Star.
1.6. Concepto de Bus Guardian.
Antes de nada
hay que comentar, que el concepto de Bus Guardian aún está en desarrollo.
La idea es la de aportar otro elemento de red
al bus Flexray con la intención de incrementar su condición de
“Fault-Tolerant”. Su función es la de permitir transmitir al resto del bus
única y exclusivamente al nodo que tiene programado en su memoria como que le
toca enviar en ese preciso instante. La memoria del Bus Guardian, pues, se ha
de programar en tiempo de diseño.
El Bus
Guardian se concibe pues como un elemento de red dotado de cierta inteligencia
que aporta seguridad y protección contra fallos como podrían ser babbling idiot
o cortocircuitos en el bus.
Está pensado exclusivamente para aplicaciones
muy críticas. Tanto es así, que podríamos programar el Bus Guardian de manera
que sólo protegiera determinadas tramas que nos interesaran por diseño. Veamos
un esquema de red integrando un Bus Guardian
Fig. 2.21 Arquitectura de red usando un Bus Guardian
Como vemos haría falta un BG por canal. Para
poder hacer estas funciones, el BG debe de estar sincronizado con el protocolo,
con lo cual necesitará un reloj propio y incorporar capas superiores a la
física en su pila.
2.2 Capa lógica
La capa lógica
del protocolo está gestionada por el CC. Encima de la capa lógica
encontraríamos la capa de aplicación controlada por el uC de la ECU.
Por ejemplo, en
un sistema de Brake-by-Wire, el uC de la ECU gestionaría los sensores que
determinarían la posición de frenado, las máquinas de estados que determinarían
el flujo del programa y la información que hay que enviar al CC (por SPI o bus
paralelo) para que llegue a través de FLEXRAY a la ECU que controla el sistema
de actuadores.
Es decir, el uC
se abstrae totalmente de la gestión del protocolo Flexray, cuya misión recae en
el CC. A la máquina de estados principal del CC se le llama POC (Protocol
Operation Control) y es la que controla los procesos más importantes de
Flexray. En este capítulo estudiaremos estos procesos y veremos los mecanismos
que dispone Flexray para despertar la red (Wake Up) y para comenzar la
comunicación (Start UP).
2.1. Protocol Operation Control (POC)
El POC es la
máquina de estados principal del protocolo. Decide en todo momento en qué
estado se encuentra el protocolo y reacciona a las órdenes del uC realizando
los cambios necesarios en los siguientes subprocesos, llamados “core
mechanisms”:
• Coding and Decoding
• Frame and Symbol processing
• Media Access Control
• Clock Synchronization.
Inmediatamente después de recibir energía. El
CC controller entra en el estado de POC OPERATIONAL y empieza a funcionar el
POC. Lo podemos apreciar en el siguiente diagrama de estados:
Fig. 2.22 Máquina de estados del power
on del POC
Una vez que el POC está operativo puede
cambiar de estado debido a las órdenes que le lleguen del host o por
condiciones de error detectadas en el protocolo. Veamos el diagrama de estados
principal del POC y qué función desempeña cada estado
Fig. 2.23 Máquina de estados del POC
• Default config: Estado
por defecto al entrar en el POC. En este estado se inicializa la configuración
por defecto.
• Config: Estado de
configuración. En este estado se entrará siempre que se requiera configurar de
nuevo algún parámetro.
• Ready: Estado por el
cual hay que pasar para realizar una nueva configuración, así pues despertar el
nodo si es necesario (wake up), o volver a iniciar la comunicación con la nueva
configuración aplicada (startup)
• Wakeup: Estado cuya
función principal es despertar la red.
• Startup: Estado cuya
función principal es la de iniciar la comunicación en la red.
• Normal active: Modo
normal de operación en el cual hay comunicación fluida Flexray.
• Normal passive: Estado
al cual se llega si se detectan leves errores en la comunicación En caso de
recuperarse de esos errores puede volver a pasar a normal active. En caso
contrario, pasará al estado HALT.
• Halt: Estado al que se
llega si se detecta error grave en la comunicación, o por orden directa del
host. Para volver a comunicarse, hará falta realizar de nuevo la secuencia de
estados desde el inicio del POC.
A continuación
describiremos los principales procesos controlados por el POC y que son
llamados los “core mechanisms”, ya que son la base de FLEXRAY.
2.1.1 Coding and decoding
El subproceso
Coding and decoding se encarga de realizar las funciones de Codificar y
Decodificar las tramas. Forman parte de este proceso los mecanismos Majority
Voting y Bit Strobing vistos en el apartado 2.1.4.1. y 2.1.4.2. para
decodificar las tramas. Hay que añadir que la forma de codificarlas también lo
vimos en el apartado 2.1.3.3.
Lo que vamos a ver a continuación son los
campos a nivel lógico que conforman la trama Flexray.
Fig. 2.24 Trama lógica del bus Flexray
En un primer
nivel podemos distinguir entre 3 bloques: Cabecera, Datos y CRC. Como vemos la
trama puede variar entre 8 y 262 bytes.
El significado
de los campos de cabecera es el siguiente:
• Reserved
bit: Bit reservado del protocolo para futuros usos.
• Payload
Preamble indicator: Sirve para indicar que los primeros bytes del segmento
de datos también son de cabecera. Esto se usa para tareas de mantenimiento y
gestión de la red o para indicadores en las tramas dinámicas.
• Null Frame Indicator: Indica si la trama lleva datos
o no. A veces, por ejemplo en tramas de sincronismo, se envía una trama para
mantener el sincronismo pero no lleva
datos asociados. Cabe indicar que la situación contraria se puede dar. Es decir,
se puede enviar una trama de sincronía que además contenga datos.
• Sync
Frame Indicator: Indica si la trama es de sincronismo. Estas tramas que
sirven para sincronizar todos los nodos a la base de tiempos global de Flexray.
• Startup
Frame Indicator: Indica si es una trama de Startup. Es decir, si es una
trama de inicio de comunicación. En el apartado 2.2.3. se describe su uso.
• Frame
ID: Identificador único de la trama asociado a un nodo. Define el slot en
el cual se envía la trama.
• Payload
length: Define la longitud del campo de datos enviado con la trama.
• Header
CRC: CRC de cabecera. Sirve para agilizar el protocolo. Si un nodo detecta
un error en el CRC de cabecera descarta directamente la trama.
• Cycle
Count: indica el ciclo de comunicación en el que nos encontramos.
2.1.1.1 Channel idle detection
Dentro del
apartado coding and decoding cobra especial relevancia un subproceso llamado
Channel idle detection el cual detecta si el canal está libre. Como comentamos
en la capa física (apartado 2.1.3.2.), el Transceiver traducía los 3 símbolos
eléctricos (1, 0 y libre) tan sólo a dos lógicos (1 y 0).
El mecanismo que
usa Flexray para determinar si el canal está libre es contar el número de unos
seguidos que se reciben y si pasa un determinado umbral, se considera el canal
libre. Esto funciona ya que cualquier trama Flexray, lleva intercalado cada 8
bits un BSS (Byte Start Sequence) en el cual siempre hay un flanco
descendiente, forzando un cero.
2.1.2. Frame and Symbol Processing
El proceso Frame and Symbol
Processing, se encarga de recoger los datos de salida del “Coding and Decoding
process”, comprobar errores tanto sintácticos, semánticos como de
sincronización y en caso positivo pasar la información relevante al CHI
(Controller Host Interface) para que el uC pueda leer el mensaje recibido.
2.1.3. Media Acces Control
El protocolo
Flexray se basa en un ciclo de comunicación recurrente. Este ciclo está
dividido en 4 segmentos:
• Static Segment: El Static Segment está compuesto por
slots de medida fija. Cada slot está asociado a una Frame ID. Por su parte cada
Frame ID está asociada a un nodo, de manera que cada nodo sabe siempre en qué
slot o slots le toca enviar. Este segmento es de carácter obligatorio y siempre
se comporta igual. Es decir, las tramas estáticas siempre se envían.
• Dynamic Segment: El Dynamic Segment está compuesto
por dynamic slots la medida de los cuales es variable y se establece un orden
de envío por prioridad de ID, similar al CAN. Es decir, si dos nodos en el
segmento dinámico luchan por transmitir, ganará el de la ID más baja. Además el
tamaño de la trama no es fijo, así que el primer nodo en coger el control del
bus podría agotar el Dynamic Segment. Este segmento es de carácter opcional, a
diferencia del estático.
• Symbol Window: En el Symbol Window se pueden
enviar los MTS para gestión de la red. Es de carácter opcional y raramente se
usa.
• Network Idle Time: Al final del ciclo se deja el
canal un cierto tiempo libre para poder ajustar el tiempo de ciclo a la durada
fija determinada. Este segmento es de carácter obligatorio.
En el siguiente diagrama se aprecian las diferentes
posibilidades de configurar el ciclo de comunicación.
Fig. 2.25 Ciclo
de comunicación básico del bus Flexray
2.1.3.1. Unidades de tiempo en Flexray
Flexray es un
protocolo basado en una base de tiempos global. Con lo cual la gestión del
tiempo es crítica para el acceso al medio. Por ello tiene diferentes unidades
de tiempo:
• Microtick: Unidad de tiempo básica dependiente el
oscilador local de cada nodo.
• Macrotick: Unidad de tiempo básica de la red.
Todos los nodos tienen el mismo valor de Macrotick. Así pues si dos nodos
tienen un oscilador local diferente tendrán diferente número de microticks por
macrotick, pero al final el valor de macrotick será el mismo para todos.
• Cycle: Es una unidad de tiempo propia de la red y
es el tiempo del ciclo de comunicación medido en macroticks.
Para ver más clara la diferencia entre estos
tres conceptos fijémonos en el siguiente diagrama:
Fig. 2.26 División del ciclo de comunicación Flexray en
macroticks y microticks
Una vez visto los diferentes segmentos que
forman el ciclo de Flexray y entendidas las unidades básicas de tiempo, veamos
como está dividido un ciclo de comunicación en unidades de tiempo:
Fig. 2.27 División del ciclo de
comunicación Flexray en segmentos, slots y macroticks
El Static
Segment, está dividido en un número fijo de static slots que a su vez están
formados por un número fijo de macroticks. Al inicio de cada Static Slot, el
mecanismo ‘Clock Synchronization’ marca el instante en el cual ha se ha de
empezar a transmitir ese slot. A este instante, se le llama Static Slot Action
Point y es de vital importancia dada la naturaleza TDMA del protocolo.
En el Dynamic
Segment ocurre algo parecido pero en este caso se habla de Dynamic Slots,
formados por minislots y guiados por el Minislot Action point. Esta diferencia
entre Static slots y minislots radica en que en el segmento dinámico las tramas
no tienen por qué tener una medida estándar y cabe aprovechar al máximo las
unidades de tiempo, reduciendo su duración en macroticks.
En el Symbol
Window y el Network idle Time el tiempo se mide directamente en macroticks.
2.1.4. Clock Synchronization
Flexray es un
protocolo determinístico basado en la división del tiempo en ranuras donde cada
nodo sabe en qué ranura puede enviar y en cual no. Dada esta descripción, se
puede entender la gran importancia de mantener todos los nodos sincronizados
constantemente. De lo contrario, fácilmente un nodo no sincronizado podría al
transmitir invadir la ranura del vecino y provocar un fallo general de
comunicación. Es por eso, que el proceso Clock Synchronization cobra gran
relevancia en el protocolo Flexray.
Todo y que cada
nodo dispone de su propio oscilador, Flexray funciona con una base de tiempos
global a nivel de red. Esto lo consigue gracias a las tramas de sincronismo que
envían un mínimo de 2 nodos en una red de 2 ECUs o 3 en una red de 3 o más
ECUs. Estos nodos, llamados Coldstart nodes, son muy importantes tanto en el
inicio de la comunicación como en el sincronismo de la red. Suelen tener
osciladores muy precisos y marcan el tiempo al cual se han de ir adaptando el
resto de nodos.
La sincronización del reloj se basa en 2
subprocesos importantes:
2.1.4.1. Clock Synchronization Process.
El Clock
Synchronization Process (CSP) recoge los valores de las tramas de sincronía
enviadas por los diferentes Coldstart nodes de la red, los compara con los que
él había predecido y hace una estimación del valor correcto. El resultado lo
pasa al Macrotick Generation Process.
2.1.4.2. Macrotick Generation Process
El Macrotick
Generation Process (MTG), como indica su nombre, es el encargado de generar el
macrotick y del control de tiempos como el tiempo de ciclo o el tiempo de slot.
Así pues, con los datos que le pasa el CSP, efectúa las correcciones necesarias
para mantener el sincronismo del nodo:
·
• Correcciones de Offset: Indica
el número de microticks que hace falta añadir al NIT (Network idle Time) para
que el ciclo de comunicación Flexray comience en el momento adecuado. Se
calcula cada ciclo y se corrige en el NIT de los ciclos impares.
·
• Correcciones de Rate: Indica
el número de microticks por macrotick que hay que añadir (o substraer) para
adecuarse al tiempo de ciclo. Se calcula en los ciclos impares y se aplica
siempre.
Fig. 2.28 Correcciones
de offset y de rate del CSP (Clock Synchronization Process)
2.2. Wake Up del Bus Flexray
En Flexray, como en otros
muchos sistemas electrónicos, es posible encontrarnos con ECUs y transceivers
en estado sleep como método de ahorro de energía. Por eso, antes de iniciar una
comunicación Flexray, es necesario un procedimiento de Wake Up que despierte
todos los nodos. Para que este procedimiento funcione, el mínimo requerimiento
es que todos los Transceiversse encuentren
alimentados, aunque se encuentren en estado de baja energía. Si esto sucede, el
Transceiver que reciba una orden de WakeUp (un Wake Up pattern formado por una
cadena de símbolos WakeUp) por uno de sus canales del bus podrá comunicarse
directamente con su host y despertarlo. El host será responsable de determinar
si el otro canal está dormido y en cuyo caso será responsable de despertarlo.
Un hecho
importante a considerar es que está prohibido intentar despertar los dos
canales a la vez, puesto que en caso que hubiera un nodo fallando podría
perturbar los dos canales y impedir la comunicación Flexray.
Teniendo todo esto en cuenta veamos un
ejemplo de como se despertaría una red de 4 nodos y dos canales:
Fig. 2.29 Flujo de secuencia del Wake Up del bus
Flexray
Como
vemos el nodo 4 sólo está conectado a un canal, en este caso el B. Esta
situación se puede dar siempre que el nodo no sea crítico.
1.
Siempre ha de haber un host que tome la iniciativa de iniciar la comunicación
debido a un evento externo.
2. Se
inicializa el CC con los parámetros de configuración deseados.
3. El
host despierta sus dos transceivers (Canal A y Canal B)
4. El
host lanza la orden al CC de que pase al estado de WakeUP. El CC genera un
Wake-up pattern que es enviado al transceiver del canal A para que sea
transmitido por el bus.
5. Todos los transceivers del canal A se despiertan por el
wake-up pattern y a la vez despiertan a sus hosts.
6. Los hosts 2 y 3 de despiertan.
7. Los hosts 2 y 3 despiertan sus CCs y los inicializan.
8. Los hosts 2 y 3 chequean si los transceivers del Canal B
se han despertado. En caso contrario los despiertan.
9. Una vez que los transceivers
del canal B están despiertos, los hosts verifican que los 2 canales estén
despiertos. Si el canal B no está despierto, dan la orden a sus CCs para que
envíen un Wake-up pattern al canal B. Esto hace despertar los transceivers que
no se habían despertado en ese canal.
10. El host del nodo 4, que sólo estaba conectado al Canal
B es despertado.
11. El host del nodo 4 despierta a su CC.
Una vez que los
2 canales han sido despertados se puede empezar la fase de start-up, el
establecimiento de la conexión Flexray. Es importante destacar que en la fase
de Wake Up intervienen tanto transceivers, CC y host. Ninguno de estos puede
efectuar el Wake-up por sí sólo.
2.3. Startup del bus Flexray
Una vez
despertados los nodos con el procedimiento de Wake-up, el paso siguiente
inmediato es el de Startup, con el objetivo de establecer la conexión
sincronizando todos los nodos. Es el momento de introducir otro concepto, el
Coldstart node.
Los nodos
Coldstart, suelen ser los mismos que los nodos encargados de enviar las tramas
de sincronía. De hecho, por obligación un nodo Coldstart ha de estar
configurado para enviar tramas de sincronía. Al igual que pasaba con los Sync
nodes, ha de haber un mínimo de 2 Coldstart nodes en una red de 2 nodos y un
mínimo de 3 en una red de más nodos.
Los nodos
Coldstart son los encargados de tomar la iniciativa en la fase de Startup.
Distinguimos dos tipos: el Leading Coldstart node y el Following Coldstart
node. En un principio todos los Coldstart nodes competirán por iniciar la
comunicación pero sólo habrá uno que ganará y este será el Leading Coldstart
node. El resto se convertirán automáticamente en Following Coldstart nodes. El
mecanismo para asignar el Leading Coldstart node es el siguiente:
Todos los
nodos Coldstart después del wake-up, enviarán un CAS (Collision Avoidance
Symbol) al bus. El primero que envíe este símbolo será el Leading
Coldstart
node. El resto, recibirán el CAS y interpretarán que ya hay un Leading
Coldstart node.
El
proceso de startup tiene una serie de fases. Veamos con un la ayuda de un
diagrama ejemplo el funcionamiento:
Fig. 2.30 Cronograma de la fase de Start Up del bus
Flexray
Partimos
de una situación ficticia de 3 nodos, 2 son Coldstart y el otro no. (En
realidad en una red de 3 nodos deberían ser los 3 Coldstart, el ejemplo sólo
sirve para ilustrar el funcionamiento)
1. Los
nodos vienen de ser despertados en la fase de Wake-up. Así pues, pasan al
estado ready del POC y de allí los nodos Coldstart A y B toman la iniciativa.
2. El
primer estado por el que pasan los nodos A y B es el Coldstart listen. En este
estado han de escuchar el canal para ver si hay algún otro nodo Coldstart que
haya enviado ya un CAS. Cuando al nodo A se le acaba el tiempo de espera y no
ha recibido un CAS, envía un CAS al bus para que el resto de nodos sepan que ya
hay un “Leading Coldstart node”. Así pues, el resto de nodos Coldstart tomarán
el rol de Following Coldstart nodes. El nodo C no es Coldstart y por tanto no
interviene de momento.
3. Una
vez determinado el Leading Coldstart node, éste ha de tomar la iniciativa
empezando a enviar tramas de start-up que son a la vez tramas de sincronía. El
resto de nodos va sincronizándose conforme al nodo A. Al cabo de 4 tramas de
start-up los nodos Following Coldstart nodes se integran en la red y empiezan a
enviar también sus tramas de start-up.
4. Una
vez, todos los Coldstart nodes están integrados, el resto de nodos se integran
en la red pasando todos a normal active y pueden empezar a enviarse tramas de
datos. Es importante notar que el nodo C no envía ninguna trama de sincronía,
si no que con las tramas que han ido enviando los nodos Coldstart se ha ido
sincronizando.
Finalmente, después de la fase de Wake-up y
la fase de Start-up, ya tenemos la conexión Flexray entre todos los nodos
operativa.
CONCLUSIÓN
El protocolo
Flexray está llamado a ser el estándar de facto para las aplicaciones X-by-Wire
en un futuro cercano. Si bien hoy la mayoría de ECUs del vehículo se comunican
a través del bus CAN, en pocos años empezarán a convivir los dos buses. Su uso
se irá incrementando poco a poco y con la posible llegada de los motores
eléctricos al automóvil su inclusión puede ser muy importante.
Del estudio del
bus Flexray se sacan conclusiones interesantes. Su carácter determinístico y su
tolerancia a fallos permiten a los diseñadores abrir sus horizontes hacia el
diseño electrónico de aplicaciones críticas del automóvil. El protocolo
mantiene ciertas similitudes con CAN sobre todo en su capa física como son el
carácter diferencial del mismo y las etapas de salida. Esto hace que el diseño
hardware para un ingeniero experimentado en CAN no sea una gran dificultad
teniendo en cuenta las pequeñas diferencias. A nivel lógico es bastante
diferente, hecho que sí que reportará más trabajo al ingeniero de software.
De todas
maneras, así como el controlador de CAN se ha acabado incorporando en la
mayoría de microcontroladores de automoción, un hecho similar pasará con Flexray,
simplificando así el diseño, el software y el ahorro de espacio y precio de la
PCB.
El diseño de un
prototipo ilustrativo de esta tecnología nos ha permitido experimentar el
arranque de un bus nuevo, adquirir know-how de la tecnología y crear una
aplicación de alto nivel basada en ella. Este hecho permite a la empresa FICOSA
estar preparada para el día en que los clientes empiecen a demandar esta
tecnología. Análogamente, los clientes que visiten el show-room de FICOSA
podrán apreciar esta nueva tecnología y entender sus virtudes y las necesidades
de seguridad que puede satisfacer.
Como líneas futuras de investigación, se
pueden crear buses más complejos, con un número mayor de ECUs, incluyendo
Active Stars o incluso Bus Guardians. Este hecho permitiría crear aplicaciones
más complejas de alto nivel para sacar el máximo rendimiento al bus. El uso de
la PCB-FLEXRAY aquí diseñada puede allanar el terreno gracias a su versatilidad
para comunicarse con una gran cantidad de microcontroladores.
BIBLIOGRAFÍA
1.
Lorenz, Steffen (2010). "The FlexRay
Electrical Physical Layer Evolution" (PDF). Automotive 2010.
Retrieved 16
February 2015.
3.
Scoltock, James (1 December 2013). "Milestones:
Flexray". Automotive Engineer.
Retrieved 16
February 2015.
4.
Regler, Richard; Schlinkheider, Jörg; Maier, Markus;
Prechler, Reinhard; Berger, Eduard; Pröll, Leo (2011). "Intelligent
electrics / electronics architecture". ATZextra worldwide 15 (11): 246–251. doi:10.1365/s40111-010-0269-9 (inactive 15 June
2015).
6.
Scoltock, James (16 April 2013). "Mercedes-Benz
E-Class". Automotive Engineer.
Retrieved 16
February 2015.
8.
Hammerschmidt, Christoph (18 June 2010). "Beyond FlexRay:
BMW airs Ethernet plans". EE Times.
Retrieved 16
February 2015.
RESUMEN
1. Capa física
En este
apartado vamos a describir los puntos más importantes y relevantes de la capa
física del protocolo Flexray.
1.1. Arquitectura de un nodo
Un nodo
Flexray está formado esencialmente por un microcontrolador, un periférico
llamado Communication Controller, 2 transceivers y una fuente de alimentación.
El
microcontrolador es el propio de la ECU, el cual seguramente realiza otras
funciones externas propias de la ECU y que cada cierto tiempo envía y recibe
una trama de información al bus Flexray. Para ello se comunica con el
Communication Controller (CC), que no es más que un periférico hardware que
gestiona en todo momento el protocolo. Es decir, el microcontrolador no se
encarga de la pila del protocolo, si no que lo gestiona todo el CC.
Así pues,
el CC se comunica a su vez con los transceivers que se encargan de transformar
los datos lógicos a niveles eléctricos de Bus. Flexray dispone de 2 canales de
comunicación, lo que requiere un transceiver para cada canal.
Entre los
diferentes bloques mencionados existen líneas optativas de señalización para
determinadas situaciones. Esto será explicado más adelante con más detalle.
Por tanto el hardware que se espera de un
nodo o ECU responde al siguiente esquema:
1.2. Topologías de red.
Flexray
permite un amplio abanico de topologías de red. El hecho de tener 2 canales
independientes aporta además otro grado de libertad, pudiendo hacer para cada
canal una configuración de nodos diferente.
La
interconexión básica entre dos nodos responde al siguiente esquema:
Como
podemos apreciar, es similar a cualquier protocolo diferencial como podría ser
CAN. En el capítulo 3 entraremos en más detalle en el hardware asociado a la terminación
de los nodos.
En el
caso que conectemos más nodos podemos hacerlo de manera pasiva o de manera
activa. Veamos antes de empezar a ver diferentes ejemplos de topologías otro
elemento de red importante en Flexray como es el Active Star. El siguiente
esquema nos da una idea:
Como vemos,
podemos asociar el concepto de Active Star (AS) al de un hub repetidor de bus.
En el apartado 2.1.5. se describe el concepto de AS con más detalle.
Así pues
combinando estos elementos entre sí y para cada canal obtenemos una
flexibilidad substancial de crear diferentes topologías de red, ya sean básicas
o híbridas.
Para cada una de
ellas existen algunas limitaciones que hay que cumplir para el correcto
funcionamiento del bus tales como longitud máxima del bus, número máximo de
stubs, número máximo de Active Stars... Estos parámetros son típicos de todos
los buses y tienen como causa principal los retardos que se producen en el bus.
1.2.1. Topologías básicas
1.2.1.1 Linear passive bus
Es la topología
más básica y una de las más usadas. Se puede apreciar como es posible que un
nodo se conecte a los dos canales (por ejemplo en el caso que este nodo
representara una función crítica del sistema) mientras que otros nodos se
conectan a uno de los dos canales.
Cabe recalcar
que existe una variante del Passive Bus que es la Passive Star la cual tiene
las mismas limitaciones que el anterior. Eso sí se limita el uso de la Passive
Star a un máximo de 1 ‘splice’ (empalme). La idea de la Passive Star es que
todos los nodos se unen en un solo punto. Veamos un ejemplo:
1.2.1.2 Topologías con Active Stars
Estas topologías hacen uso del elemento
repetidor Active Star. Este elemento de bus es capaz de desacoplar
eléctricamente las diferentes ramas a las cual está conectado, además de
regenerar la señal aunque por otro lado introduce retardos. Se les puede dotar
de cierta inteligencia consiguiendo un ruteado del mensaje, todo y que esto
acumularía aún más retardo. También pueden desconectar una rama de la red si
detectan un mal funcionamiento. Las limitaciones en este caso son:
1.2.2. Topologías híbridas
Es posible crear una red a base de la unión
de topologías básicas, todo y que no es muy recomendable ya que son topologías
no estándar y poco probadas. En estos casos, las limitaciones son una mezcla de
las topologías básicas que entrañe. La gran ventaja de estas topologías es su
versatilidad.
1.3. Morfología de datos a nivel físico
Flexray es un
bus diferencial, lo que quiere decir que se basa en la diferencia de señales
del bus para determinar el dato enviado. Las salidas del transceiver son BP y
BM y la información relativa uBus = BP-BM.
El transceiver
es el encargado de gestionar la trama lógica que le llega del Communication
Controller y traducirla a los niveles eléctricos correspondientes del bus y
viceversa.
1.3.1. Datos a nivel eléctrico.
Los diferentes símbolos que podemos encontrar
en el bus son:
• Idle_LP: Estado del bus
en baja energía cuando no circula corriente por el mismo y el transceiver
fuerza un 0 a la salida.
• Idle: Estado del bus cuando no circula corriente
por el bus pero el transceiver fuerza un determinado voltaje para BP y BM.
• Data_1: La información lógica 1 se traduce a una
diferencia positiva entre BP y BM (uBus>0)
• Data_0: La información lógica 1 se traduce a una
diferencia negativa entre BP y BM (uBus<0)
Los estados
Idle_LP y Idle sirven para determinar que el canal está libre. Más adelante,
veremos como se gestiona este aspecto ya que en ello intervienen elementos de
protocolo de capa superior. Además de estos estados, por el Bus pueden circular
lo que en el protocolo Flexray se llaman Símbolos y que realizan funciones
especificas. Los veremos en el siguiente apartado.
1.3.2. Datos a nivel lógico.
El transceiver traduce de niveles eléctricos
a niveles lógicos en ambos sentidos. Para eso, dispone de una entrada Vdig
(Voltaje digital) para adecuarse a la tensión de operación del CC. Veámoslo en
el siguiente ejemplo:
Si la
diferencia entre BP y BM (uBus) es positiva se traducirá como un uno lógico
mientras que si es negativa en un cero lógico. Si detecta el bus libre (uBus
cercano a 0) lo traducirá como un uno lógico. Una capa superior será la
responsable de interpretar esta información. Finalmente, el tiempo de bit
dependerá de la velocidad a la que esté transmitiendo los datos, que en el caso
de Flexray puede ser de 1 a 10Mbps.
Además de
éstos, existen en Flexray 3 símbolos especiales:
• WUS (Wake Up Symbol): Sirve
para despertar los nodos de una red. Morfológicamente es una sucesión de ceros
determinada seguida de otra de unos. Los Wake Up Symbols suelen ir en
secuencias de Wake Up Patterns. Su función la describiremos más adelante cuando
hablemos de la capa lógica Flexray. Veamos su morfología:
• MTS (Media Access Test
Symbol): Este símbolo sirve para realizar procesos de depuración y su
morfología es la misma que el WUS.
• CAS (Collision Avoidance
Symbol): Sirve para sincronizar una red y evitar colisiones en la fase de
establecimiento de la conexión. Su morfología es un conjunto de ceros seguidos
durante un tiempo determinado. Veremos su función cuando hablemos de la capa
lógica del protocolo.
1.3.3 Trama física
La trama Física en Flexray sigue la siguiente
morfología:
• TSS (Transmission Start
Sequence): Antes de iniciar la comunicación se inserta un periodo de ceros
determinado de manera de aviso al resto de nodos. La TSS es un parámetro
importante, sobre todo en el uso de Active Stars, ya que les ayuda a configurar
sus entradas y salidas antes de iniciar la comunicación.
• FSS (Frame Start Sequence): Posteriormente
a la TSS se inserta un bit a 1 para compensar posibles errores de cuantización.
• BSS (Byte Start Sequence): Al
principio de cada Byte enviado se inserta un 1 lógico seguido de un 0. Esto nos
sirve para sincronizar así como también nos ayuda a determinar si el canal está
libre o se están enviando datos.
Cuando el canal está libre, el
receptor lo interpreta como un seguido de unos. Si una capa superior detecta
que hay muchos unos seguidos determinará que el canal está libre, ya que en el
caso contrario cada 8 unos seguidos se tendría que encontrar forzadamente un
cero debido al BSS.
• FES
(Frame End Sequence): Es el indicador de final de trama. Como veremos en la
capa lógica del protocolo, en Flexray existen tramas estáticas y tramas
dinámicas con longitud variable. En el caso de que la trama sea dinámica, se
añade posteriormente al FES lo que se denomina el DTS (Dynamic Trailing
Sequence) y que sirve para evitar una prematura detección de canal libre.
Los datos
pues se envían denotando el principio de trama, el final y en grupos de Bytes
empezando por el MSB (Most significant bit) y acabando en el LSB (Least
significant bit).
Finalmente,
veamos algunas capturas de tramas reales del Bus para apreciar con más detalle
toda esta información:
En esta captura podemos apreciar una trama
estática clásica perteneciente a la línea BP. Empieza con un TSS y cada 8 bits
se incluye un BSS. Finalmente acaba en un FES. Podemos apreciar también los
niveles eléctricos. Vidle= 2.5V y BP varía entre máximo y mínimo 1200mV.
En esta otra trama podemos apreciar el final
de trama con el FES y como después, al cabo de un número prefijado de unos se
queda el canal libre.
Finalmente, vemos en este caso una trama
dinámica y como justo después del FES encontramos el DTS que evita que el canal
quede libre prematuramente.
En el anexo 1
“Capturas y estadísticas del bus Flexray” se pueden encontrar un gran conjunto
de capturas interesantes del bus.
1.4. Algoritmos Majority Voting y de Bit
Strobing.
Las señales
eléctricas del bus son traducidas a niveles lógicos por el transceiver y éste
los envía al CC. Para muestrear correctamente estos datos y evitar errores el
CC efectúa dos operaciones importantes antes de pasar los datos a una capa
superior: son el Majority Voting i el Bit Strobing.
1.4.1 Majority Voting
Su funcionamiento es sencillo de entender.
Como su propio nombre indica se basa en una votación por mayoría.
El CC toma 8
muestras por cada bit proveniente del transceiver. En una ventana de 5 muestras
guarda los últimos resultados y la salida zVotedVal es igual a la mayoría de
unos o ceros acumulado en la ventana en ese momento.
Esto tiene 2
consecuencias. Sí que es cierto que introducimos un retardo de 3 muestras a la
salida. No obstante, el beneficio es grande. Gracias a este método se eliminan
glitches de hasta 2 muestras de duración, haciendo pues la señal más robusta.
1.4.2. Bit Strobing
Una vez los datos han pasado por el mecanismo
de Majority Voting, pasan al mecanismo de Bit Strobing. Su función es la de
sincronizarse con la trama de entrada y muestrear en el instante óptimo de
muestreo.
El CC tiene un contador de muestreo que
cuenta en módulo 8. Parece lógico e intuitivo pensar en que de las 8 muestras
que toma de cada bit que le llega, el instante óptimo de muestreo esté en la 4
o 5 posición, asegurando así que un pequeño jitter no produzca un muestreo
erróneo.
Otro
punto a considerar es la sincronización del contador para que empiece a contar
al inicio del bit. Así pues, en cada flanco de bajada se resetea este contador.
Como hemos comentado anteriormente, la trama física Flexray tiene cada 8 bits
un BSS el cual fuerza un flanco de bajada. De esta manera al inicio de cada bit
se resetia el contador y se toma la 5 muestra a partir de ese momento. Ésta
será la muestra que se pasará a la capa superior.
1.5. Concepto de Active Star.
En el
apartado 1.2.1. (Topologías de red) hemos visto por encima las Active Star. En
concreto hemos visto como podemos crear una red con elementos activos
funcionando como repetidores. Esto implica 2 ventajas esenciales:
• Aislamos las diferentes ramas
de bus conectadas a la estrella, con lo que si se genera un fallo en una rama
no se transmite al resto de ramas.
• Regenera la señal eléctrica.
Los dos
principales inconvenientes serían:
• Estos elementos introducen
retardos.
• Supone un coste extra de
hardware y de espacio.
Así pues,
todo dependerá de la solución requerida en cada caso.
Otro aspecto importante es que las Active
Star pueden incorporar o no un CC. Es decir, podemos encontrar que un nodo se
comportara como Active Star. Esto dotaría de este elemento de red de una cierta
inteligencia, pagando el precio de un elevado retardo. Veamos una solución
usando esta idea:
Otra solución sin CC es la que propone
Phillips con su transceiver TJA1080. Su gran ventaja es la facilidad de uso.
Como vemos, el
transceiver incorpora unos pines llamados TRXD0 y TRXD1 los cuales uniéndolos
con los del resto de transceivers forman la Active Star.
1.6. Concepto de Bus Guardian.
Antes de nada
hay que comentar, que el concepto de Bus Guardian aún está en desarrollo.
La idea es la de aportar otro elemento de red
al bus Flexray con la intención de incrementar su condición de
“Fault-Tolerant”. Su función es la de permitir transmitir al resto del bus
única y exclusivamente al nodo que tiene programado en su memoria como que le
toca enviar en ese preciso instante. La memoria del Bus Guardian, pues, se ha
de programar en tiempo de diseño.
El Bus
Guardian se concibe pues como un elemento de red dotado de cierta inteligencia
que aporta seguridad y protección contra fallos como podrían ser babbling idiot
o cortocircuitos en el bus.
Está pensado exclusivamente para aplicaciones
muy críticas. Tanto es así, que podríamos programar el Bus Guardian de manera
que sólo protegiera determinadas tramas que nos interesaran por diseño. Veamos
un esquema de red integrando un Bus Guardian
Como vemos haría falta un BG por canal. Para
poder hacer estas funciones, el BG debe de estar sincronizado con el protocolo,
con lo cual necesitará un reloj propio y incorporar capas superiores a la
física en su pila.
2.2 Capa lógica
La capa lógica
del protocolo está gestionada por el CC. Encima de la capa lógica
encontraríamos la capa de aplicación controlada por el uC de la ECU.
Por ejemplo, en
un sistema de Brake-by-Wire, el uC de la ECU gestionaría los sensores que
determinarían la posición de frenado, las máquinas de estados que determinarían
el flujo del programa y la información que hay que enviar al CC (por SPI o bus
paralelo) para que llegue a través de FLEXRAY a la ECU que controla el sistema
de actuadores.
Es decir, el uC
se abstrae totalmente de la gestión del protocolo Flexray, cuya misión recae en
el CC. A la máquina de estados principal del CC se le llama POC (Protocol
Operation Control) y es la que controla los procesos más importantes de
Flexray. En este capítulo estudiaremos estos procesos y veremos los mecanismos
que dispone Flexray para despertar la red (Wake Up) y para comenzar la
comunicación (Start UP).
2.1. Protocol Operation Control (POC)
El POC es la
máquina de estados principal del protocolo. Decide en todo momento en qué
estado se encuentra el protocolo y reacciona a las órdenes del uC realizando
los cambios necesarios en los siguientes subprocesos, llamados “core
mechanisms”:
• Coding and Decoding
• Frame and Symbol processing
• Media Access Control
• Clock Synchronization.
Inmediatamente después de recibir energía. El
CC controller entra en el estado de POC OPERATIONAL y empieza a funcionar el
POC. Lo podemos apreciar en el siguiente diagrama de estados:
Una vez que el POC está operativo puede
cambiar de estado debido a las órdenes que le lleguen del host o por
condiciones de error detectadas en el protocolo. Veamos el diagrama de estados
principal del POC y qué función desempeña cada estado
• Default config: Estado
por defecto al entrar en el POC. En este estado se inicializa la configuración
por defecto.
• Config: Estado de
configuración. En este estado se entrará siempre que se requiera configurar de
nuevo algún parámetro.
• Ready: Estado por el
cual hay que pasar para realizar una nueva configuración, así pues despertar el
nodo si es necesario (wake up), o volver a iniciar la comunicación con la nueva
configuración aplicada (startup)
• Wakeup: Estado cuya
función principal es despertar la red.
• Startup: Estado cuya
función principal es la de iniciar la comunicación en la red.
• Normal active: Modo
normal de operación en el cual hay comunicación fluida Flexray.
• Normal passive: Estado
al cual se llega si se detectan leves errores en la comunicación En caso de
recuperarse de esos errores puede volver a pasar a normal active. En caso
contrario, pasará al estado HALT.
• Halt: Estado al que se
llega si se detecta error grave en la comunicación, o por orden directa del
host. Para volver a comunicarse, hará falta realizar de nuevo la secuencia de
estados desde el inicio del POC.
A continuación
describiremos los principales procesos controlados por el POC y que son
llamados los “core mechanisms”, ya que son la base de FLEXRAY.
2.1.1 Coding and decoding
El subproceso
Coding and decoding se encarga de realizar las funciones de Codificar y
Decodificar las tramas. Forman parte de este proceso los mecanismos Majority
Voting y Bit Strobing vistos en el apartado 2.1.4.1. y 2.1.4.2. para
decodificar las tramas. Hay que añadir que la forma de codificarlas también lo
vimos en el apartado 2.1.3.3.
Lo que vamos a ver a continuación son los
campos a nivel lógico que conforman la trama Flexray.
En un primer
nivel podemos distinguir entre 3 bloques: Cabecera, Datos y CRC. Como vemos la
trama puede variar entre 8 y 262 bytes.
El significado
de los campos de cabecera es el siguiente:
• Reserved
bit: Bit reservado del protocolo para futuros usos.
• Payload
Preamble indicator: Sirve para indicar que los primeros bytes del segmento
de datos también son de cabecera. Esto se usa para tareas de mantenimiento y
gestión de la red o para indicadores en las tramas dinámicas.
• Null Frame Indicator: Indica si la trama lleva datos
o no. A veces, por ejemplo en tramas de sincronismo, se envía una trama para
mantener el sincronismo pero no lleva
datos asociados. Cabe indicar que la situación contraria se puede dar. Es
decir, se puede enviar una trama de sincronía que además contenga datos.
• Sync
Frame Indicator: Indica si la trama es de sincronismo. Estas tramas que
sirven para sincronizar todos los nodos a la base de tiempos global de Flexray.
• Startup
Frame Indicator: Indica si es una trama de Startup. Es decir, si es una
trama de inicio de comunicación. En el apartado 2.2.3. se describe su uso.
• Frame
ID: Identificador único de la trama asociado a un nodo. Define el slot en
el cual se envía la trama.
• Payload
length: Define la longitud del campo de datos enviado con la trama.
• Header
CRC: CRC de cabecera. Sirve para agilizar el protocolo. Si un nodo detecta
un error en el CRC de cabecera descarta directamente la trama.
• Cycle
Count: indica el ciclo de comunicación en el que nos encontramos.
2.1.1.1 Channel idle detection
Dentro del
apartado coding and decoding cobra especial relevancia un subproceso llamado
Channel idle detection el cual detecta si el canal está libre. Como comentamos
en la capa física (apartado 2.1.3.2.), el Transceiver traducía los 3 símbolos
eléctricos (1, 0 y libre) tan sólo a dos lógicos (1 y 0).
El mecanismo que
usa Flexray para determinar si el canal está libre es contar el número de unos
seguidos que se reciben y si pasa un determinado umbral, se considera el canal
libre. Esto funciona ya que cualquier trama Flexray, lleva intercalado cada 8
bits un BSS (Byte Start Sequence) en el cual siempre hay un flanco
descendiente, forzando un cero.
2.1.2. Frame and Symbol Processing
El proceso Frame and Symbol
Processing, se encarga de recoger los datos de salida del “Coding and Decoding
process”, comprobar errores tanto sintácticos, semánticos como de
sincronización y en caso positivo pasar la información relevante al CHI
(Controller Host Interface) para que el uC pueda leer el mensaje recibido.
2.1.3. Media Acces Control
El protocolo
Flexray se basa en un ciclo de comunicación recurrente. Este ciclo está
dividido en 4 segmentos:
• Static Segment: El Static Segment está compuesto
por slots de medida fija. Cada slot está asociado a una Frame ID. Por su parte
cada Frame ID está asociada a un nodo, de manera que cada nodo sabe siempre en
qué slot o slots le toca enviar. Este segmento es de carácter obligatorio y
siempre se comporta igual. Es decir, las tramas estáticas siempre se envían.
• Dynamic Segment: El Dynamic Segment está compuesto
por dynamic slots la medida de los cuales es variable y se establece un orden
de envío por prioridad de ID, similar al CAN. Es decir, si dos nodos en el
segmento dinámico luchan por transmitir, ganará el de la ID más baja. Además el
tamaño de la trama no es fijo, así que el primer nodo en coger el control del
bus podría agotar el Dynamic Segment. Este segmento es de carácter opcional, a
diferencia del estático.
• Symbol Window: En el Symbol Window se pueden
enviar los MTS para gestión de la red. Es de carácter opcional y raramente se
usa.
• Network Idle Time: Al final del ciclo se deja el
canal un cierto tiempo libre para poder ajustar el tiempo de ciclo a la durada
fija determinada. Este segmento es de carácter obligatorio.
En el siguiente diagrama se aprecian las diferentes
posibilidades de configurar el ciclo de comunicación.
2.1.3.1. Unidades de tiempo en Flexray
Flexray es un
protocolo basado en una base de tiempos global. Con lo cual la gestión del
tiempo es crítica para el acceso al medio. Por ello tiene diferentes unidades
de tiempo:
• Microtick: Unidad de tiempo básica dependiente el
oscilador local de cada nodo.
• Macrotick: Unidad de tiempo básica de la red.
Todos los nodos tienen el mismo valor de Macrotick. Así pues si dos nodos
tienen un oscilador local diferente tendrán diferente número de microticks por
macrotick, pero al final el valor de macrotick será el mismo para todos.
• Cycle: Es una unidad de tiempo propia de la red y
es el tiempo del ciclo de comunicación medido en macroticks.
Para ver más clara la diferencia entre estos
tres conceptos fijémonos en el siguiente diagrama:
Una vez visto los diferentes segmentos que
forman el ciclo de Flexray y entendidas las unidades básicas de tiempo, veamos
como está dividido un ciclo de comunicación en unidades de tiempo:
El Static
Segment, está dividido en un número fijo de static slots que a su vez están
formados por un número fijo de macroticks. Al inicio de cada Static Slot, el
mecanismo ‘Clock Synchronization’ marca el instante en el cual ha se ha de
empezar a transmitir ese slot. A este instante, se le llama Static Slot Action
Point y es de vital importancia dada la naturaleza TDMA del protocolo.
En el Dynamic
Segment ocurre algo parecido pero en este caso se habla de Dynamic Slots,
formados por minislots y guiados por el Minislot Action point. Esta diferencia
entre Static slots y minislots radica en que en el segmento dinámico las tramas
no tienen por qué tener una medida estándar y cabe aprovechar al máximo las
unidades de tiempo, reduciendo su duración en macroticks.
En el Symbol
Window y el Network idle Time el tiempo se mide directamente en macroticks.
2.1.4. Clock Synchronization
Flexray es un
protocolo determinístico basado en la división del tiempo en ranuras donde cada
nodo sabe en qué ranura puede enviar y en cual no. Dada esta descripción, se
puede entender la gran importancia de mantener todos los nodos sincronizados
constantemente. De lo contrario, fácilmente un nodo no sincronizado podría al
transmitir invadir la ranura del vecino y provocar un fallo general de
comunicación. Es por eso, que el proceso Clock Synchronization cobra gran
relevancia en el protocolo Flexray.
Todo y que cada
nodo dispone de su propio oscilador, Flexray funciona con una base de tiempos
global a nivel de red. Esto lo consigue gracias a las tramas de sincronismo que
envían un mínimo de 2 nodos en una red de 2 ECUs o 3 en una red de 3 o más
ECUs. Estos nodos, llamados Coldstart nodes, son muy importantes tanto en el
inicio de la comunicación como en el sincronismo de la red. Suelen tener
osciladores muy precisos y marcan el tiempo al cual se han de ir adaptando el
resto de nodos.
La sincronización del reloj se basa en 2
subprocesos importantes:
2.1.4.1. Clock Synchronization Process.
El Clock
Synchronization Process (CSP) recoge los valores de las tramas de sincronía
enviadas por los diferentes Coldstart nodes de la red, los compara con los que
él había predecido y hace una estimación del valor correcto. El resultado lo
pasa al Macrotick Generation Process.
2.1.4.2. Macrotick Generation Process
El Macrotick
Generation Process (MTG), como indica su nombre, es el encargado de generar el
macrotick y del control de tiempos como el tiempo de ciclo o el tiempo de slot.
Así pues, con los datos que le pasa el CSP, efectúa las correcciones necesarias
para mantener el sincronismo del nodo:
·
• Correcciones de Offset: Indica
el número de microticks que hace falta añadir al NIT (Network idle Time) para
que el ciclo de comunicación Flexray comience en el momento adecuado. Se
calcula cada ciclo y se corrige en el NIT de los ciclos impares.
·
• Correcciones de Rate: Indica
el número de microticks por macrotick que hay que añadir (o substraer) para
adecuarse al tiempo de ciclo. Se calcula en los ciclos impares y se aplica
siempre.
2.2. Wake Up del Bus Flexray
En Flexray, como en otros
muchos sistemas electrónicos, es posible encontrarnos con ECUs y transceivers
en estado sleep como método de ahorro de energía. Por eso, antes de iniciar una
comunicación Flexray, es necesario un procedimiento de Wake Up que despierte
todos los nodos. Para que este procedimiento funcione, el mínimo requerimiento
es que todos los Transceiversse encuentren
alimentados, aunque se encuentren en estado de baja energía. Si esto sucede, el
Transceiver que reciba una orden de WakeUp (un Wake Up pattern formado por una
cadena de símbolos WakeUp) por uno de sus canales del bus podrá comunicarse
directamente con su host y despertarlo. El host será responsable de determinar
si el otro canal está dormido y en cuyo caso será responsable de despertarlo.
Un hecho
importante a considerar es que está prohibido intentar despertar los dos
canales a la vez, puesto que en caso que hubiera un nodo fallando podría
perturbar los dos canales y impedir la comunicación Flexray.
Teniendo todo esto en cuenta veamos un ejemplo de como se
despertaría una red de 4 nodos y dos canales:
Como
vemos el nodo 4 sólo está conectado a un canal, en este caso el B. Esta
situación se puede dar siempre que el nodo no sea crítico.
1.
Siempre ha de haber un host que tome la iniciativa de iniciar la comunicación
debido a un evento externo.
2. Se
inicializa el CC con los parámetros de configuración deseados.
3. El
host despierta sus dos transceivers (Canal A y Canal B)
4. El
host lanza la orden al CC de que pase al estado de WakeUP. El CC genera un
Wake-up pattern que es enviado al transceiver del canal A para que sea
transmitido por el bus.
5. Todos los transceivers del canal A se despiertan por el
wake-up pattern y a la vez despiertan a sus hosts.
6. Los hosts 2 y 3 de despiertan.
7. Los hosts 2 y 3 despiertan sus CCs y los inicializan.
8. Los hosts 2 y 3 chequean si los transceivers del Canal B
se han despertado. En caso contrario los despiertan.
9. Una vez que los transceivers
del canal B están despiertos, los hosts verifican que los 2 canales estén
despiertos. Si el canal B no está despierto, dan la orden a sus CCs para que
envíen un Wake-up pattern al canal B. Esto hace despertar los transceivers que
no se habían despertado en ese canal.
10. El host del nodo 4, que sólo estaba conectado al Canal
B es despertado.
11. El host del nodo 4 despierta a su CC.
Una vez que los
2 canales han sido despertados se puede empezar la fase de start-up, el
establecimiento de la conexión Flexray. Es importante destacar que en la fase
de Wake Up intervienen tanto transceivers, CC y host. Ninguno de estos puede
efectuar el Wake-up por sí sólo.
2.3. Startup del bus Flexray
Una vez
despertados los nodos con el procedimiento de Wake-up, el paso siguiente
inmediato es el de Startup, con el objetivo de establecer la conexión
sincronizando todos los nodos. Es el momento de introducir otro concepto, el
Coldstart node.
Los nodos
Coldstart, suelen ser los mismos que los nodos encargados de enviar las tramas
de sincronía. De hecho, por obligación un nodo Coldstart ha de estar
configurado para enviar tramas de sincronía. Al igual que pasaba con los Sync
nodes, ha de haber un mínimo de 2 Coldstart nodes en una red de 2 nodos y un
mínimo de 3 en una red de más nodos.
Los nodos
Coldstart son los encargados de tomar la iniciativa en la fase de Startup.
Distinguimos dos tipos: el Leading Coldstart node y el Following Coldstart
node. En un principio todos los Coldstart nodes competirán por iniciar la
comunicación pero sólo habrá uno que ganará y este será el Leading Coldstart
node. El resto se convertirán automáticamente en Following Coldstart nodes. El
mecanismo para asignar el Leading Coldstart node es el siguiente:
Todos los
nodos Coldstart después del wake-up, enviarán un CAS (Collision Avoidance
Symbol) al bus. El primero que envíe este símbolo será el Leading
Coldstart
node. El resto, recibirán el CAS y interpretarán que ya hay un Leading
Coldstart node.
El
proceso de startup tiene una serie de fases. Veamos con un la ayuda de un
diagrama ejemplo el funcionamiento:
Partimos
de una situación ficticia de 3 nodos, 2 son Coldstart y el otro no. (En
realidad en una red de 3 nodos deberían ser los 3 Coldstart, el ejemplo sólo
sirve para ilustrar el funcionamiento)
1. Los
nodos vienen de ser despertados en la fase de Wake-up. Así pues, pasan al
estado ready del POC y de allí los nodos Coldstart A y B toman la iniciativa.
2. El
primer estado por el que pasan los nodos A y B es el Coldstart listen. En este
estado han de escuchar el canal para ver si hay algún otro nodo Coldstart que
haya enviado ya un CAS. Cuando al nodo A se le acaba el tiempo de espera y no
ha recibido un CAS, envía un CAS al bus para que el resto de nodos sepan que ya
hay un “Leading Coldstart node”. Así pues, el resto de nodos Coldstart tomarán
el rol de Following Coldstart nodes. El nodo C no es Coldstart y por tanto no
interviene de momento.
3. Una
vez determinado el Leading Coldstart node, éste ha de tomar la iniciativa
empezando a enviar tramas de start-up que son a la vez tramas de sincronía. El
resto de nodos va sincronizándose conforme al nodo A. Al cabo de 4 tramas de
start-up los nodos Following Coldstart nodes se integran en la red y empiezan a
enviar también sus tramas de start-up.
4. Una
vez, todos los Coldstart nodes están integrados, el resto de nodos se integran
en la red pasando todos a normal active y pueden empezar a enviarse tramas de
datos. Es importante notar que el nodo C no envía ninguna trama de sincronía,
si no que con las tramas que han ido enviando los nodos Coldstart se ha ido
sincronizando.
Finalmente, después de la fase de Wake-up y la fase de Start-up,
ya tenemos la conexión Flexray entre todos los nodos operativa.
MAPA MENTAL
