ES2270724A1 - Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. - Google Patents
Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. Download PDFInfo
- Publication number
- ES2270724A1 ES2270724A1 ES200502292A ES200502292A ES2270724A1 ES 2270724 A1 ES2270724 A1 ES 2270724A1 ES 200502292 A ES200502292 A ES 200502292A ES 200502292 A ES200502292 A ES 200502292A ES 2270724 A1 ES2270724 A1 ES 2270724A1
- Authority
- ES
- Spain
- Prior art keywords
- hub
- hubs
- nodes
- node
- contributions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 63
- 230000002457 bidirectional effect Effects 0.000 title claims abstract description 12
- 238000010168 coupling process Methods 0.000 claims abstract description 24
- 230000008878 coupling Effects 0.000 claims abstract description 23
- 238000005859 coupling reaction Methods 0.000 claims abstract description 23
- 238000000034 method Methods 0.000 claims abstract description 10
- 238000003745 diagnosis Methods 0.000 claims description 5
- 238000001514 detection method Methods 0.000 claims description 4
- 238000002161 passivation Methods 0.000 claims description 3
- 230000006833 reintegration Effects 0.000 claims description 3
- 230000008901 benefit Effects 0.000 abstract description 13
- 230000015556 catabolic process Effects 0.000 description 21
- 230000007246 mechanism Effects 0.000 description 19
- 230000005540 biological transmission Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000005192 partition Methods 0.000 description 6
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 5
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000011664 signaling Effects 0.000 description 4
- 230000000295 complement effect Effects 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000008030 elimination Effects 0.000 description 2
- 238000003379 elimination reaction Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 206010001488 Aggression Diseases 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000016571 aggressive behavior Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000009528 severe injury Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000003466 welding Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/44—Star or tree networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
Abstract
Red de comunicaciones de protocolo can con topología en estrella replicada y procedimiento de acoplamiento de dicha red. La red comprende al menos dos nodos conectados a través de al menos un primer hub, y se caracteriza porque comprende al menos un segundo hub idéntico al primero, cada par de hubs está interconectado por al menos dos enlaces bidireccionales, e implementa medios de tratamiento de fallos. El procedimiento de acoplamiento de dicha red se caracteriza porque el hub acopla las contribuciones de los nodos conectados a él y acopla dicho resultado con las contribuciones que recibe de los otros hubs. Presentan la ventaja de la eliminación de cualquier punto de avería severa, y así esta red puede ser utilizada en los sistemas de control críticos más exigentes en términos de tolerancia a fallos y fiabilidad.
Description
Red de comunicaciones de protocolo CAN con
topología en estrella replicada y procedimiento de acoplamiento de
dicha red.
La presente invención se refiere a una red de
comunicaciones de protocolo CAN con topología en estrella replicada
y a un procedimiento de acoplamiento de dicha red.
En el ámbito industrial, especialmente en
aplicaciones tales como automoción, aviación o robótica, se
utilizan diferentes redes de comunicaciones (también llamados buses
de campo). Mediante la utilización de dichas redes es posible la
transmisión de información entre las distintas partes de un
sistema. Estas redes de comunicaciones pueden ser de diferentes
tipos, dependiendo del protocolo de comunicaciones que empleen:
CAN, TTP, etc.
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 red, proporciona buena fiabilidad y buen
funcionamiento en tiempo real a muy bajo coste.
De todas maneras, dichas redes de comunicaciones
CAN presentan varios problemas de garantía de funcionamiento que
son causados por la topología bus del protocolo. La principal
desventaja de dicha topología es que la estructura de la red
presenta múltiples puntos donde un fallo puede impedir la
comunicación entre varios nodos. 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. Cualquier punto de la red
de comunicaciones cuyo fallo es capaz de provocar que haya más de
un nodo que no pueda comunicarse con varios de los otros nodos será
denominado en el presente documento "punto de avería severa".
Esta definición de "punto de avería severa" incluye el
concepto comúnmente conocido como "punto único de avería". Un
"punto único de avería" es aquel "punto de avería severa"
cuyo fallo provoca que ningún nodo se pueda comunicar, haciendo que
toda la red de comunicaciones se averíe.
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
faults". 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 severa 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
("shorted medium fault" en inglés), 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 envía
continuamente valores aleatorios y erróneos a la red (en inglés,
"bit-flipping faults"). En este caso, incluso
si un nodo intenta enviar un flujo de datos correcto, éste flujo es
destruido por los bits dominantes del flujo
bit-flipping. Algunas posibles causas de este tipo
de fallo son: un nodo dañado que envía valores erróneos, una
soldadura estropeada en un conector del medio que genera bits
incorrectos, etc.
Otra forma habitual de mejorar la fiabilidad en
redes de comunicaciones es utilizar una topología en estrella en
lugar de la topología de bus. Básicamente, existen dos
clasificaciones de redes con topología en estrella: estrella pasiva
("passive star" en inglés) y estrella activa ("active
star" en inglés). El centro de una estrella pasiva simplemente
acopla directamente las señales físicas de cada brazo; mientras que
en las activas, para cada bit, el centro tiene en cuenta el bit
recibido de cada brazo, calcula el bit resultante de acoplar cada
uno de estos bits y retransmite dicho bit hacia cada uno de los
nodos. Algunas redes de comunicaciones, como TTP, ya han adoptado
una topología en estrella para aumentar la fiabilidad de la red.
Existen también redes de tipo CAN con topología en estrella. Las
estrellas pasivas que existen para CAN presentan varias desventajas
desde el punto de vista eléctrico o desde el punto de vista del
desempeño, y no incorporan ningún mecanismo para impedir la
propagación de los errores (mecanismos de contención de errores)
causados por ninguno de los fallos descritos anteriormente. Las
estrellas activas para CAN solucionan los problemas eléctricos y de
desempeño de las pasivas, pero o bien no incluyen mecanismos de
contención de errores, o bien éstos son insuficientes. Por lo que
las soluciones descritas anteriormente son tan vulnerables a
determinados fallos en los brazos de la estrella como lo es un
bus.
De hecho, tan sólo existe una red de tipo CAN
con topología en estrella que presente mecanismos especialmente
diseñados para impedir la propagación de los errores causados por
fallos. Dicha red se describe en la solicitud de patente 200402207
"red de comunicaciones de protocolo CAN con topología en
estrella" propuesta, entre otros, por los mismos autores de la
presente solicitud de patente. Dicha solución tiene medios de
tratamiento de fallos mejorados que reducen los múltiples "puntos
de avería severa" existentes en una red CAN con topología bus a
un solo "punto único de avería", localizado en el hub (también
llamado acoplador en estrella) incrementando de esta manera la
garantía de funcionamiento de la red. Es importante notar que al
ser el hub el único elemento que es un "punto único de avería"
la probabilidad de avería severa en la red de comunicaciones puede
reducirse fácilmente con sólo disminuir la probabilidad de fallo
del hub. Esto puede hacerse, por ejemplo, colocando el hub en una
zona mejor protegida y por ello menos sometida a ruido y otras
agresiones. La reducción de la probabilidad de avería de la red de
comunicaciones 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. Sin embargo, a pesar de que
dicha red de comunicaciones puede ser adecuada para muchos sistemas
tolerantes a fallos, puede no serlo para algunos sistemas críticos
con demandas aún más estrictas de garantía de funcionamiento.
La eliminación de todos los "puntos de avería
severa" en una red de comunicaciones se puede conseguir con
redundancia temporal o espacial. De todos modos, las averías
permanentes, como por ejemplo una red que queda dividida en varias
subredes, sólo se pueden tolerar con redundancia espacial. Con el
fin de obtener mayor "garantía de funcionamiento" existen
protocolos que ofrecen arquitecturas basadas en buses replicados
(FlexCAN), y en algunos casos también, basadas en estrellas
replicadas (TTP, FlexRay). En el artículo de J. R. Pimentel y J. A.
Fonseca, "FlexCAN: a flexible architecture for highly dependable
embedded applications" se presenta una red de comunicaciones CAN
basada en nodos y buses triplicados. Los nodos se coordinan a
través de un software que utiliza temporizadores para controlar la
transmisión y recepción en los canales. El inconveniente de esta
solución es que está basada en topología bus, por lo que siguen
existiendo varios "puntos de avería severa". Por ejemplo, nada
impide que un nodo defectuoso envíe información errónea
continuamente a todos los canales.
Hasta la fecha no existe ninguna red CAN que
elimine todos los puntos de avería severa.
Según un primer aspecto, la invención se refiere
a "una red de comunicaciones de protocolo CAN con topología en
estrella replicada". Con la red de comunicaciones de la
invención se consigue resolver los inconvenientes antes
mencionados.
La red de comunicaciones de protocolo CAN con
topología en estrella de la invención es del tipo que comprende al
menos dos nodos conectados a dicha red a través de al menos un
primer hub (o acoplador en estrella) y se caracteriza porque
comprende al menos un segundo hub idéntico al primero, porque cada
par de hubs está interconectado por al menos dos enlaces
bidireccionales y porque el conjunto de la red implementa medios de
tratamiento de fallos.
En particular, cada enlace de un nodo a un hub,
así como cada enlace que interconecta a un par de hubs es
bidireccional. De ahora en adelante, en este documento se hará
referencia a dichos enlaces como "links" e "intralinks"
respectivamente.
En dicha red de comunicaciones, si un hub falla,
los nodos pueden comunicarse a través de los hubs no averiados.
Concretamente, si se utilizan N hubs (con N mayor o igual a dos),
la red de comunicaciones tolerará el fallo de N-1
hubs. Por lo tanto la principal ventaja en dicha red es la
eliminación de cualquier punto de avería severa (y consecuentemente
cualquier punto único de avería), y así esta red puede ser utilizada
en los sistemas de control críticos más exigentes en términos de
tolerancia a fallos y fiabilidad.
Además, en dicha red de comunicaciones el
tráfico de datos está replicado con el fin de que dicho tráfico no
se pierda por el fallo de algún hub. Cada nodo envía
simultáneamente los mismos datos a todos los hubs y todos y cada
uno de los hubs se utilizan para transmitir simultáneamente los
mismos bits a todos los nodos. Sin embargo, debido a los mecanismos
de señalización de error del protocolo CAN, un simple bit erróneo en
uno de los hubs, debido por ejemplo a interferencias
electromagnéticas transitorias, puede hacer que el tráfico a través
de ese hub evolucione de forma diferente al resto. La única forma
de asegurar que el tráfico de datos sea idéntico en todos los hubs
es haciendo que cada hub acople las contribuciones de los nodos
conectados a él con las contribuciones de los nodos conectados a
cada uno de los otros hubs. Se entiende por acoplamiento a la
acción y efecto de unir un conjunto de señales o contribuciones con
el fin de obtener una señal resultante cuyo valor dependa del valor
de todas y cada una de dichas contribuciones.
En la presente invención cada hub recibe las
contribuciones de los nodos conectados a otro hub a través del
intralink que los interconecta. De ahora en adelante, a la señal que
un hub calcula como acoplamiento de las contribuciones de los nodos
conectados a él y que envía a cada uno los otros hubs a través de
los correspondientes intralinks se denominará "contribución de
ese hub". Por otro lado, cada hub envía a los nodos conectados a
él la señal que calcula acoplando las contribuciones de los nodos
conectados a él con las contribuciones de los nodos conectados a
cada uno de los otros hubs. Esta última señal se denominará de
ahora en adelante "señal resultante de ese hub".
Gracias a que cada hub acopla las contribuciones
de sus nodos con las contribuciones de los otros hubs, la presente
invención presenta la ventaja de que cualquier nodo puede estar
conectado a todos o varios de los hubs, para poder tolerar la
pérdida de conexión con uno de ellos debido, por ejemplo, a un fallo
en el link (enlace entre nodo y hub), o puede estar conectado sólo
a uno de ellos. Este hecho de que un nodo no necesite conectarse a
todos los hubs es posible porque independientemente del número de
hubs al que un nodo esté conectado, las transmisiones del nodo
estarán acopladas en la señal resultante que todos los hubs envían
a los nodos y, por tanto, su contribución estará incluida en el
tráfico de todos los hubs. Esto permite ahorrar costes en el
cableado para aquellos nodos cuya presencia en la red de
comunicaciones sea menos crítica y, por tanto, no necesiten estar
conectados directamente a muchos hubs.
Preferiblemente la red de comunicaciones de la
presente invención se caracteriza porque cada uno de los hubs
comprende dos operadores lógicos AND, un operador lógico OR por cada
nodo de los que están conectados a ese hub y un operador lógico OR
por cada uno de los enlaces bidireccionales que ese hub tiene con
los otros hubs.
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. Es
decir, en CAN el medio físico es un bus que implementa una AND
lógica de los valores de bit transmitidos por los nodos. Esta
propiedad se utiliza para definir el resto de características del
protocolo CAN. En la presente red de comunicaciones, el hub
implementa esta función AND lógica de tal forma que la señal que
reciben los nodos es la misma que recibirían en un bus CAN en el
que participasen todos los nodos capaces de comunicar. De esta
forma, desde el punto de vista de los nodos, la existencia del hub
es transparente. Dicha transparencia hace posible que se mantengan
todas las características del protocolo CAN (el formato de las
tramas, el mecanismo de arbitraje, los mecanismos de detección de
errores del canal y señalización de los mismos, etc). Por este
motivo, como en la "red de comunicaciones de protocolo CAN con
topología en estrella", la invención posee la ventaja de que no
se pierden las propiedades de tolerancia a fallos de CAN y que se
pueden utilizar circuitos y componentes CAN estándar (p.e.
controladores CAN, transceptores, cables, etc) lo que hace que la
implementación presentada sea más económica.
Preferiblemente cada hub de la red de
comunicaciones de la presente invención se caracteriza porque un
primer operador lógico AND tiene como entradas las contribuciones
de cada uno de los nodos conectados al hub y un segundo operador
lógico AND tiene como entradas la salida del primero y las
contribuciones de cada uno de los enlaces bidireccionales que ese
hub tiene con los otros hubs.
Por otro lado, la presente invención tiene la
ventaja de que el hub puede utilizar cada uno de los operadores OR
de los que dispone para habilitar o inhabilitar la contribución de
un determinado nodo o de un determinado hub (según corresponda) al
operador lógico AND correspondiente y, por tanto, al valor de cada
bit que constituye la contribución del hub y/o al valor final de
cada bit que constituye la señal resultante del hub (según
corresponda).
Esto permite aislar dicha contribución cuando se
haya detectado que está permanentemente averiada, así como
reintegrar las contribuciones no permanentemente averiadas.
Preferiblemente la red de comunicaciones de la
presente invención se caracteriza porque cada uno de dichos hubs
comprende dos transceptores por cada uno de los nodos conectados a
dicho hub, uno para el uplink y otro para el downlink, y dos
transceptores por cada uno de los enlaces bidireccionales que ese
hub tiene con los otros hubs.
Ventajosamente la red de comunicaciones de la
presente invención se caracteriza porque dichos dos transceptores
por cada uno de los enlaces bidireccionales con otros hubs están
conectados uno por cada uno de los dos sentidos de dichos enlaces
bidireccionales.
Por ejemplo, cada enlace bidireccional podría
estar formado por dos subenlaces, cada uno dedicado a un sentido de
la comunicación. De esta forma, cada enlace (en inglés,
"link") que conecta un nodo a un hub está compuesto por un
uplink y un downlink; mientras que cada intralink, es decir, cada
uno de los enlaces bidireccionales entre cada par de hubs, está
formado por dos subenlaces unidireccionales llamados
"subintralinks".
Tal como se ha indicado, el hecho de tener dos
enlaces, uno para cada sentido de la comunicación, permite separar
en cada link la contribución real del nodo correspondiente, de la
señal resultante del acoplamiento en el hub; así como separar en
cada intralink la contribución del propio hub, de la que proviene
del otro hub. De esta forma, cada hub tiene una visión de lo que
realmente desea transmitir cada nodo y cada hub, pudiendo aplicar
los mecanismos necesarios para detectar qué contribución o
contribuciones en concreto está o están averiadas.
Estos transceptores se encargan de traducir las
señales lógicas (bits) que generan los diferentes circuitos a
señales físicas que puedan viajar por el medio físico (los enlaces)
y viceversa, traducir las señales físicas del medio a una señal
lógica que pueda ser
entendida por los circuitos.
entendida por los circuitos.
En CAN es preciso que las operaciones lógicas
AND y OR así como las operaciones de los transceptores de los
uplinks, de los downlinks y de los subintralinks en el hub se
realicen en el menor tiempo posible. El tiempo de bit en CAN es de
1 microsegundo a la máxima velocidad, aunque se puede agrandar para
conseguir velocidades menores. Por tanto, todas las operaciones
realizadas por las puertas AND y OR, así como por los transceptores
se realizan en una fracción de tiempo sensiblemente inferior al
tiempo que dura un bit en el protocolo CAN. Por ello, y como se
precisa una respuesta rápida, tanto la función AND como la función
OR se implementan mediante hardware, utilizando un operador o
puerta lógica. Gracias a estas características se consigue mantener
la propiedad de "in-bit response" propia de
CAN y maximizar el ancho de banda.
Preferiblemente la red de comunicaciones de la
presente invención se caracteriza porque los medios de tratamiento
de fallos comprenden detección de errores, diagnóstico de fallos y
pasivación de fallos en componentes permanentemente averiados; así
como la reintegración de componentes no permanentemente averiados.
Se entiende como componente a cada nodo, hub, link e intralink;
puesto que entendemos que cualquier elemento que pertenece a la red
de comunicaciones forma parte de alguno de
ellos.
ellos.
El hub de la presente invención diagnostica
fallos en los componentes a partir de la detección de errores
recibidos a través de sus puertos. Así, fallos en un nodo, otro
hub, un link, o en un intralink provocarán que el hub reciba
errores desde el correspondiente puerto. Cuando estos errores se
acumulen, le llevará a diagnosticarlo como averiado y a
aislarlo.
Además, los nodos de la presente invención
también son capaces de detectar errores recibidos desde los hubs y
de dejar de utilizar la información que llega desde cualquiera de
los hubs cuando diagnostica que dicho hub está averiado.
Los fallos ocurridos en un nodo se manifestarán
como la transmisión de bits erróneos a través de uno o más de los
uplinks con los que el nodo se comunica con los correspondientes
hubs. Los bits erróneos enviados a través de uno cualquiera de
estos uplinks pueden corresponder a una avería
stuck-at o una avería bit-flipping,
independientemente de lo que se transmita por los otros
uplinks.
El caso de un hub afectado por uno o varios
fallos es análogo al anterior. Un hub con fallos puede transmitir
independientemente por cada uno de sus puertos bits erróneos;
pudiendo presentar éstos una avería de tipo
stuck-at o bit-flipping.
En lo que respecta a fallos en los links o en
los intralinks, éstos se manifestarán siempre como la recepción de
bits stuck-at o bit-flipping en los
correspondientes puertos situados en los nodos o en los hubs, según
el caso.
Es importante notar que un fallo shorted medium
se manifiesta en el puerto de un hub como un fallo
stuck-at, mientras que una medium partition se puede
manifestar tanto como un stuck-at, como un fallo
bit-flipping. Esto se debe a que en un fallo
shorted medium el medio está cortocircuitado a masa o a
alimentación, mientras que en un fallo medium partition el medio
puede tanto estar cortocircuitado a un nivel de voltaje constante,
como puede causar errores en el canal debido a reflexiones en los
extremos abiertos del cable.
Cualquier contribución de un nodo que esté
permanentemente averiada bien por fallos en el nodo, bien por
fallos en el correspondiente link, será aislada por el
correspondiente hub.
De forma parecida, cualquier información errónea
que un hub envía de forma permanente a un nodo, debido tanto a
fallos en el hub como en el correspondiente link, será detectada
por el nodo, que dejará de tener en cuenta a ese hub a la hora de
comunicarse. Además, cualquier contribución permanentemente
averiada que un hub envía a otro hub, debido a fallos en el primer
hub o en el correspondiente subintralink, será aislada por el
segundo hub.
En la presente invención, cada par de hubs debe
estar interconectado a través de M intralinks (con M mayor o igual
a dos) con el fin de poder tolerar fallos en los enlaces entre
cualquier par de hubs. Así, si uno de los intralinks entre dos hubs
falla, el hub que recibe la contribución del otro hub a través de
ese intralink deja de utilizarlo, y continúa recibiendo dicha
contribución mediante los intralinks restantes entre ambos hubs. De
esta forma, mediante la replicación de los intralinks, se consigue
ventajosamente tolerar el fallo de (M-1) intralinks
entre cada par de hubs; con un coste mínimo de (M *
\sum^{N-1}_{i=1} i) intralinks en toda la red,
donde N es el número de hubs.
Siempre que exista al menos un intralink entre
cada par de hubs que les permitan intercambiar sus contribuciones,
todos los nodos serán capaces de ver las contribuciones de todos
los nodos, independientemente del hecho de que uno o varios nodos
puedan comunicarse solamente a través de un hub o a través de varios
hubs. Es pues una ventaja de la presente invención el hecho de que
mientras cada par de hubs puedan intercambiarse sus contribuciones
se evita la ocurrencia de un tipo especial de avería severa
denominada "avería de dominio de comunicación inconsistente",
en inglés "inconsistent communication domain failure". Este
tipo de avería puede ocurrir al utilizar una topología en estrella
replicada en general (que no tuviera las réplicas del hub
conectadas entre sí con intralinks, es decir, que no las tuviera
acopladas). Concretamente, una avería de este tipo aparece cuando,
debido a combinaciones particulares de pérdidas de conexión de los
nodos con alguno de los hubs, se crean diferentes dominios de
comunicación (solapados o no). De tal forma, que los nodos tienen
una visión inconsistente de los nodos que están disponibles para
comunicar.
Debido a las características de la presente
invención que se han expuesto hasta ahora, se obtiene la ventaja de
que se evita la ocurrencia de averías severas en el subsistema de
comunicaciones. Estas averías que se evitan son tanto las averías
severas que pueden producirse por los tipos de fallos
stuck-at fault y bit-flipping
faults; como las averías severas potenciales de tipo
"inconsistent communication domain failure".
Es más, como se toleran estos fallos sin
importar el componente en el cuál se produzcan (nodos, hubs, links,
intralinks), la presente invención ventajosamente elimina todos los
puntos de avería severa de una red de protocolo CAN provocados por
alguno de los fallos descritos en el párrafo anterior.
Es igualmente importante destacar que el hub de
la presente invención no sólo incluye mecanismos de tratamiento de
fallos para evitar averías severas, sino que también es capaz de
detectar los componentes que presentan algunos fallos que no pueden
provocar la avería severa del subsistema de comunicaciones, como
pueden ser los stuck-at-recessive
faults. Esto tiene la ventaja de que se puede informar a los
administradores del subsistema de comunicaciones sobre la
ocurrencia de un mal funcionamiento, aún cuando éste no pueda
provocar una avería severa.
Ventajosamente la red de comunicaciones de la
presente invención se caracteriza porque cada uno de dichos nodos
comprende dos transceptores por cada uno de los hubs a los que ese
nodo se conecta, uno de esos dos transceptores para el uplink y otro
para el downlink. También se caracteriza porque comprende al menos
un controlador CAN, al menos un microcontrolador, y medios para
cambiar las conexiones entre dichos controladores CAN y los
transceptores.
Un controlador CAN es un dispositivo electrónico
que implementa el protocolo CAN y que es utilizado por otros
dispositivos electrónicos para comunicarse a través de una red CAN,
transmitiendo y recibiendo mensajes. Mientras que un
microcontrolador es un dispositivo electrónico que dispone de varías
capacidades de proceso (ejecución de programas, temporizadores,
etc); de varios puertos para enviar y/o recibir señales de control
y/o datos hacia otros dispositivos; y, normalmente, también de
recursos de memoria que le permiten almacenar y consultar programas
y/o datos.
Es pues una ventaja de la presente invención el
hecho de que si un nodo dispone de N pares de transceptores, será
capaz de conectarse a N hubs simultáneamente. Concretamente, uno de
los transceptores de cada par se puede utilizar para conectarse al
uplink de un link, mientras que el otro transceptor se utiliza para
conectarse al downlink de ese mismo link.
En la presente invención los nodos se pueden
construir utilizando componentes electrónicos estándar. La forma de
utilizar estos componentes (controladores CAN, transceptores, etc)
dependerá del nivel de tolerancia a fallos que se pretenda
alcanzar.
Por ejemplo, se puede utilizar un único
controlador CAN cuya señal de recepción se obtiene acoplando,
mediante un operador lógico AND, los bits recibidos desde cada hub
al que el nodo esté conectado. Sin embargo, este esquema tiene una
desventaja importante. Cuando la señal que provenga de un hub
contenga errores, estos se propagarán a la señal resultante de
acoplar los bits recibidos desde todos los hubs y el nodo los
detectará sin saber de qué hub provienen. A continuación el nodo
señalizará los errores hacia todos los hubs; ya que en CAN cuando
un nodo detecta un error en un mensaje, lo señaliza de tal forma
que fuerza a que todos los otros nodos también detecten un error.
Por ello, al señalizar los errores a todos los hubs, todos ellos
van a detectar errores en la contribución que reciben de dicho
nodo. Si la situación en la que el nodo detecta errores y los
señaliza se prolonga lo suficiente, cada hub puede llegar a
diagnosticar que la contribución que recibe de dicho nodo está
averiada; con lo que el nodo sería aislado por todos los hubs,
cuando en realidad el nodo está actuando correctamente. Así, por
ejemplo, una única avería en uno de los downlinks de un nodo puede
ser suficiente para que todos los hubs aíslen al nodo. Por tanto, a
pesar de ser simple y práctica, esta solución no debe ser utilizada
en sistemas que requieran un alto grado de tolerancia a
fallos.
Sin embargo, en sistemas que requieran un alto
grado de tolerancia a fallos es preferible que, si N es el número de
hubs a los que se conecta un nodo, este nodo se caracteriza porque,
preferiblemente, utiliza N pares de transceptores; N controladores
CAN; porque cada uno de los controladores CAN se puede utilizar
para recibir y transmitir bien desde/hacia un hub, o bien
desde/hacia dos hubs diferentes; el hecho de que el nodo puede
cambiar en pleno funcionamiento las conexiones entre los
controladores CAN y los transceptores; y por el hecho de que para
un mensaje dado sólo uno de los controladores CAN será el
responsable de transmitirlo;
Es decir, cada controlador CAN de un nodo será
el encargado de enviar y recibir información hacia (o desde) un
hub en concreto. Por tanto, cada controlador CAN estará conectado
al transceptor del uplink y al transceptor del downlink
pertenecientes al link que lo conecta con dicho hub.
Preferiblemente, todos los controladores CAN se utilizarán para
recibir, simultáneamente, a través de su correspondiente hub; pero
sólo uno de los controladores CAN se utilizará para transmitir en
un momento dado. Obviamente, en caso de fallos, si el nodo no puede
continuar utilizando un determinado controlador CAN para
transmitir, utilizará otro de sus controladores CAN (el que le
convenga) para ello.
Además, por razones de tolerancia a fallos el
nodo también puede cambiar las conexiones entre los controladores
CAN y los transceptores. De forma que un controlador CAN también
puede estar conectado al transceptor del uplink de un hub y al
transceptor del downlink de otro hub. De esta forma, el controlador
CAN puede transmitir a través de un hub y recibir a través de otro.
Por tanto, ventajosamente un nodo conectado a varios hubs puede
comunicarse incluso cuando sólo es capaz de transmitir a través de
un hub y recibir a través de otro. Es decir, un nodo podrá
comunicarse con los otros nodos (transmitiendo y recibiendo
correctamente) siempre que uno de sus uplinks y uno de sus downlinks
no esté averiado. De esta forma, dicha red de comunicaciones tolera
el fallo simultáneo de varios uplinks y varios downlinks
pertenecientes al mismo link o a links diferentes.
Por otro lado, la presente invención tiene la
ventaja de que los fallos de tipo stuck-at y
bit-flipping pueden ser detectados por los nodos
utilizando convenientemente los mecanismos ya incluidos en los
controladores CAN estándar.
Según un segundo aspecto, la invención se
refiere a "un procedimiento de acoplamiento de una red de
comunicaciones de protocolo CAN con topología en estrella
replicada".
El procedimiento de acoplamiento de una red de
comunicaciones de protocolo CAN con topología en estrella replicada
según la invención se caracteriza porque el hub acopla las
contribuciones de los nodos conectados a él y acopla dicho
resultado con las contribuciones que recibe de los otros hubs.
Ventajosamente el procedimiento de acoplamiento
se caracteriza porque las contribuciones de los nodos conectados
al hub se acoplan mediante un primer operador lógico AND y dicho
resultado se acopla con las contribuciones que dicho hub recibe de
los otros hubs mediante un segundo operador lógico AND. El hub envía
la señal que resulta del primer operador lógico AND a cada uno de
los otros hubs a través de los intralinks correspondientes,
mientras que la señal resultante del segundo operador lógico AND es
enviada por el hub a los nodos conectados a él.
Así, la señal que resulta del primer operador
AND constituye la denominada anteriormente "contribución del
hub"; mientras que la señal resultante del segundo operador AND
constituye la denominada anteriormente "señal resultante del
hub".
Este esquema de conexiones le permite al hub de
la presente invención acoplar las contribuciones de los nodos
conectados a él con las contribuciones que recibe de los otros hubs
en dos fases independientes. Una primera fase en la que el hub
acopla las contribuciones de los nodos conectados a él, y una
segunda fase en la que acopla el resultado de la anterior fase con
las contribuciones que recibe de los otros hubs.
Esta separación del acoplamiento en dos fases
tiene la ventaja de que cada hub puede conocer cuál es el valor de
la señal que resulta de acoplar las contribuciones de los nodos
conectados a él, independientemente del valor de las contribuciones
de cada uno de los otros hubs.
Es importante destacar que para realizar las dos
fases de acoplamiento antes descritas, se pueden utilizar tantos
operadores AND como se quiera. Sin embargo, el hecho de utilizar
dos operadores lógicos AND; uno para la primera fase y otro para la
segunda fase tiene la ventaja de que es sencillo y puede implicar
menos retardos en el cálculo de las señales acopladas
resultantes.
El hecho de que la señal que resulta del primer
operador lógico AND sea enviada por el hub a cada uno de los otros
hubs a través de los intralinks correspondientes, mientras que la
señal resultante del segundo operador lógico AND sea enviada por el
hub a los nodos conectados a él, conlleva varias ventajas. Primero,
se evitan bucles infinitos en los acoplamientos que realizan los
diferentes hubs. En segundo lugar, el hecho de que cada hub envíe
al resto de hubs la señal que resulta de acoplar las contribuciones
de sus propios nodos, permite a los otros hubs implementar
mecanismos de tratamiento de fallos sobre la contribución recibida
desde el hub en cuestión y de esta forma evitar la propagación de
errores recibidos desde ese hub.
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 replicada;
la figura 2 es una vista de la red CAN con
topología en estrella replicada y acoplada 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 de un 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.
Dicha red tiene una serie de nodos 1 y cada nodo
1 se conecta a todos los hubs 3, usando un link 2 distinto para
conectarse a cada uno de los hubs 3.
Como puede verse en la figura 2, la principal
característica arquitectural de esta realización preferida de la
presente invención es que está constituida por dos hubs 3 (aunque
podría estar constituida por más) interconectados mediante al menos
dos enlaces bidireccionales llamados intralinks 6. Cada intralink 6
está constituido por dos subintralinks 6a 6b, y cada hub 3 utiliza
uno de los subintralinks 6a 6b de cada intralink 6 (cada hub uno
diferente dentro del mismo intralink) para enviar la señal que
resulta de acoplar las contribuciones de los nodos 1 conectados a
él hacia el otro hub 3. Cada uno de los nodos 1 (en la figura 2
pueden verse tres nodos 1 a modo de ejemplo aunque podría haber
más) está conectado a cada hub 3 a través de un enlace
bidireccional llamado link 2. Cada link 2 está formado por una
conexión ascendente ("uplink") 5 y una conexión descendente
("downlink") 4.
Es importante tener en cuenta que cada hub envía
dos tipos de señales distintas. Por un lado, la señal que cada hub
3 envía al otro hub y que resulta de acoplar las contribuciones de
los nodos conectados al primer hub, denominada como "contribución
de ese primer hub" 17. Por otro lado, la señal que cada hub
envía a sus nodos, llamada "señal resultante del hub" 22, y
que resulta de acoplar las contribuciones de sus propios nodos con
la contribución recibida desde el otro hub.
En CAN un nodo 1 típicamente está formado por un
microcontrolador 10 que ejecuta la aplicación; un controlador CAN
9 que implementa el protocolo CAN en sí y que es utilizado por el
microcontrolador 10 para transmitir y recibir mensajes; y un
transceptor 8 encargado de traducir la señal lógica (bits) que
transmite el controlador CAN 9 a una señal física que pueda viajar
por el medio físico (el canal) y viceversa, traducir la señal
física del medio a una señal lógica que pueda ser entendida por el
controlador 9. La figura 3 muestra una forma de conectar un nodo
CAN 1 a ambos hubs 3. A diferencia de un bus CAN, en dicha red de
comunicaciones cada nodo 1 preferiblemente utiliza N controladores
CAN 9, donde N es el número de hubs 3 (con N=2 en este caso). El
nodo 1 utiliza un controlador CAN 9 y dos transceptores 8 para
conectarse a un determinado link 2, un transceptor 8 para el uplink
5 y otro para el downlink 4. La salida de transmisión 11a de cada
controlador CAN 9 está conectada a la entrada de transmisión
("transmit data input" en inglés) del transceptor 8
correspondiente al uplink 5; mientras que la entrada de recepción
11b de cada controlador CAN está conectada a la salida de recepción
("receive data output" en inglés) del transceptor 8
correspondiente al downlink 4. Finalmente, el microcontrolador 10
se conecta a ambos controladores CAN 9 mediante los puertos de
entrada y salida 9a pertinentes. Aunque también sería posible
utilizar un microcontrolador con controladores CAN integrados; o
bien conectar el microcontrolador con los controladores CAN
mediante el bus de memoria externo del microcontrolador.
En la figura 4 se puede apreciar la estructura
interna de cada hub 3 en una realización preferida de la invención.
El hub 3 está constituido por tres módulos, un módulo de
entrada/salida 12, un módulo acoplador 13 y un módulo de
tratamiento de fallos 14.
El módulo de entrada/salida 12, está constituido
por una serie de transceptores 8, dos para cada intralink 6 y dos
para cada link 2. Se asigna un transceptor 8 para cada subintralink
6b que proviene del otro hub 3 para convertir las correspondientes
señales físicas recibidas en valores lógicos que el hub 3 pueda
procesar. De igual modo, se asigna un transceptor 8 a cada
subintralink 6a que va del hub 3 hacia el otro hub 3 para convertir
la contribución 17 del hub 3 desde una forma lógica a unas señales
físicas que se pueda transmitir al otro hub 3. Análogamente, se
asigna un transceptor 8 a cada uplink 5 para convertir la señal
física recibida de cada nodo en un valor lógico; y se asigna un
transceptor 8 a cada downlink 4 para convertir la señal resultante
del hub 22, que dentro del hub 3 es una señal lógica, a una señal
física que se pueda transmitir a cada nodo 1.
El módulo acoplador 13 está constituido por dos
puertas AND 15 16, una serie de puertas OR 19, una por cada uno de
los subintralinks 6b que provienen de los otros hubs 3 (en este
caso, del otro hub 3) y otra serie de puertas OR 18, una por cada
uno de los uplinks 5. La primera puerta AND 15 realiza el
acoplamiento de las señales de los uplinks 5. El resultado de esta
puerta AND 15 constituye la referida como "contribución del
hub" 17, y es enviada al otro hub 3 a través de cada uno de los
subintralinks 6a que van hacia él. La segunda puerta AND 16 acopla
la contribución del primer hub 17 con las contribuciones de los
otros hubs 3 (en este caso con la contribución del otro hub 3),
obteniendo la referida como "señal resultante del hub" 22 que
es enviada a través de los downlinks 4 a todos y cada uno de los
nodos 1 a los que se conecta el primer hub 3. Cada puerta OR 18 19
es utilizada por el hub 3 para habilitar o inhabilitar la
contribución a la correspondiente puerta AND 15 16 de uno de los
uplinks 5 o de uno de los subintralinks 6b provenientes del otro
hub 3, según el caso. Esta configuración junto con los
transceptores 8 del módulo de entrada/salida 12 produce unos
retrasos adicionales en la señal que reciben los nodos 1.
El módulo de tratamiento de fallos 14 está
constituido por una serie de unidades de habilitación e
inhabilitación, una por cada uno de los subintralinks 6b que
provienen del otro hub 3, llamadas "Hub Ena/Dis" 21, y una por
cada uno de los uplinks 5, llamadas "Node Ena/Dis" 20. Cada
una de estas unidades de habilitación e inhabilitación recibe la
señal de salida 22 de la segunda puerta AND 16, y la señal del
transceptor 8 correspondiente a un subintralink 6b o a un uplink 5,
según el caso, y genera una salida que se transmite a la puerta OR
correspondiente dentro del módulo acoplador 13. Como también puede
observarse, los mecanismos de diagnóstico de fallos del módulo de
tratamiento de fallos 14 del hub 3 requieren la observación por
separado de la contribución que llega por cada uno de los intralinks
6; así como la observación, también por separado, de la
contribución que llega por cada link 2. Gracias al uso de un cable
separado para cada subintralink 6a 6b y de dos cables separados, uno
para el uplink 5 y otro para el downlink 4, es posible mantener
separadas dichas contribuciones. 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 3, los mecanismos de pasivación de fallos del
módulo de tratamiento de fallos 14 eliminan la contribución de
dicho puerto del sistema. Se entiende como fallo en un puerto a
cualquier fallo, localizado en un nodo 1, un hub 3, un link 2 o un
intralink 6, que provoque que se reciba un número excesivo de bits
erróneos. La inhabilitación o eliminación de la contribución de un
puerto en fallo se consigue transmitiendo/fijando un valor lógico
"1" en la salida de la unidad de habilitación e inhabilitación
20 21 a la puerta OR 18 19 correspondiente a dicho puerto. Así la
salida de dicha puerta OR 18 19 tendrá también un valor lógico
"1" que hará irrelevante la contribución del puerto a la
salida de la puerta AND 15 16.
Inhabilitar un puerto equivale a desconectar el
correspondiente uplink 5 (o subintralink 6b) conectado a dicho
puerto. Es importante notar que no es preciso inhabilitar los
puertos del hub 3 conectados a un downlink 4, ni los puertos
conectados a un subintralink 6a que vaya del hub 3 hacia otro hub 3.
Esto es así porque el hub 3 no utiliza estos puertos para recibir,
sino para transmitir y, consecuentemente estos puertos no aportan
ninguna contribución al cálculo de las señales acopladas. Más aún,
un fallo en el downlink 4 (camino de comunicación que va desde el
hub 3 hacia un nodo 1) hará que el nodo 1 reaccione inadecuadamente
teniendo en cuenta la parte del mensaje que se está transmitiendo
y, consecuentemente, se manifestará en el hub 3 como la recepción
de bits erróneos a través del puerto conectado al uplink 5. De forma
parecida, un fallo en un subintralink 6a que va desde el hub 3
hacia el otro hub 3 hará que el otro hub 3 y los nodos 1 conectados
al otro hub 3 reaccionen incorrectamente con la parte del mensaje
que desde el punto de vista del primer hub 3 se está transmitiendo.
Así, el fallo de un subintralink 6a que va hacia otro hub 3 puede
manifestarse como la recepción de bits erróneos a través de los
uplinks 5 de los nodos 1 conectados al otro hub 3 y al primer hub
3, así como a través de los subintralinks 6b que provienen del otro
hub 3.
Además, el hecho de que el hub 3 continúe
transmitiendo por el downlink 4 de un nodo cuyo uplink 5 ha sido
inhabilitado, permite que el nodo pueda utilizar ese downlink 4
para poder recibir cuándo ya no pueda utilizar ningún otro downlink
4. Por ejemplo, se podría imaginar una situación en la que el
uplink 5 de un determinado nodo 1 sufre un fallo y es inhabilitado
por el hub 3 correspondiente. En este caso, el nodo 1 deja de
utilizar el controlador CAN 9 por el que transmitía hacia ese hub 3
y empieza a transmitir por el controlador CAN 9 conectado al otro
hub 3. Sin embargo, podría ser que un segundo fallo afectase al
downlink 4 conectado a este segundo controlador CAN 9. Entonces, el
nodo 1 podría utilizar cualquiera de los dos controladores CAN 9
para transmitir y recibir a través del uplink 5 y del downlink 4 no
averiados respectivamente. Es decir, el nodo transmitiría a través
de un hub 3 y recibiría a través del otro (utilizando un solo
controlador CAN 9), tolerando de esta forma hasta dos fallos en los
links 2, siempre que éstos afecten a un uplink 5 y a un downlink
4.
El hecho de que un nodo pueda utilizar un
controlador CAN para transmitir hacia un hub y recibir a través del
otro es posible por dos razones. Primero porque cada uno de los
hubs 3 acopla las contribuciones de sus propios nodos con la
contribución que recibe del otro hub; de tal forma que lo que un
nodo transmite hacia un hub es enviado por los dos hubs a todos los
nodos. Segundo, porque cada nodo dispone de mecanismos (por
ejemplo, circuitos multiplexores) que le permiten cambiar las
conexiones de los diferentes controladores CAN a los diferentes
transceptores.
La unidad "Hub Ena/Dis" 21 y la unidad
"Node Ena/Dis" 20 presentan básicamente la misma estructura
interna. La estructura de la unidad "Node Ena/Dis" 20 se
muestra en la Figura 5. Dichas unidades de habilitación e
inhabilitación incluyen un contador DBC (Dominant Bit Counter en
inglés) y su correspondiente unidad de control "DBC manager"
23; un contador NACK (Non acknowledgement en inglés) y su
correspondiente unidad de control "NACK manager" 24; un
contador BFC (Bit Flipping Counter) y su correspondiente unidad de
control "BFC manager" 25; así como un módulo "Threshold
control" 26 que básicamente compara los valores de la cuenta
acumulada por cada contador con unos determinados valores
prefijados.
Al analizar con detenimiento la estructura
interna de una unidad de habilitación e inhabilitación 20 21,
podemos entender mejor cómo funcionan los mecanismos de diagnóstico
de fallos del módulo de tratamiento de fallos 14. Por ejemplo, para
diagnosticar un fallo
"stuck-at-dominant" en un
puerto, la unidad de habilitación e inhabilitación correspondiente
(la unidad Node Ena/Dis 20 o la unidad Hub Ena/Dis 21, según el
caso) incluye un contador DBC y su correspondiente unidad de
control "DBC manager" 23, que sirven para contar el número de
bits dominantes recibidos de manera consecutiva en ese puerto. El
contador DBC, 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 módulo "Threshold control" 26
transmite un valor de salida "1" que va a la puerta OR 18 19
correspondiente a ese puerto. De esta forma se impide que un fallo
"stuck-at-dominant" en un solo
puerto provoque que todos los nodos 1 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 20, 21 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 1, se ha considerado
importante poder detectar tales fallos. En particular, la
capacidad de detectar fallos
"stuck-at-recessive" podría
ayudar en las tareas de mantenimiento de la red, ya que permitiría
informar sobre componentes averiados que, de otra forma, tardarían
más tiempo en ser detectados. Con el fin de detectar un fallo
"stuck-at-recessive", el
contador NACK es incrementado por su "NACK manager" 24 cada
vez que éste detecta que por el puerto correspondiente se ha
omitido la transmisión del bit de ACK que debería transmitirse
hacia el final de cada trama para indicar que la trama se ha
recibido correctamente. En CAN todo nodo que recibe correctamente
una trama debe transmitir un bit de valor dominante en un campo
específico situado muy cerca del final de dicha trama. Cuando el
valor del contador NACK excede un valor máximo prefijado, el
"Threshold control" 26 no transmite un valor de salida "1"
a la puerta OR 18 19 correspondiente a ese puerto (no es
necesario), sino que registra internamente (e indica en una posible
interfaz de registros o a través de otros mecanismos) que alguno de
los componentes conectados al puerto en cuestión, según el caso,
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 20, 21 del módulo de
tratamiento de fallos 14 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 1,
envía continuamente valores aleatorios y erróneos a la red. Para
diagnosticar este tipo de fallos cada unidad de habilitación e
inhabilitación 20, 21 incluye el contador BFC y su correspondiente
unidad de control "BFC manager" 25. Esta unidad es capaz de
detectar las situaciones en las que el puerto correspondiente
recibe uno o más bits erróneos de acuerdo con las especificaciones
del protocolo CAN (por ejemplo, con el formato de la trama, la
regla de bit complementario, etc). Cuando estas situaciones se
producen, el contador BFC es incrementado y cada vez que una trama
completa es transmitida sin errores, el contador BFC es
decrementado. Cuando el valor del contador excede el valor máximo
prefijado, el "Threshold control" 26 transmite un valor de
salida "1" que va a la puerta OR 18 19 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 1 reciban bits erróneos indefinidamente y no puedan
comunicarse entre sí.
A parte de los mecanismos de diagnóstico de
fallos, las unidades de habilitación e inhabilitación 20, 21
también incluyen mecanismos de reintegración mediante los cuales
puertos que previamente fueron inhabilitados son habilitados tras
observar que su funcionamiento es correcto nuevamente. De esta
forma, se tienen en cuenta fallos transitorios, maximizando el uso
de los recursos, y se permite realizar operaciones de reparación sin
necesidad de que el subsistema de comunicaciones deje de dar
servicio. El módulo "Threshold control" 26 es el responsable
de diagnosticar que un puerto que previamente había sido
inhabilitado no presenta ningún fallo y que, por tanto, puede
contribuir nuevamente en la señal resultante que es enviada a todos
los nodos 1. Por ejemplo, esto ocurre cuando el "Threshold
control" 26 detecta que el valor de los contadores DBC y BFC ha
descendido lo suficiente (indicando que ya no existe un fallo de
stuck-at-dominant ni un fallo de
bit-flipping respectivamente). Para rehabilitar la
contribución del puerto, el módulo "Threshold control"
transmite un valor de salida "0" que va a la puerta OR 18 19
correspondiente a ese puerto. De esta forma, la salida de la puerta
OR 18 19 tendrá el mismo valor lógico que la contribución del
puerto y, de esta forma, esta contribución será relevante a la
salida de las puertas AND 15 16.
Finalmente, es importante destacar cuáles son
las diferencias entre una unidad "Hub Ena/Dis" 21 y una "Node
Ena/Dis" 20. La primera diferencia radica en la forma en que los
módulos BFC manager 25 detectan cuándo un bit recibido por el
correspondiente puerto es erróneo. Como se ha dicho anteriormente,
el BFC manager 25 determina si un determinado bit es correcto o
erróneo de acuerdo con las especificaciones del protocolo CAN. Para
ello básicamente se tiene en cuenta si el valor del bit incumple o
no las reglas CAN sobre el formato de la trama y sobre la inserción
de bits complementarios. Estas reglas son diferentes dependiendo de
si el nodo 1 está actuando como transmisor o como receptor. La
diferencia entre el BFC manager 25 de la unidad "Hub Ena/Dis"
21 y el de la unidad "Node Ena/Dis" 20 es que el de la primera
tiene en cuenta que el valor de cada bit que recibe desde el
correspondiente subintralink 6b puede ser el resultado del
acoplamiento de los bits enviados por un nodo transmisor 1 y varios
nodos receptores 1, un solo nodo transmisor 1, o únicamente nodos
receptores 1; mientras que el de la segunda únicamente considera
que el bit recibido a través del uplink 5 o bien es enviado por un
nodo transmisor 1 o por un nodo receptor 1.
La segunda diferencia entre una unidad "Hub
Ena/Dis" 21 y una "Node Ena/Dis" 20 estriba en los valores
máximos prefijados que el módulo "Threshold control" 26 tiene
en cuenta para diagnosticar cada tipo de fallo. Esto se debe al
hecho de que un hub 3 que tiene un puerto averiado correspondiente
a un nodo 1 envía hacia el otro hub 3 los bits erróneos que recibe
a través de dicho puerto mientras no lo inhabilite. En este tipo de
situaciones, el otro hub 3 detecta errores en los correspondientes
subintralinks 6a. Por tanto, si los valores máximos de error que
tienen en cuenta los módulos "Threshold control" 26 de las
correspondientes unidades "Hub Ena/Dis" 21 no son lo
suficientemente mayores que los valores máximos de error que tienen
en cuenta los módulos "Threshold control" 26 de las unidades
"Node Ena/Dis" 20, un fallo en uno de los puertos de un hub 3
puede llevar al otro hub 3 a diagnosticar que aquel hub 3 está
averiado. Con el fin de evitar que en estas situaciones un hub 3
pueda diagnosticar injustamente que el otro hub 3 está averiado,
los valores máximos de error que tienen en cuenta los módulos
"Threshold control" 26 de las unidades "Hub Ena/Dis" 21
son mayores que los que tienen en cuenta las unidades "Node
Ena/Dis" 20.
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 (9)
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 al menos un primer hub (3),
caracterizada por el hecho de que
comprende al menos un segundo hub (3) idéntico
al primero;
cada par de hubs (3) está interconectado por al
menos dos enlaces bidireccionales (6);
e implementando medios de tratamiento de
fallos.
2. Red de comunicaciones según la reivindicación
1, caracterizada por el hecho de que cada uno de dichos hubs
(3) comprende dos operadores lógicos AND (15 16), un operador
lógico OR (18) por cada nodo de los que están conectados a ese hub
(3) y un operador lógico OR (19) por cada uno de los enlaces
bidireccionales que ese hub (3) tiene con los otros hubs (3).
3. Red de comunicaciones según la reivindicación
2, caracterizada por el hecho de que dicho primer operador
lógico AND (15) tiene como entradas las contribuciones de cada uno
de los nodos (1) conectados al hub (3) y dicho segundo operador
lógico AND (16) tiene como entradas la salida del primero (17) y
las contribuciones de cada uno de los enlaces bidireccionales que
ese hub (3) tiene con los otros hubs (3).
4. Red de comunicaciones según las
reivindicaciones 1, 2 ó 3, caracterizada por el hecho de que
cada uno de dichos hubs (3) comprende dos transceptores (8) por
cada uno de los nodos (1) conectados a dicho hub, uno para el
uplink (5) y otro para el downlink (4), y dos transceptores (8) por
cada uno de los enlaces bidireccionales (6) que ese hub (3) tiene
con los otros hubs (3).
5. Red de comunicaciones según la reivindicación
4, caracterizada por el hecho de que dichos dos
transceptores (8) por cada uno de los enlaces bidireccionales (6)
con otros hubs (3) están conectados uno por cada uno de los dos
sentidos (6a, 6b) de dichos enlaces bidireccionales (6).
6. Red de comunicaciones según cualquiera de las
reivindicaciones anteriores, caracterizada por el hecho de
que dichos medios de tratamiento de fallos comprenden detección de
errores, diagnóstico de fallos y pasivación de fallos en
componentes permanentemente averiados, y reintegración de
componentes no permanentemente averiados.
7. Red de comunicaciones según cualquiera de las
reivindicaciones anteriores, caracterizada por el hecho de
que cada uno de dichos nodos (1) comprende dos transceptores (8)
por cada uno de los hubs (3) a los que ese nodo (1) se conecta, uno
de esos dos transceptores (8) para el uplink (5) y otro para el
downlink (4); al menos un controlador CAN (9); al menos un
microcontrolador (10); y medios para cambiar las conexiones entre
dichos controladores CAN (9) y los transceptores (8).
8. Procedimiento de acoplamiento de una red de
comunicaciones según cualquiera de las reivindicaciones anteriores,
caracterizado por el hecho de que
el hub (3) acopla las contribuciones de los
nodos (1) conectados a él;
y acopla dicho resultado con las contribuciones
que recibe de los otros hubs (3).
9. Procedimiento de acoplamiento según la
reivindicación 8, caracterizado por el hecho de que
las contribuciones de los nodos (1) conectados
al hub (3) se acoplan mediante un primer operador lógico AND (15) y
el resultado es enviado a los otros hubs (3);
dicho primer resultado se acopla con las
contribuciones que dicho hub (3) recibe de los otros hubs (3)
mediante un segundo operador lógico AND (16);
y dicho segundo resultado es enviado a los nodos
conectados al hub.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200502292A ES2270724B1 (es) | 2005-09-16 | 2005-09-16 | Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200502292A ES2270724B1 (es) | 2005-09-16 | 2005-09-16 | Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2270724A1 true ES2270724A1 (es) | 2007-04-01 |
| ES2270724B1 ES2270724B1 (es) | 2008-03-01 |
Family
ID=38319286
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200502292A Expired - Fee Related ES2270724B1 (es) | 2005-09-16 | 2005-09-16 | Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. |
Country Status (1)
| Country | Link |
|---|---|
| ES (1) | ES2270724B1 (es) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5127067A (en) * | 1990-09-10 | 1992-06-30 | Westinghouse Electric Corp. | Local area network with star topology and ring protocol |
| US5355375A (en) * | 1993-03-18 | 1994-10-11 | Network Systems Corporation | Hub controller for providing deterministic access to CSMA local area network |
| US6044405A (en) * | 1996-04-12 | 2000-03-28 | Wam!Net Inc. | Service network incorporating geographically-remote hubs linked by high speed transmission paths |
| US6111888A (en) * | 1997-05-27 | 2000-08-29 | Micro Motion, Inc. | Deterministic serial bus communication system |
| US6335137B1 (en) * | 1999-06-17 | 2002-01-01 | Ricoh Company Limited | Electrophotographic toner and electrophotographic image forming method and apparatus using the toner |
-
2005
- 2005-09-16 ES ES200502292A patent/ES2270724B1/es not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5127067A (en) * | 1990-09-10 | 1992-06-30 | Westinghouse Electric Corp. | Local area network with star topology and ring protocol |
| US5355375A (en) * | 1993-03-18 | 1994-10-11 | Network Systems Corporation | Hub controller for providing deterministic access to CSMA local area network |
| US6044405A (en) * | 1996-04-12 | 2000-03-28 | Wam!Net Inc. | Service network incorporating geographically-remote hubs linked by high speed transmission paths |
| US6111888A (en) * | 1997-05-27 | 2000-08-29 | Micro Motion, Inc. | Deterministic serial bus communication system |
| US6335137B1 (en) * | 1999-06-17 | 2002-01-01 | Ricoh Company Limited | Electrophotographic toner and electrophotographic image forming method and apparatus using the toner |
Non-Patent Citations (2)
| Title |
|---|
| EMRICH: "CAN Application in Avionics". Omnisys Instruments AB. Final Report. 11 Julio 2001. Páginas 9,10,16,31-33; figura 10. * |
| EMRICH: "CAN Application in Avionics". Omnisys Instruments AB. Final Report. 11 Julio 2001. Pßginas 9,10,16,31-33; figura 10. * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2270724B1 (es) | 2008-03-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2359650T3 (es) | Unidad de interfaz y sistema de comunicaciones con una estructura maestro-esclavo. | |
| CN111025959B (zh) | 一种数据管理的方法、装置、设备及智能汽车 | |
| RU2656684C2 (ru) | Система шин и способ эксплуатации такой системы шин | |
| Barranco et al. | An active star topology for improving fault confinement in CAN networks | |
| US7783808B2 (en) | Embedded self-checking asynchronous pipelined enforcement (escape) | |
| US20110103390A1 (en) | Serialized enforced authenticated controller area network | |
| US8381059B2 (en) | Error correction and recovery in chained memory architectures | |
| US8670303B2 (en) | Multiple-fault-tolerant ethernet network for industrial control | |
| US8051338B2 (en) | Inter-asic data transport using link control block manager | |
| US20070234136A1 (en) | Method and apparatus for detecting the presence of errors in data transmitted between components in a data storage system using an I2C protocol | |
| US20060203716A1 (en) | Error detection and recovery of an optical network element | |
| CN110166354A (zh) | 一种包含片上网络容错路由的数据处理系统 | |
| ES2270724B1 (es) | Red de comunicaciones de protocolo can con topologia en estrella replicada y procedimiento de acoplamiento de dicha red. | |
| Barranco et al. | CANcentrate: An active star topology for CAN networks | |
| JPH09212453A (ja) | バス延長対応型制御システム | |
| CN104778104B (zh) | 一种串行数据通信总线的检错方法和串行数据通信总线 | |
| ES2215753T3 (es) | Diseño de placa madre con linea comun vme virtual, tolerante a fallos. | |
| ES2396013T3 (es) | Dispositivo de conmutación de sistema Ethernet de doble puerto | |
| US9407319B2 (en) | Fault tolerant transceiver | |
| ES2253100B1 (es) | Red de comunicaciones de protocolo can con topologia en estrella. | |
| WO2020199377A1 (zh) | 一种安全通信的装置和方法 | |
| CN114884767A (zh) | 一种同步双冗余can总线通信系统、方法、设备及介质 | |
| CN116506082B (zh) | 一种应用于应答器传输模块的二取二系统 | |
| ES2614456B2 (es) | Procedimiento de comunicaciones en redes can y concentrador de señales que ejecuta dicho procedimiento | |
| EP4489333A1 (en) | Ethernet device and method for reliable redundant communication links in safety critical applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20070401 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2270724B1 Country of ref document: ES |
|
| PC2A | Transfer of patent |
Owner name: UNIVERSITAT DE LES ILLES BALEARS Effective date: 20131023 |
|
| FD2A | Announcement of lapse in spain |
Effective date: 20180809 |