ES2253100A1 - Red de comunicaciones de protocolo can con topologia en estrella. - Google Patents

Abstract

Red de comunicaciones de protocolo CAN con topología en estrella que comprende al menos dos nodos conectados a dicha red a través de un acoplador en estrella, caracterizada por el hecho de que dicho acoplador es un hub que comprende un circuito que implementa una función AND, por lo menos un transceptor por cada uno de los nodos, e implementando dicho hub medios de tratamiento de fallos.

Description

Red de comunicaciones de protocolo CAN con topología en estrella.

La presente invención se refiere a una red de comunicaciones de protocolo CAN con topología en estrella.

Antecedentes de la invención

En el ámbito industrial, especialmente en aplicaciones tales como automoción, aviación o robótica, se utilizan diferentes buses de campo. Mediante la utilización de dichos buses es posible la transmisión de información entre las distintas partes de un sistema. Estos buses de campo pueden ser de tipo CAN, TTP, etc... en función del protocolo de comunicación que emplean.

El protocolo de comunicación CAN (Controller Area Network) está en la actualidad prácticamente estandarizado en la mayoría de vehículos. Este tipo de protocolo y por lo tanto, este tipo de bus, proporciona buena fiabilidad y buen funcionamiento en tiempo real a muy bajo coste.

De todas formas, en sistemas distribuidos como los que se construyen con redes CAN, un fallo en el subsistema de comunicaciones puede producir un error en dicho subsistema que puede derivar en una avería de todo el sistema. En concreto, las redes de comunicaciones basadas en el bus CAN presentan también ciertos problemas en cuanto a garantía de funcionamiento causados por la topología en bus característica de estas redes.

Por ejemplo, un fallo en la interfaz con el bus de uno de los nodos puede generar errores que se propaguen a los nodos restantes y que puedan impedir la comunicación entre otros nodos de la red.

Así, las redes CAN que se conocen pueden presentar diversos fallos en componentes que pueden provocar una avería generalizada del subsistema de comunicaciones, es decir, pueden impedir la comunicación entre más nodos que los directamente afectados por un fallo.

Dichos fallos pueden ser, por ejemplo, fallos consistentes en que un nodo envía permanentemente el mismo valor a la red, conocidos en inglés como "stuck-at-node fault". En CAN, estos fallos pueden ser de dos tipos, en función de cuál es el valor que el nodo envía permanentemente a la red. Si dicho valor es un "0" (lo que en CAN se denomina valor dominante) el fallo se conoce como "stuck-at-dominant" y si dicho valor es un "1" (lo que en CAN se denomina valor recesivo) se conoce como "stuck-at-recessive". Un fallo de tipo "stuck-at-dominant" puede producir una avería generalizada del subsistema de comunicaciones, ya que en una red CAN basta que un único nodo envíe el valor dominante para que todos los nodos reciban ese valor; mientras que para que todos los nodos reciban el valor recesivo es preciso que todos ellos envíen el valor recesivo. Por este motivo se dice que el nivel físico de CAN es equivalente a una función lógica AND de la contribución de cada uno de los nodos.

Otro fallo que se puede dar es un fallo de medio de comunicación cortocircuitado (en inglés, "shorted medium fault"), que ocurre cuando se produce un cortocircuito a tierra o a alimentación y que produce una avería generalizada de las comunicaciones.

Otro tipo de fallo potencial, es el fallo de medio de comunicación partido, (en inglés, "medium partition fault"), que hace que la red quede dividida en varias subredes o particiones de red (en inglés, "network partitions") y que impide que los nodos que hayan quedado en particiones de red diferentes puedan comunicarse entre sí.

También se pueden dar fallos consistentes en que un nodo o medio parlotea incesantemente en la red, (en inglés, "babbling idiot fault") como, por ejemplo, cuando el nodo envía continuamente valores aleatorios a la red, (en inglés, "bit-flipping fault"). En algunos casos los fallos de tipo "babling idiot" no producen una avería generalizada de las comunicaciones aunque sí deterioran el funcionamiento del subsistema de comunicaciones de la red.

Para mejorar la fiabilidad de las redes CAN existen diseños que cuentan con redundancia de bus. De este modo, se intenta dotar al sistema de los medios necesarios para tolerar algunos de los fallos anteriormente mencionados. Sin embargo, a pesar del incremento de la fiabilidad conseguido, las redes de este tipo pueden todavía sufrir una avería generalizada si se producen ciertos fallos de los mencionados.

En otros buses de campo, como el TTP, una forma habitual de mejorar la fiabilidad es utilizar una topología en estrella en lugar de la topología de bus. Existen también buses de campo de tipo CAN con topología en estrella.

Por ejemplo, en el artículo de Gianluca Cena, Luca Durante y Adriano Valenzano, "A new CAN-like field network based on a star topology" publicado en el "Computer Standards & Interfaces" de Marzo de 2001, se describe una red de comunicaciones con topología en estrella, denominada StarCAN, que permite multiplicar la longitud de la red CAN o las velocidades de transmisión por 10. En dicha configuración, la estructura convencional en bus se sustituye por una topología en estrella, donde el centro de la estrella tiene la función de realizar operaciones no triviales. De esta manera, se puede mantener la técnica de arbitraje propia del protocolo CAN a pesar del aumento en los retrasos en la propagación. Esta arquitectura del bus CAN en estrella cuenta con un acoplador lógico en estrella que conecta los diferentes nodos. Cada nodo está conectado a dicho acoplador mediante un par de conexiones (en inglés, "links"), una para cada uno de los sentidos de comunicación.

Sin embargo, el objetivo de la red StarCAN es aumentar la longitud o velocidad de transmisión de la red CAN y no el de aumentar la garantía de funcionamiento de la red.

De hecho, ninguna de las redes de tipo CAN con topología en estrella que han sido diseñadas hasta este momento, ya sean en esquema de tipo estrella pasiva (en inglés, "passive star") o en esquema de tipo estrella activa (en inglés "active star") o el StarCAN mencionado anteriormente, presenta mecanismos especialmente diseñados para impedir la propagación de los errores causados por todos los fallos descritos anteriormente. Por lo que son tan vulnerables a determinados fallos en los brazos de la estrella como lo es un bus.

Descripción de la invención

El objetivo de la presente invención es resolver los inconvenientes antes mencionados, desarrollando una red de comunicaciones de protocolo CAN con topología en estrella que presenta las ventajas que se indican a continuación.

La red de comunicaciones de la presente invención comprende al menos dos nodos conectados a dicha red a través de un acoplador en estrella y está caracterizada por el hecho de que dicho acoplador es un hub que comprende un circuito que implementa una función AND, por lo menos un transceptor por cada uno de los nodos, e implementando dicho hub medios de tratamiento de fallos.

Por función AND, nos referimos a aquella que realiza un operador o puerta lógica AND.

Se conoce como transceptor al dispositivo que realiza funciones tanto de transmisión como de recepción, utilizando componentes de circuito comunes para ambas funciones.

Gracias a estas características la red de la presente invención consigue detectar y resolver situaciones en las que un único fallo en la red de comunicaciones, por ejemplo, en uno de los nodos, impide las comunicaciones entre más de un nodo. Dicho objetivo se consigue al utilizar una topología en estrella combinada con un hub especialmente diseñado. Por su posición en el centro de la estrella, el hub tiene una visión privilegiada de lo que ocurre en la red y puede así implementar medios de tratamiento de fallos más adecuados. De este modo, el hub puede identificar y aislar los componentes que presentan fallos y así evitar que produzcan una avería generalizada en el subsistema de comunicaciones. El hub realiza así las funciones de detección de errores, bloqueando en los puertos del hub la propagación de los errores generados en los nodos averiados.

La red de comunicaciones de la presente invención, presenta la ventaja de que haciendo uso de una topología en estrella consigue aumentar la garantía de funcionamiento de la red. Esto es así a pesar de que el hub es un punto único de avería, es decir, un elemento cuya avería provocaría la avería generalizada de todo el sistema. Al tratarse del único elemento que presenta esta característica, su probabilidad de fallo puede ser fácilmente reducida, por ejemplo, colocándolo en una zona mejor protegida y por ello menos sometida a ruido y otras agresiones. Esto es más fácil de conseguir si hay solamente un punto único de avería, como ocurre en una topología en estrella, que si hay varios, como ocurre en un bus.

Es también una ventaja de la presente invención, el hecho de que mantiene las características básicas de las redes de protocolo CAN convencionales. Por ejemplo, para mantener las características de las redes CAN de transmisión de bits dominantes (que en esta implementación se corresponden con el valor "0") y recesivos (que en esta implementación se corresponden con el valor "1"), el hub implementa una función lógica AND de las transmisiones recibidas desde cada nodo.

Preferiblemente la red de comunicaciones de la presente invención está caracterizada por el hecho de que el hub comprende al menos un operador lógico AND que tiene como entrada o entradas la o las contribuciones de todos y cada uno de los nodos, y un operador lógico OR por cada nodo, lo que le permite habilitar o inhabilitar la contribución de cada nodo al valor final de cada bit.

Preferiblemente la red de comunicaciones de la presente invención está caracterizada por el hecho de que el hub comprende dos transceptores por cada uno de los nodos. Uno para el enlace que va del nodo al hub, que denominaremos ascendente (en inglés "uplink") y que se conecta a uno de dichos transceptores, y otro para el enlace que va del hub al nodo, que denominaremos descendente (en inglés "downlink") y que se conecta al otro transceptor.

En dicha realización preferida no es necesario multiplexar en el tiempo la información enviada por el nodo y el hub, ni tener como máximo tantos cables como brazos tenga la estrella. Igualmente mediante el uso de dos cables y dos transceptores el hub consigue diferenciar de una manera más sencilla la contribución de cada uno de los nodos al valor de cada bit.

Es también una ventaja de la presente invención el hecho de que se mantiene la sincronización de bit tal como se realiza en el protocolo CAN. Ello es posible porque las operaciones lógicas AND y OR así como las operaciones de los transceptores de los uplink y de los downlink en el hub se realizan en una fracción de tiempo sensiblemente inferior al tiempo que dura un bit en el protocolo CAN.

Como se precisa una respuesta rápida, la manera más sencilla de implementar la función AND es mediante hardware, en cuyo caso, lo más normal es utilizar un operador o puerta lógica.

Si se implementa mediante software es preciso usar alguna instrucción adecuada y además un procesador. Un procesador, si no es imprescindible para otras operaciones, resulta un recurso demasiado caro. De hecho, para poder implementar la respuesta del protocolo CAN existen implementaciones que utilizan un procesador pero precisan de procesadores potentes y por ello caros para conseguir la misma velocidad de funcionamiento del CAN.

De forma análoga al caso de la puerta AND, la manera más sencilla de implementar la función OR, ya que precisamos de una respuesta rápida es mediante hardware, en cuyo caso, lo más normal es utilizar un operador o puerta lógica OR.

Es pues una ventaja más de esta red de comunicaciones, el hecho de que el hub realiza sus operaciones en una fracción de tiempo inferior a un bit. En CAN, un bit dura 1 microsegundo aproximadamente, mientras que el retardo del conjunto formado por las mencionadas puertas lógicas y los transceptores del hub está en el orden de los cientos de nanosegundos. Además, si fuera preciso se puede alargar el tiempo que dura un bit (es programable en CAN) para que el resultado del hub se obtenga con suficiente antelación antes del instante en que los nodos muestrean el bit.

También se mantienen las características habituales del protocolo CAN en cuanto al formato de las tramas (en inglés, "frame format"), y a los mecanismos de detección de errores del canal y señalización de los mismos y por este motivo no se pierden las propiedades de tolerancia a fallos de CAN.

Resulta evidente, para un experto en la materia, que la manera más sencilla de conectar los nodos a los links que les unen con el hub es haciendo uso de también dos transceptores en cada uno de los nodos, uno para el uplink y uno para el downlink. La presencia de dos transceptores en cada nodo facilita la conexión a un controlador CAN estándar. Gracias a ello, y al hecho de que la red de la presente invención mantiene las características básicas del protocolo CAN, es posible la utilización de circuitos controladores CAN estándar en los nodos, lo que hace que la implementación de una red de estas características sea más económica.

Preferiblemente la red de comunicaciones de la presente invención está caracterizada por el hecho de que dichos medios de tratamiento de fallos comprenden diagnóstico y pasivación de fallos.

Tal como se ha dicho con anterioridad, el hub de la presente invención implementa medios de tratamiento de fallos. En particular, el hub puede detectar y aislar los componentes que presenten fallos de los tipos que podrían provocar un bloqueo de las comunicaciones entre todos los nodos, como son el "stuck-at-dominant fault" o el "bit-flipping fault". De esta forma el hub evita que tales fallos produzcan una avería generalizada en el subsistema de comunicaciones. El hub de la presente invención también detecta los componentes que presentan algunos fallos que no pueden provocar la avería generalizada del subsistema de comunicaciones, como pueden ser los "stuck-at-recessive faults".

Es pues una ventaja de la presente invención el hecho de que mediante dichos medios de diagnóstico de fallos (en inglés, "fault diagnosis") y de pasivación de fallos (en inglés, "fault passivation") conseguimos no sólo la detección de los fallos permanentes, sino también la desconexión de los nodos o conexiones afectadas por tales fallos, al objeto de impedir que dificulten la comunicación entre los demás nodos.

Breve descripción de los dibujos

Para mayor comprensión de cuanto se ha expuesto se acompañan unos dibujos en los que, esquemáticamente y sólo a título de ejemplo no limitativo, se representa un caso práctico de realización.

En dichos dibujos:

la figura 1 es una vista de una red genérica con topología en estrella;

la figura 2 es una vista de la red CAN con topología en estrella de la presente invención;

la figura 3 es una vista de la conexión típica de un nodo al resto de la red;

la figura 4 es un diagrama de la estructura interna del hub;

la figura 5 es un diagrama de la estructura interna de una unidad de habilitación e inhabilitación de las que se encuentran en el interior del hub.

Descripción de una realización preferida

La figura 1, muestra una configuración típica de una red de comunicaciones con topología en estrella, tal cómo se ha mencionado en los antecedentes de la invención. Tal y como puede verse en la figura 1, una red con topología en estrella tiene una serie de nodos 1, conectados mediante un link 2 cada uno, a un acoplador en estrella de tipo hub 3.

Tal y como puede verse en la figura 2, una realización preferida de la red de comunicaciones de la presente invención comprende una serie de nodos 1 (en la figura pueden verse cuatro nodos a modo de ejemplo) conectados a dicha red a través de un hub 3 mediante un enlace 2 (en inglés, "link"), formado por una doble conexión, un enlace ascendente ("uplink") 4 y un enlace descendente ("downlink") 5. Tal como muestra la figura 3, cada nodo 1 se conecta a su enlace 2 mediante dos transceptores 6, uno para el uplink 4 y uno para el downlink 5, y dos cables 7, uno para el transceptor 6 del uplink 4 y uno para el transceptor 6 del downlink 5. Estos dos cables 7 conectan cada uno de los transceptores 6 del nodo 1 con el controlador CAN 8 del nodo 1.

En la figura 4 se puede apreciar la estructura interna del hub en una realización preferida de la invención. El hub está constituido por tres módulos, un módulo de entrada/salida 9, un módulo acoplador 10 y un módulo de tratamiento de fallos 11.

El módulo de entrada/salida 9, está constituido por una serie de transceptores 6, dos para cada enlace. Como se observa en la figura 4, se asigna un transceptor 6 a cada enlace ascendente 4 para convertir la señal física recibida de cada nodo en un valor lógico que el hub pueda procesar. De igual modo, se asigna un transceptor 6 a cada enlace descendente 5 para convertir la señal lógica de salida del hub en una señal física que se pueda transmitir a cada nodo.

Tal como muestra la figura 4, el módulo acoplador está constituido por una puerta AND 12 que realiza el acoplamiento de las señales de los enlaces ascendentes 4 y una serie de puertas OR 13, una por cada uno de los enlaces ascendentes 4, que permiten al hub 3 habilitar o inhabilitar la contribución de cada uno de los enlaces ascendentes 4 a la puerta AND 12. Esta configuración junto con los transceptores 6 del módulo de entrada/salida 9 produce unos retrasos adicionales en la señal que reciben los nodos.

Como también puede observarse en la figura 4, el módulo de tratamiento de fallos 11 está constituido por una serie de unidades de habilitación e inhabilitación 14, una por cada uno de los enlaces ascendentes 4, que reciben la señal de salida de la puerta AND 12, y las señales de cada uno de los transceptores 6 correspondientes a cada uno de los enlaces ascendentes 4 de los nodos y generan una salida que se transmite a cada una de las puertas OR 13 del módulo acoplador 10.

Los mecanismos de diagnóstico de fallos del módulo de tratamiento de fallos 11 del hub requieren la observación de la contribución de cada nodo por separado, así como información sobre el estado actual de la trama que está siendo transmitida a todos los nodos. Gracias al uso de dos cables separados, uno para el uplink y otro para el downlink, es posible mantener separadas las contribuciones de cada nodo y por lo tanto es más fácil realizar el diagnóstico de fallos, es decir, localizar con rapidez y precisión dónde se ha producido un fallo.

Cuando se diagnostica un fallo en uno de los puertos del hub (entendemos como fallo en un puerto, tanto un fallo en el medio de comunicación como un fallo en el nodo), los mecanismos de pasivación de fallos del módulo de tratamiento de fallos eliminan la contribución de dicho puerto del sistema. Esto se consigue transmitiendo/fijando un valor lógico "1" en la salida de la unidad de habilitación e inhabilitación a la puerta OR correspondiente al puerto que presenta el fallo. Así la salida de dicha puerta OR tendrá también un valor lógico "1" que hará irrelevante la contribución de dicho puerto a la salida de la puerta AND. Esta acción es equivalente a desconectar dicho enlace y su nodo correspondiente, de la estrella.

En la figura 5 se puede apreciar la estructura interna de una unidad de habilitación e inhabilitación 14 de una realización preferida de la invención. Dicha unidad de habilitación e inhabilitación 14 consiste de un contador DBC 15 y su correspondiente unidad de control "DBC manager" 16, un contador NACK 17 y su correspondiente unidad de control "NACK manager" 18 y un contador BFC 19 y su correspondiente unidad de control "BFC manager" 20, así como un elemento para comparar los valores de la cuenta acumulada por cada contador con unos determinados valores prefijados. Este elemento se denomina "threshold control" 21.

Al analizar con detenimiento la estructura interna de la unidad de habilitación e inhabilitación 14 podemos entender mejor cómo funcionan los mecanismos de diagnóstico de fallos del módulo de tratamiento de fallos.

Por ejemplo, para diagnosticar un fallo "stuck-at-dominant" en un puerto, la unidad de habilitación e inhabilitación 14 correspondiente incluye el contador DBC 15 y su correspondiente unidad de control "DBC manager" 16, que sirven para contar el número de bits dominantes recibidos de manera consecutiva en ese puerto. El contador DBC 15, se incrementa con cada bit dominante y se pone a cero al recibir un valor recesivo. El valor acumulado por el contador es continuamente comparado a un valor máximo permitido de bits dominantes consecutivos. Cuando el valor del contador excede el valor máximo prefijado, el "threshold control" 21 transmite un valor de salida "1" que va a la puerta OR correspondiente a ese puerto. De esta forma se impide que un fallo "stuck-at-dominant" en un solo puerto provoque que todos los nodos reciban bits dominantes indefinidamente y no puedan comunicarse entre sí.

De forma similar a lo que se acaba de describir, la unidad de habilitación e inhabilitación 14 también permite diagnosticar un fallo "stuck-at-recessive" en un puerto. A pesar de que debido a las características de CAN los fallos de tipo "stuck-at-recessive" no pueden bloquear las comunicaciones de los demás nodos, en esta realización preferida se ha considerado importante poder detectar tales fallos. La capacidad de detectar fallos de "stuck-at-recessive", fallos que en un bus CAN no son triviales de detectar, es el primer paso para poderlos tolerar por parte del resto del sistema. En concreto, el contador NACK 17 es incrementado por su NACK manager 18 cada vez que éste detecta que el nodo correspondiente ha omitido la transmisión del bit de ACK que debería transmitir hacia el final de cada trama, según el protocolo CAN, para indicar que ha recibido la trama correctamente. Cuando el valor del contador NACK 17 excede un valor máximo prefijado, el "threshold control" 21 no transmite un valor de salida "1" a la puerta OR correspondiente a ese puerto (no es necesario), sino que registra internamente que el nodo en cuestión está averiado.

El último mecanismo de diagnóstico de fallos que en esta realización preferida se ha incluido en cada una de las unidades de habilitación e inhabilitación 14 del módulo de tratamiento de fallos es el que permite identificar fallos de tipo "bit-flipping". Estos fallos son los que se producen cuando un componente del sistema, por ejemplo un nodo, envía continuamente valores aleatorios a la red. Para diagnosticar este tipo de fallos cada unidad de habilitación e inhabilitación 14 incluye el contador BFC 19 y su correspondiente unidad de control "BFC manager" 20. Esta unidad es capaz de detectar las situaciones en las que el puerto correspondiente recibe bits erróneos de acuerdo con las especificaciones del protocolo CAN. Cuando estas situaciones se producen, el contador BFC 19 es incrementado y cada vez que una trama completa es transmitida sin errores, el contador BFC 19 es decrementado. Cuando el valor del contador excede el valor máximo prefijado, el "threshold control" 21 transmite un valor de salida "1" que va a la puerta OR correspondiente a ese puerto. De esta forma se impide que un fallo de tipo "bit-flipping" en un solo puerto provoque que todos los nodos reciban bits erróneos indefinidamente y no puedan comunicarse entre sí (ya que cada vez que se transmite un bit erróneo el protocolo CAN interrumpe la transmisión de la trama y la retransmite posteriormente).

A pesar de que se ha descrito y representado una realización concreta de la presente invención, es evidente que el experto en la materia podrá introducir variantes y modificaciones, o sustituir los detalles por otros técnicamente equivalentes, sin apartarse del ámbito de protección definido por las reivindicaciones adjuntas.

Claims (4)

1. Red de comunicaciones de protocolo CAN con topología en estrella que comprende al menos dos nodos (1) conectados a dicha red a través de un acoplador en estrella, caracterizada por el hecho de que dicho acoplador es un hub (3) que comprende

un circuito que implementa una función AND;

por lo menos un transceptor (6) por cada uno de los nodos (1);

e implementando dicho hub (3) medios de tratamiento de fallos.

2. Red de comunicaciones según la reivindicación 1, caracterizada por el hecho de que el hub (3) comprende al menos un operador lógico AND (12) que tiene como entrada o entradas la o las contribuciones de todos y cada uno de los nodos (1), y un operador lógico OR (13) por cada nodo (1).

3. Red de comunicaciones según las reivindicaciones 1 o 2, caracterizada por el hecho de que dicho hub (3) comprende dos transceptores (6) por cada uno de los nodos (1), uno para el uplink (4) y uno para el downlink (5).

4. Red de comunicaciones según las reivindicaciones 1, 2 o 3, caracterizada por el hecho de que dichos medios de tratamiento de fallos comprenden diagnóstico y pasivación de fallos.