WO2003055152A1 - Protocolo de comunicacion serie con esquema de funcionamiento master - slave - Google Patents

Abstract

Métado de comunicación serie con esquema de funcionamiento de tipo maestro - esclavo. El método, optimizado para una arquitectura basada en un microcontrolador dotado de una UART para cada nodo ya sea maestro o esclavo, cuyo nodo maestro siempre actúa como estación primaria y los nodos esclavo como estaciones secundarias y en donde la planificación de la via de comunicación consiste en una distribución de unos mensajes que circulan por dicha via, formados en general por un conjunto de grupos de mensajes de transferencia de datos, propone la utilización de unas tramas especiales de consulta, de varios tipos, que permiten detectar desde el nodo maestro, en unos intervalos de tiempo razonables, la o las peticiones actuales de los nodos esclavos, con la posibilidad de que dichas tramas especiales sean empleadas, en otros esquemas de funcionamiento, como un mecanismo básico de distribución de dichos mensajes de datos, precediendo a los mismos.

Description

PROTOCOLO DE COMUNICACIÓN SERIE CON ESQUEMA DE FUNCIONAMIENTO MASTER - SLAVE

Campo de la invención La presente invención hace referencia a un protocolo o método de comunicación serie (términos utilizados indistintamente a lo largo del texto) con un esquema de funcionamiento de tipo master-slave, es decir maestro - esclavo, optimizado para una arquitectura basada en un microcontrolador dotado de una UART para cada nodo ya sea maestro o esclavo, cuyo nodo maestro siempre actúa como estación primaria y los nodos esclavo como estaciones secundarias y en donde la planificación de la vía de comunicación consiste en una distribución de unos mensajes que circulan por dicha vía, formados en general por un conjunto de grupos de mensajes de transferencia de datos incluyendo al menos un mensaje de escritura desde el nodo maestro a un nodo esclavo, seguido de, opcionalmente, un mensaje de lectura o respuesta del mismo nodo, encadenados de forma sucesiva formando un ciclo normal de comunicación,

En cuanto al entorno de aplicación el método propuesto es especialmente adecuado para un sistema de comunicación interno de un automóvil y para sistemas de control distribuido industrial, si bien su aplicación no debe considerarse restringida a ningún ámbito de los citados. La invención concierne también a un medio legible por un computador codificado con un programa para realizar la construcción de unas tramas especiales utilizadas en el método, así como a un medio legible por un computador codificado con un programa para realizar un método de planificación de uso temporal de un bus de acuerdo a los criterios expuestos por la invención.

Antecedentes de la invención

A principios de los años 80 se desarrollaron experimentalmente algunos protocolos para el entorno del automóvil, la mayoría de ellos basados en el uso de UARTs (Universal Asynchronous Receiver/Transmitteή y empleando protocolos propietarios. Esta tendencia con el tiempo fue cambiando lentamente hacia el uso de protocolos estándares como sucede en la actualidad.

El principal foro de documentación y debate de las comunicaciones en este ámbito ha girado en torno a la Society of Automotive Engineers (SAE). De hecho este organismo estableció una clasificación de los sistemas de comunicación internos del automóvil en tres niveles resumidos en la Tabla 1 Tabla 1

Clase velocidad aplicación aprox.

A < 10 kbit/s transmisión de señales de activación poco frecuente (activación humana)

B 10 - 100 kbit/s transmisión de información de control en tiempo real no estricto. Aplicaciones no críticas (). Presentación de datos al conductor, comunicación entre equipos electrónicos (aire acondicionado, audio, retrovisores, diagnosis, etc.).

C > 100 kbit/s transmisión de información de control en tiempo real estricto. Aplicaciones de seguridad crítica (ABS, ESP, ...).

Se puede considerar además una cuarta clase (clase D), abarcando sistemas de alta velocidad para aplicaciones, por ejemplo multimedia (> 1Mbit/s).

El primer salto cualitativo en este entorno se produjo alrededor del año 1985, con el desarrollo de los protocolos CAN (Controller Área Network) y CCD Chrysler Colusión Detection). Sin embargo éstos no se aplicaron en modelos comerciales hasta pasados unos años (CCD en 1988 y CAN en 1991). En 1991 apareció una nueva versión del protocolo CAN, denominada CAN 2.0, compatible con el estándar CAN 1.0, cuya aportación consistió básicamente en aumentar el campo de dirección de la trama de 11 bits a 29 bits (2²⁹ posibles mensajes), mediante la inclusión de un campo de identificación extendido de 18 bits. Esta mejora permite una mejor planificación de las direcciones de los mensajes, cuando en un mismo bus existen muchos posibles grupos de aplicaciones. La velocidad se aumentó a 500kbit/s al estandarizarse bajo SAE J2284-500 y a 1 Mbit/s bajo ISO11519, lo cual le engloba en la clase C. El procedimiento de contienda de este protocolo limita su máxima velocidad de funcionamiento. El protocolo SAE J1850 fue aprobado por la SAE en 1998 y revisado finalmente en 1994. Se trata de un protocolo que, en cierta medida, procede del protocolo CCD de Chrysler. Su especificación incluye las capas 1 y 2. Su principal aportación fué la inclusión de las respuestas de los nodos destinatarios dentro de la propia trama emitida desde el nodo origen. En concreto permite: respuesta de un byte desde un simple destinatario, respuestas concatenadas de un byte desde múltiples destinatarios y respuesta de múltiples bytes desde un simple destinatario.

El grupo francés Renault y PSA Peugeot-Citroén desarrollaron en 1988 el protocolo VAN (Vehicle Área Network) que es de capa 1 y 2. Sin embargo se realizaron diversas revisiones hasta septiembre de 1990, en que se presentó en la ISO por primera vez (VAN 1.0). En 1994 se presentó la versión 2.0 Paralelamente durante todo este periodo, se desarrollaron circuitos específicos para su implementación. Su principal aportación es el uso de un carácter especial de inicio de trama que le permite re-sincronizar el receptor a un precisión de un 1 %, partiendo de una diferencia entre emisor y receptor de un 20%. Al igual que CAN también incluye un bit de reconocimiento dentro de la trama original, así como la posibilidad de encadenar una trama de respuesta a continuación de la trama original, de forma parecida a J1850. La velocidad máxima que aconseja el estándar es 125 kbit/s (clase B).

En 1989 Mazda desarrolló el protocolo PALMNET (Protocol for Automotive Low and Médium speed Networks) puesto en práctica en un modelo de la marca en 1990. La capa física de este protocolo emplea una codificación PWM (baja eficiencia, pero sincronismo bit a bit), la cual es de 20 kbit/s (parte baja de la clase B). Con respecto a la capa de enlace usa CSMA CD con arbitrio no destructivo (también denominado CSMA/CD + NDA) como el protocolo CAN. En cuanto a la trama empleada contiene una longitud fija de 4 bytes de datos.

Su aportación más significativa es el procedimiento de confirmación multinodo al final de la trama y antes del carácter de fin de trama, denominado ANC (Acknowledgement for Network Control). Este método consiste en el envió al final de la trama, por parte de cada nodo conectado al bus, de una señal de reconocimiento (ACK) en una posición localizada de forma que se pueda interpretar por el nodo emisor. Este método limita el número máximo de nodos a 24. En 1994 Mazda realizó una mejora sustancial del protocolo PALMNET, que pasó a denominarse Advanced PALMNET . Aunque este protocolo conserva parte del nombre de su antecesor, el significado del acrónimo cambió de acuerdo al aumento de velocidad. Advanced PALMNET especifica dos versiones: media-baja velocidad (hasta 125 kbit/s) y alta velocidad (hasta 1 Mbit/s). En la versión de media-baja velocidad) con referencia a la capa de enlace , respecto de su predecesor sólo cambia el método ANC que, en este caso, para gobernar 32 nodos se obliga a tratarlos como dos buses lógicos de 16 nodos por separado. La capa física de esta versión utiliza codificación NRZ, con sincronización start-stop tanto en la zona ANC como fuera de ella. Esta sincronización consiste en el envío, desde el nodo emisor de la trama, 2 bits de sincronismo cada 4 bits de la trama. El tipo de canal empleado es par trenzado.

La versión de alta velocidad requiere el empleo de par trenzado apantallado. En cuanto a la capa física, usa NRZ como con sincronismo start-stop en la zona ANC, pero fuera de ella usa NRZ con bit stuffing (insertando un bit de signo contrario si 5 bits consecutivos no cambian de valor), igual que CAN. El número de nodos se reduce a 16. Por otra parte, este protocolo añade un nuevo método de consulta con respuesta encadenada de múltiples nodos dentro de la misma trama denominado SDG (Simultaneous Data Gathering). El procedimiento SDG permite que en una trama original se le concatenen una serie de respuestas de otros nodos seguido de un campo CRC del nodo origen y la posterior confirmación (bit ACK) individual y concatenada de los nodos de respuesta. El campo de CRC protege la trama desde su inicio hasta la última respuesta inclusive. Cada uno de los nodos que enviaron la respuesta contestan con dicho bit ACK si el campo CRC casa con su comprobación CRC local del mismo intervalo. SDG permite un ahorro sustancial de tiempo en la recolección de datos, si bien, se ha de tener en cuenta que sólo permite la consulta desde el nodo original y no el envío de datos.

Otros protocolos de interés son el BEAN (Body Electronics Área Network) desarrollado por Toyota a principios de los años 90, con el objetivo de resolver las comunicaciones concernientes a las operaciones relativas a los pasajeros (conmutadores, control de puertas y ventanas, y diagnósticos de vehículos) y se aplicó de forma comercial en 1995 y el K-Bus desarrollado por BMW en 1995, orientado a funciones no críticas

El protocolo TTP (Time Triggered Protocol) impulsado principalmente por H. Kopetz de la Universidad de Viena aparecido hacia 1994, representó un salto cualitativo muy alto con respecto a los buses de comunicación de aquel momento y del mismo se realizaron diversas versiones cubriendo todas las clases SAE A, B y C: TTP/A, TTP/B y TTP/C.

TTP emplea como acceso al medio el método TDMA (Time-División Múltiple Access) basada en una planificación temporal de los mensajes. De hecho, a este protocolo se le puede considerar como el primero que rompió la tendencia de las comunicaciones de este campo basada hasta el momento, en la planificación de bus por eventos ET (event triggered), planteando la planificación por tiempo TT (Time Triggered).

El funcionamiento del bus es cíclico. El instante de acceso al bus en cada ciclo, por parte de un nodo, viene determinado por el contenido de la tabla MEDL (MEssage Description List) ubicada en cada nodo. Cada nodo dispone de un reloj interno, actualizado por una trama de resincronización enviada con cierta frecuencia por un nodo, lo cual permite considerar la existencia de un reloj global.

La planificación temporal le permite además, asegurar el determinismo en las diferentes replicas temporales del valor de un conjunto de variables en todo el sistema (si no ha sucedido un error). La velocidad de este bus de 1 Mbit/s (TTP/C) si bien desde 1994 se notificó una versión a 2 Mbit/s en 1997 y se anuncia otra a 10 Mbit/s, lo que le hace un claro candidato a sistemas de tiempo real de aplicacones de seguridad crítica.

En 1998 K. Tindell, A. Rajnak y L Casparsson en "A CAN Communications Concept with Guaranteed Message Latencies", SAE Publications Group, expusieron el uso de CAN en sistemas distribuidos de tiempo real, con latencias garantizadas.

J.A. Fonseca y L.M. Almeida en "Using a planning scheduler in the CAN network". 1999 7^th IEEE International Conference on emerging Technologies and Factory Automation, vol.2, p.815-21. 1999, presentaron un planificador de mensajes sobre CAN, orientado a buses de campo del sector industrial y en enero de 2000 S.H. Hong y W.H. Kim en "Bandwidth allocation scheme in CAN protocol", IEE Proc.-Control Theory Appl., vol. 147, no. 1, presentaron un esquema de planificación de bus montado sobre can, consistente en dividir el ciclo de bus en N subciclos, de forma que cada uno de ellos está compuesto de dos partes una ventana de mensajes de tiempo real y otra de mensajes de no tiempo real.

El concepto X-by-wire procede de la industria aeronáutica consistente en la sustitución de sistemas mecánicos o hidráulicos por sistemas cableados, con sistemas electrónicos de control y de comunicación exige un sistema de comunicación altamente fiable y el detonante para su planteamiento ha sido la elevada tolerancia a fallos del protocolo TTP antes citado.

El protocolo Qwik fue el fue el resultado de una tesis desarrollada en la Chalmers University of Technology y se halla descrito en "Technical Specification Qwik Sigma-1.2 Node", QED AB, 1997. Está orientado a aplicaciones sencillas (entrada/salida), de seguridad no crítica, y con unos requerimientos de velocidad bajos y se aplicó al sensado de conmutadores de la columna de dirección de un vehículo. Su principal aportación es su sencillez y los símbolos empleados. QWIK es un protocolo orientado a bit, de tipo cíclico.

Alrededor de 1999 se realizó una nueva versión de la capa física de CAN, consistente en un nuevo transceptor, el cual, en funcionamiento normal trabaja con par trenzado y, caso de que uno de los conductores se vea afectado por un malfuncionamiento, el transceptor continua trabajando con el otro cable a la misma frecuencia, si bien con una menor inmmunidad ante EMI ElectroMagnetic Interíerence). La velocidad máxima permitida es de 125 kbit/s.

En octubre de 1999 BMW dio a conocer el protocolo Byteflight, tamben conocido como Sl-bus. Este protocolo tiene, como principal cualidad la unión de las ventajas de los métodos síncronos y asincronos, garantizando unas latencias deterministas para los mensajes de alta prioridad y un uso flexible del ancho de banda para mensajes de baja prioridad. La base de este protocolo es un método de acceso al medio denominado FTDMA (Flexible Time-División Múltiple Access), consistente en una distribución cíclica de bus, dividida en dos partes. La primera dedicada a mensajes de alta prioridad, con una planificación de tipo TT, mientras que la segunda se reserva a mensajes de tipo ET, los cuales se consideran de menor prioridad. Durante el intervalo TT, los mensajes se sincronizan por pulsos desde una estación central o master. Durante el intervalo ET, también se emplean un tren de pulsos enviado por el nodo master, con una separación mínima entre ellos, si no hay mensajes a transmitir por los nodos esclavos. Si alguno de ello tiene un mensaje para enviar, identifica su slot mediante el contaje de pulsos y, una vez encontrado transmite la trama, con lo que el espacio entre pulsos de sincronización de dicho slot se ve dilatado.

Sin embargo este protocolo, fue diseñado para un funcionamiento en estrella, y empleando fibra óptica, lo cual le aleja, en principio de la línea del sector de automoción. La velocidad de transmisión es de 10 Mbit/s. Aunque J. Berwangler et al. en "bytefight. A New High-Performance Data Bus System for Safety-Related Applications", Technical document of BMW, 2000, exponen ciertas posibilidades de dotar a este sistema de tolerancia a fallos, no se especifica que se hayan incluido en dicha versión. El protocolo FlexRay muy reciente se le puede considerar como una evolución de Byteflight hacia el terreno del control, dominado a nivel de prestaciones por TTP.

En abril de 2000, H. Kopetz en "Comparison CAN vs. Byteflight vs. TTP/C " , TTTech Computertechnik Gmbh, 2000 realizó una comparación de los protocolos CAN, ByteFlight y TTP. En dicha publicación expone los pros y contras de cada uno de estos protocolos, destacando de Byteflight una alta precisión de la señal de reloj central (nodo master) y la flexible distribución de mensajes no críticos. Como desventajas, revela la existencia de "single points of failure", la no solución de las estrategias de tolerancia a fallos, las cuales deben reposar en la aplciación, y la no disposición de servicios de comunicación con reconocimiento. En el año 2000 se presentó el protocolo LIN (Local Interconnect Network) en el congreso SAE de Detroit. Este protocolo se diseño a partir de un amplio grupo de empresas del sector automovilístico, principalmente europeo, para crear un protocolo de clase A. La última revisión realizada (LIN 1.2) es de noviembre de 2000.

Este protocolo afecta a las capas OSI (Open Systems Interconnection) de la 1 y 2. Se basa en el método de acceso al bus master/slave, con master único, para lo cual no le hace falta ningún procedimiento de arbitrio. Debido a ello, puede garantizar las latencias de transmisión de los mensajes. La trama empleada está orientada a carácter, de forma que el protocolo se puede implementar en base a un microcontrolador dotado de una UART. Una característica importante es la trama empleada, la cual, en su parte inicial, dispone de un carácter que permite resincronizar el reloj del sistema de comunicación del nodo receptor para el resto de la trama. Ello supone la posibilidad de emplear un oscilador interno de baja precisión (< 15%) integrado en el microcontrolador, en lugar de un cristal externo. Esta resincronización permite afinar la precisión a 0,5%, suficiente para su funcionamiento.

En 2000, H. Zeltwanger en "CAN Standard Review: Changes and Enhancements of the ISO 11898", SAE Publications Group, expone ciertas mejoras que se están planteando al estandard CAN, que llevarán, en breve, a la creación de las revisiones ISO 11898-1 y 11898-2. En ellas se contempla la posibilidad de añadir una cierta sincronización entre los nodos mediante la detección del bit SOF de todas las tramas que circulan por el bus. Esta sincronización, junto con la adopción de un nodo productor de mensajes de tiempo permitiría una planificación de tipo TT. Por otra parte, con respecto a la capa física también se anuncia la inclusión del transceptor tolerante a fallos ya disponible en un tercer apartado de estas normas, sustituyendo a la actual ISO 11519-2.

En la solicitud de patente PCT/ES 00/00487, en la que aparece el presente inventor, se describe un bus digital de comunicaciones de bajo coste orientado a la transmisión de múltiples canales de audio basado en el uso de par trenzado como canal de comunicación. El protocolo expuesto en dicha patente denominado DCMCAT (Digital Communications for Múltiple Channel Audio Transmission) finalizado en el año 2000, consistió en un modelo maestro/esclavo que funcionaba a una velocidad de 2 Mbit/s sobre par trenzado, empleando como capa física RS485. Esta velocidad le permitía transportar 6 canales de audio con una resolución de 12 bits y una frecuencia de muestreo de 16 kHz. La planificación era totalmente estática y por tanto, determinista. La principal aportación de este protocolo fue la propiedad de antibloqueo de los nodos esclavos. El procedimiento propuesto consistía en la reinicialización completa del sistema de comunicaciones de los nodos esclavos cada vez que se detectaba el inicio de una trama del nodo maestro.

En la Tabla 2 se muestra un resumen de las características de los protocolos anteriormente expuestos. Tabla 2

Medio codific. de acceso detec. de datos veloc. Implem. año promotor bit al medio error (bytes) trans.

CCD TP NRZ & BS CSMA/CR CRC8 no limit. 7,8 kbit/s ? 1985 Chrysler

CAN 1.0 TP NRZ & BS CSMA CR CRC16 0-8 125 kbit/s hwd 1985 R. Bosch

J1850 PM TP VPM CSMA/CR CRC8 1-8 10,4 hwd 1987 SAE kbit/s

J1850 PW TP PWM CSMA/CR CRC8 1-8 41 ,6 hwd 1987 SAE kbit/s

PALMNET TP NRZ CSMA/CR CRC8 4 or 8 20 kbit/s hwd 1989 Mazda

VAN TP Manchester CSMA/CR CRC16 0-28 125 kbit/s hwd 1991 Re. & PSA

CAN 2.0 TP NRZ & BS CSMA/CR CRC16 0-8 1 Mbit/s hwd 1991 R. Bosch

Adv PALMNET LM TP PWM CSMA/CR CRC8 4 125 kbit/s hwd 1994 Mazda

Adv PALMNET H STP NRZ & BS CSMA/CR CRC16 4 or 8 1 Mbit/s hwd 1994 Mazda

BEAN sw NRZ & BS CSMA/CD CRC8 1-11 10 kbit/s sft / hwd 1995 Toyota

K-Bus sw RS232C type CSMA/CD CHKSUM 32 9,6 kbit/s hwd / sft 1995 BMW 8

TTP/C dual TP MFM TDMA CRC16 32 2 Mbit/s hwd 1995 TTTech

Qwik 1.0 sw custom pulse count - 1 bit 25 kbit/s hwd / sft 1997 Chalmers

FT-CAN TP NRZ & BS contention CRC16 0-8 125 kbit/s hwd 1999 R. Bosch

ByteFMght optic NRZ pulse count CRC16 0-12 10 Mbit/s hwd 1999 BMW start/stop

LIN sw RS232C type master/slav CHKSUM 2-4-6 19,2 sft / hwd 2000 LIN cons. e 8 kbit/s

DCMCAT TP Manchester master/slav ~ 12bit 2 Mbit/s hwd 2000 LEAR e corp.

FlexRay TP, NRZ pulse count CRC 16 0-12 > 1 Mbit/s hwd 2001 BMW, DC optic start/stop

DC-bus pow. llke CAN / DCbus Al ¡ine UN ^"

TP: Par trenzado STP: Par Trenzado Apantallado SW: Cable único BS: Relleno de bit Manch: Manchester

Entre los protocolos del sector industrial, aún más numerosos que los del sector del automóvil cabe citar, el protocolo ModBus desarrollado por la empresa Modicon. Se trata de un protocolo abierto, cuya implementación puede realizarse por software (sobre un microcontrolador por ejemplo) y empleando una UART. Su especificación abarca la capa 2 y capa 7. Como capa física se puede emplear, entre otros, el conocido estándar RS485. El método de acceso al bus es de tipo maestro/esclavo. El nodo maestro puede realizar transacciones punto a punto con un nodo esclavo, o enviar mensajes de difución a todo el bus. En caso de ser detectado un error en la recepción en el nodo esclavo, éste envia un mensaje de respuesta indicando el tipo el error.

Dispone de dos tipos de tramas: tramas basadas en caracteres ASCII y tramas binarias. Para resolver el problema de la transparencia de datos en las tramas binarias, el protocolo impone unos intervalos de silencio al principio y fin de trama, así como un intervalo máximo entre caracteres de medio carácter. La trama no dispone de campo de longitud de datos. Esta información se considera inherente en del campo de comando. El significado del campo de comando corresponde a la capa 7. ModBus define al respecto una serie de comandos, con el número de caracteres y significado asociado. Este protocolo se ha extendido por todo el sector industrial en aplicaciones de baja seguridad. La velocidad de funcionamiento es de 19,2 kbit/s.

Las patentes US.A-5488693, US-A-5530436, US-A-5952932, US-A-6167057 y

US-A-6310892 describen diversos aspectos de protocolos que constituyen antecedentes en relación con las propuestas de la presente invención, si bien no plantean la problemática de interés ni aportan soluciones a la misma.

Del análisis de la evolución de los sistemas de comunicación en el entorno de automóvil se pueden distinguir dos líneas de investigación: por una parte los protocolos de muy altas prestaciones, con requerimientos extremos de hardware y, por otra parte, los protocolos destinados a aplicaciones no críticas que emplean arquitecturas hardware muy simples. En medio, en la clase B, las propuestas son prácticamente inexistentes.

Se entiende por lo tanto la necesidad de un protocolo de comunicación para ser empleado en plataformas de sistemas distribuidos de tiempo real de área local y extremo bajo coste, orientadas principalmente a las siguientes aplicaciones: por una parte las clases B y C en el entorno de las comunicaciones del automóvil y por otra, el control empotrado (embedded control) de máquinas con una elevada producción.

En un terreno más general, no tan sólo limitado al sector del automóvil, la consideración de los antecedentes citados muestran que seria deseable disponer de un protocolo dotado de un conjunto equilibrado de prestaciones en los siguientes ámbitos: • Construcción con componentes hardware de gran consumo con multitud de fabricantes: con el siguiente objetivo:

• Asegurar la disponibilidad de componentes en el mercado.

• Componentes de muy bajo coste.

• Adecuado para planificaciones de bus básicamente de tipo cíclico, sin que ello suponga la reprogramación de todos los nodos del bus cuando se añaden nodos no previstos con anterioridad, como sucede con los protocolos de tipo TDMA (TTP, ByteFlight en su parte TDMA, ...).

• Apto también para la captura de eventos acíclicos esporádicos de alta prioridad sin que ello ocasione un aumento desmesurado del ciclo de bus. Y, en caso de una elevada frecuencia de eventos, no ocasione un descontrol del bus como puede ocurrir con los protocolos de tipo CSMA (CAN, J1850, CCD, ...). • Posibilidad de modificación o mejora del protocolo, sin que ello requiera un cambio hardware de los nodos. Esto lleva a un diseño basado en software, como es el caso de LIN ó MODBUS.

• Disponibilidad de mecanismos de desbloqueo remoto de nodos, aparte de otras posibles soluciones basadas en la detección de una situación de aislamiento local a cargo de la aplicación.

• Disponibilidad de confirmación remota en mensajes de difusión, como ocurre con todos los protocolos comentados, excepto con PALMNET, si bien este, requiere un hardware especial para su resolución. • Baja carga de cabecera.

• Velocidad de transmisión de datos por encima de 250 kbit/s.

• Protegido contra el efecto "babbling idiot" (nodo parlanchín incontrolado).

• Confinamiento local y temporal de errores hasta donde sea posible.

Breve exposición de la invención

En esencia, la invención concierne a un método de comunicación serie con esquema de funcionamiento de tipo maestro - esclavo, optimizado para una arquitectura basada en un microcontrolador dotado de una UART para cada nodo ya sea maestro o esclavo, cuyo nodo maestro siempre actúa como estación primaria y los nodos esclavo como estaciones secundarias y en donde la planificación de la vía de comunicación consiste en una distribución de unos mensajes que circulan por dicha vía, formados en general por un conjunto de grupos de mensajes de transferencia de datos incluyendo al menos un mensaje de escritura desde el nodo maestro a un nodo esclavo, seguido de, opcionalmente, un mensaje de lectura o respuesta del mismo nodo, encadenados de forma sucesiva formando un ciclo normal de comunicación y dicho método se caracteriza por comprender la utilización de unas tramas especiales de consulta, de varios tipos, las cuales están previstas para ser intercaladas entre dichos grupos de mensajes, donde sea necesario desde el punto de vista de la aplicación, generando unas consultas o una acción de supervisión capaz de alcanzar a todos los nodos para detectar desde el nodo maestro si en alguno de dichos nodos esclavo se produce alguna situación de urgencia que precise una atención inmediata por parte del nodo maestro, con la posibilidad de que dichas tramas especiales sean empleadas, en otros esquemas de funcionamiento, como un mecanismo básico de distribución de dichos mensajes de datos, precediendo a los mismos. En una realización preferida el método se aplica en una topología de bus, para el control y gestión del estado de una pluralidad de nodos esclavos conectados a un nodo maestro a través de al menos un bus, operando dentro de un sistema de comunicación que ofrece los servicios de acceso al medio usados para la compartición del bus de comunicación de datos entre múltiples nodos, y demás funcionalidades requeridas para el intercambio de información serie, serialización/deserialización, la interacción con el usuario local del sistema de comunicación y la interacción con una capa física.

La resolución de la transferencia de información entre el nodo maestro y los nodos esclavos conforme al método propuesto obedece esencialmente a tres formas de operativa: mensajes cíclicos de datos; - mensajes acíclicos de datos de baja prioridad; y mensajes acíclicos, esporádicos, de datos de alta prioridad.

En el caso de una planificación de transferencia de datos cíclica, para el tratamiento de mensajes acíclicos, esporádicos, de alta prioridad, se procede a la citada inclusión intercalada de dichas tramas especiales de consulta que, en caso de detectar una petición de atención, en al menos uno de los citados nodos esclavo, provoca una atención del nodo maestro con mensajes de transferencia de datos punto a punto que se pueden incluir mediante dos procedimientos: un alargamiento del ciclo de comunicación, en caso de estar justificado por la urgencia o un cambio de modo consistente en una conmutación a un funcionamiento basado en un ciclo de emergencia adecuado al caso.

En el caso del tratamiento de mensajes acíclicos de datos de baja prioridad, el método propone un mecanismo consistente en un bucle de consulta continuo desde el nodo maestro basado en el empleo de una o varias de las citadas tramas especiales de consulta, consecutivas, hasta la detección de una o varias peticiones de atención, en cuyo caso son atendidas, mediante el empleo de tramas de datos, para posteriormente continuar con las tramas de consulta.

Conforme al método expuesto la planificación de bus puede estar constituida por una integración de intervalos de transferencia de datos cíclicos junto con intervalos de consulta reservados para la detección de las peticiones de atención de baja prioridad, realizadas mediante inclusión de dichas tramas especiales en dichos intervalos y la atención correspondiente mediante tramas de datos.

Para resolver el conjunto de las tres formas de operativa antes citadas el método propone emplear intervalos reservados para mensajes cíclicos e intervalos reservados para mensajes acíclicos de baja prioridad, y en donde los primeros además, están sujetos a la inclusión, periódica de tramas especiales de consulta para detectar peticiones de atención de alta prioridad. Las citadas tramas especiales, de varios tipos, son las siguientes:

• trama constituida únicamente por un byte para usos específicos,

• trama SingleSlot: constituida por un único slot o ventana temporal de respuesta de los nodos esclavo dedicado a la detección de peticiones de atención de dichos nodos sin identificar cual o cuales la solicitan;

• trama MultiSlot: constituida por múltiples slots o ventanas temporales de respuesta de los nodos esclavo, dedicado a la detección de peticiones de atención de dichos nodos identificando cual o cuales la solicitan;

• trama SlotContention: o de contienda de slot constituida por un número determinado de slots o ventanas temporales de respuesta, cuyo objeto es detectar la petición de atención de máxima prioridad presente en el bus, identificando de que nodo procede y con que prioridad la emite.

Es característico de la invención que todas las citadas tramas especiales tienen en común el significado de los campos A/C y extra del primer byte de trama, cuyos campos además de formar parte de la cabecera, identifican el tipo de trama de que se trata y porque las tramas de tipo Slot, están compuestas todas ellas por cuatro partes consecutivas: a.- cabecera de trama formada por al menos un byte inicial, que contiene el campo indicador del tipo de trama y un campo extra; b.- intervalo de cambio a modo respuesta; c- intervalo de respuesta constituido por ventanas temporales de respuesta, y d.- intervalo de salida de modo de respuesta. de forma que los intervalos b, c, y d vienen predeterminados por unos valores temporales conocidos por todos los nodos del bus, almacenados en unas tablas residentes en cada uno de los nodos de manera tal que los intervalos b, c, y d vienen predeterminados por unos valores temporales conocidos por todos los nodos del bus, almacenados en unas tablas residentes en cada uno de los nodos.

La invención se describirá, a partir de este punto, con un mayor detalle, y señalando particularidades adicionales de varios ejemplos de ejecución, con la ayuda de unas láminas de dibujos, en las que se ha representado lo siguiente:

Breve exposición de los dibujos

La Fig. 1 se muestra esquemáticamente la forma de operación de una configuración maestro/esclavo (master/slave). La Fig. 2 ¡lustra una posible apariencia física de la configuración mínima de un nodo.

La Fig. 3 muestra el formato del primer byte de todas las tramas. La Fig. 4 es ilustrativa del formato de trama normal con indicación de la longitud de cada campo.

La Fig. 5 muestra el formato de la trama Byte (coincidente con la Fig. 3, al estar formada por un solo byte).

La Fig. 6 ejemplifica el procedimiento de interacción de los nodos maestro- esclavos conforme a la trama SingleSlot, con un bus que incluye dos nodos esclavo. La Fig. 7 ejemplifica el procedimiento de interacción de los nodos maestro- esclavos según la trama MultiSlot en un bus con N nodos esclavo.

La Fig. 8 es equivalente a la anterior si bien muestra la operativa de la trama MultiSlot en el caso de una versión asincrona.

La Fig. 9 ilustra la estructura de trama MultiSlot en un bus con N nodos esclavo y con modo respuesta orientada a carácter

La Fig. 10 ejemplifica el procedimiento de interacción de los nodos maestro- esclavos según la trama SlotContention.

La Fig. 11 muestra como ejemplo el procedimiento para ejecución de un servicio tal como el SendPPUDR (que se explicará más adelante). La Fig. 12 muestra una planificación de bus estática basada en un servicio

SendPPUDR por cada esclavo.

La Fig. 13 es un diagrama temporal que ilustra una planificación de bus estática basada en servicios SendPPUDR de un ejemplo con tres grupos de nodos.

La Fig. 14 muestra una planificación de bus estática con período de mensajes = período hiperciclo + dinámica de baja prioridad.

La Fig. 15, muestra una planificación de bus estática con período de mensajes < período hiperciclo + dinámica de baja prioridad.

La Fig. 16 ilustra una planificación de bus estática (multiperíodo) + dinámica esporádica de alta prioridad AR_evPoll. La Fig. 17 es equivalente a la anterior, pero con detección de atención en una consulta AR evPoil.

La Fig. 18 muestra una planificación de bus estática (multiperíodo) + dinámica esporádica de alta prioridad AR_nPoll.

La Fig. 19 es equivalente a la anterior pero con detección de atención en una consulta AR nPoll. La Fig. 20 muestra una planificación de bus estática (multiperíodo) + dinámica esporádica de alta prioridad AR_mpPoll.

La Fig. 21 es equivalente a la anterior pero con dos detecciones de atención en las consultas A R_mprPoll. La Fig. 22 muestra una planificación RR + ET esporádica con procedimiento de cambio de modo.

La Fig. 23 ilustra una planificación de bus estática (período mensajes = período hiperciclo) + dinámica de alta y de baja prioridad. Descripción en detalle de unos ejemplos de realización preferidos Según se ha indicado el método de comunicación o protocolo propuesto tiene por objeto constituir el núcleo de comunicaciones de un Sistema Distribuido de Tiempo Real, aportando un conjunto de Servicios de Comunicación en cada uno de los nodos que forman parte del sistema. Dichos servicios permiten el funcionamiento del sistema distribuido bajo un esquema de transmisión de tipo maestro/esclavo, sobre una topología de tipo bus.

En la Fig. 1 los números indican el orden de circulación de los mensajes. Esta configuración se fundamenta en una gestión del bus centralizada en el nodo maestro. Los diferentes diálogos (intercambio de mensajes) son siempre iniciados por el maestro (estación activa) hacia un nodo esclavo, actuando este último como respuesta a dicha acción (estación pasiva). Todos los diálogos son entre el maestro y un esclavo (o varios, si se trata de un mensaje de difusión).

Esta diferencia de uso de la comunicación entre el nodo maestro y los nodos esclavo, debe estar implementada de forma implícita en el bloque local user (usuario local) ilustrado en dicha Fig. 1. Los aspectos principales tenidos en cuenta para la concepción y diseño del presente método se podrían sintetizar en los siguientes puntos:

1. simplicidad, tanto a nivel interno como en su uso externo, tomando como referencia el modelo OSI, citado; 2. disponibilidad de servicios de transferencia de datos con y sin confirmación y de servicios de detección rápida de una petición de atención por parte de un nodo esclavo; 3. susceptible de implementación por programación (software) en un microcontrolador dotado de una UART (como referencia se emplea el microcontrolador 80C52); 4. adecuado para una implementación determinista desde el punto de vista temporal;

5. optimizado para mensajes cortos y admitiendo un bloque de datos de tamaño variable (0-31 bytes); y 6. adecuado tanto para bajas velocidades (19,2 kbit/s) como para altas velocidades (> 500 kbit/s).

Por otra parte se han considerado los siguientes tipos de prestaciones o servicios en la especificación del método de comunicación o protocolo:

a. transmisión de mensajes desde el nodo maestro a un nodo esclavo, con o sin confirmación de recepción correcta; b. transmisión de mensajes desde el nodo maestro a un nodo esclavo con requerimiento de respuesta posterior desde el nodo esclavo al nodo maestro; c. transmisión de mensajes desde el nodo esclavo al nodo maestro, sólo como respuesta a una petición previa del nodo maestro; d. transmisión de mensajes de difusión desde el nodo maestro a todos los nodos esclavos del bus, sin confirmación; e. consulta rápida desde el nodo maestro del estado de recepción del mensaje de difusión (enviado previamente por el nodo maestro) en cada uno de los nodos esclavo, es decir la combinación de los items d) y e) da lugar a una transmisión de mensajes de difusión con confirmación; f. consulta rápida desde el nodo maestro de una situación de petición de atención en nodos esclavo, característica que identifica esencialmente al protocolo; se establece tres niveles de consulta: f.a detección rápida de una situación de petición sin identificar el esclavo o esclavos peticionarios; f.b Identificación de la petición de mayor prioridad presente en el bus; f.c Identificación de todas las peticiones presentes en el bus, con una prioridad superior a cierto valor; y g. servicios especiales orientados a desbloquear el sistema de comunicación global cuando un fallo de éste es detectado.

En las prestaciones enumeradas como ítems e y f (detección de petición de atención en estaciones esclavo y difusión confirmada) es donde el método dedica más énfasis con objeto de resolver algunos problemas típicos (pero no exclusivos) de los RTDS de tipo maestro-esclavo. En concreto permite: a. Reducir las elevadas latencias en la detección de una situación urgente de uno o varios nodos esclavos propias de una gestión cíclica de bus. b. Evitar una baja eficiencia de bus si, para resolver el caso anterior, se opta por aumentar la relación entre la frecuencia de consulta y la frecuencia del hiperciclo de bus. c. Responsabilizar únicamente al nodo maestro de la planificación del bus, permitiéndole adoptar planificaciones simples o combinadas, de tipo "time- triggered" y "event-triggered", evitando cualquier tipo de colisión de bus. En el caso de una solución combinada, diversos grados de determinismo podrán ser especificados en función de las relaciones de prioridad establecidas en el nodo maestro entre ambos tipos de mensajes. Dicha planificación debe ser gestionada por la capa usuaria del presente protocolo. Este último se limita a ofrecer a través de sus servicios, la información del estado del bus (nodos esclavo) necesaria para la gestión. d. Establecer un determinismo temporal estricto en cada uno de los servicios del bus. Esto es imprescindible para cumplir con los requerimientos de los Sistema de Tiempo Real, e. Posibilidad de confirmación de mensajes de difusión específicos, sin provocar una caída sustancial de la eficiencia del bus. Las características del método que se está describiendo permiten una implementación por programación (software) de éste en un microcontrolador genérico. Este microcontrolador se supone que está dotado de una UART y permite, como es habitual, el acceso directo a las señales de entrada/salida serie (conocidas como RxD, TxD). Sin embargo, también cabe pensar en una posible implementación por circuitería electrónica (hardware) del mismo. Esta característica se considera muy importante con objeto de poder desarrollar sistemas de muy bajo coste basados en este método de comunicación, es decir sistemas constituidos básicamente por un microcontrolador y un transceptor de adaptación a un bus, tal como se puede ver en la Fig. 2.

Los servicios ofrecidos por un sistema de comunicación utilizando el presente método son los que se detallan a continuación. Todos los servicios siguientes están disponibles en el SAP del controlador de bus del nodo maestro y se inician como petición (primitive requesf) desde el usuario de éste. Los usuarios de los nodos esclavos afectados sólo actúan como consecuencia de la indicación recibida (primitive indication) y provocando, según el servicio, una respuesta (primitive response).

SendPP (Send Point to Poinf) Transferencia Punto a Punto de un mensaje sin reconocimiento de recepción. • SendPPA (Send Point to Point with Acknowledgment) Transferencia Punto a

Punto de un mensaje con confirmación del SC (sistema de comunicación) remoto.

• SendPPUA (Send Point to Point with Acknowledgment) Transferencia Punto a Punto de un mensaje con confirmación del usuario remoto.

• SendPPUDR (Send Point to Point with User Data Response) Transferencia Punto a Punto de un mensaje con una posterior respuesta de datos del usuario remoto en sentido contrario.

• SendBC (Send Broadcast) Transferencia en modo Difusión de un mensaje sin reconocimiento.

• BA_nPoll (Broadcast Acknowledgment - Node Identification Polling)

Identificación de los nodos del bus que responden afirmativamente al reconocimiento de haber recibido correctamente el último servicio SendBC. • AR_evPoll (Attention Request - Event Detection Polling) Consulta, desde el nodo maestro, para la detección de un evento de "petición de atención" desde uno ó varios nodos esclavos, sin identificarlos.

• AR nPoli (Attention Request - Node Identification Polling) Consulta (desde el nodo maestro) para la identificación de todos los nodos del bus que piden atención.

• AR_mprPoll (Attention Request - Max. Priority Request Identification Polling)

Consulta (desde el nodo maestro) para la identificación de la petición de máxima prioridad.

• RstGCS (Reset of the Global Communication System) Reset del sistema de comunicación local de todos los nodos esclavos del bus.

• RstSN (Reset Esclavo Nodes) Reset general (sistema de comunicación y aplicación) de todos los nodos esclavos. Tal como se ha indicado el primer byte de los diferentes tipos de tramas que propone la invención, y en particular el de las tramas especiales, tiene unas características comunes. Este byte, siempre incorpora el bit mp activado (mp=1) tal como se indica en la Fig. 3. Esto significa que fuerza la lectura e interpretación inmediata de dicho byte en todos los nodos del bus. Este byte siempre está constituido de 2 campos:

A/C este campo (address/control) de 6 bits indica, a la vez, el tipo de trama y el nodo o nodos a que va dirigida la trama, dependiendo de su valor; extra Este campo (extra field) de 2 bits aporta información adicional a la trama y tiene diferentes significados dependiendo del campo A/C. En las tramas de datos y en el servicio BA_nPoll se usa como número de secuencia (nseq).

En las tramas de consulta de petición de atención se usa como prioridad (pr).

La trama normal o de datos es la de uso general empleada por el sistema de comunicación para transferencias de datos entre los usuarios de dicha capa. En total dispone de los siguientes campos de información: dirección destino (addή, número de secuencia (seq), longitud de datos (dlen), comando u orden asociado (cmd), indicación de servicio de depuración (debug), datos (data), campo redundante para detección de errores (chk) y fin de trama (EOF ó End of Frame). El contenido de la mayoría de estos campos viene definido por el usuario de la primitiva de servicio request y, en el resto (chk, EOF) viene definido por el propio sistema de comunicación. El formato de trama se puede ver en la Fig. 4, en la cual se puede apreciar la orientación a carácter de la trama. Según el campo, éste puede ocupar un byte entero, parte de un byte, o varios bytes. Por omisión, todos los caracteres incorporan el bit mp = 0 (desactivado). Los caracteres que llevan el bit mp=1 (activado), se indican en la misma Fig. 4.

El uso de la trama Byte, mostrada en la Fig. 5 está reservado a situaciones excepcionales. Está formada por un sólo byte, el cual deberá cumplir con las características comunes del primer byte de trama. Su bit mp debe estar activado y los valores aceptados dependerá de si la trama es usada a nivel interno del protocolo o desde por el usuario. El objetivo de estas dos peculiaridades (un solo byte y mp activado) tiene el siguiente objetivo:

1. Al ser una trama corta permite ser usada en circunstancias donde se requiera una elevada velocidad, a expensas de no disponer de redundancia en la detección de errores.

2. Cuando existen nodos en los que se ha producido una cierta degradación del sistema de comunicación, la recepción y ejecución asociada a una trama de este tipo aumenta las posibilidades de éxito (caracteres de reset remoto). Ha de indicarse que la recepción consecutiva de dos o más tramas Byte con un valor específico que no aparece en las tramas normales, intercaladas en cualquier punto de dichos grupos de mensajes, provoca el reset (puesta a cero) del sistema de comunicación local del nodo esclavo que los reciba.

La trama SingleSlot ilustrada en la Fig. 6 se usa para detectar, mediante una breve consulta, un estado "afirmativo" de un determinado bit (en adelante bitX o bit de referencia), en alguno o varios de los nodos esclavos constituyentes del bus, sin identificar en cual de ellos está activado. Básicamente consiste en el envío de una trama constituida por un byte, seguido de un intervalo de gestión temporal del bus. Durante este intervalo, los nodos esclavos pueden manifestar el estado del bitX. En el ejemplo de esta figura el nodo 1 responde afirmativamente. Esta trama emplea dos modos de acceso al bus, los cuales se definen a continuación: Modo UART: El acceso al bus es a través de la recepción/envío de caracteres, empleando una UART típica. Modo Directo : El acceso al bus es directo a las señales TxD y TxDenable (transmisión) y RxD (recepción), sin intervención de la UART. Tal como puede verse en dicha Fig. 6, una vez enviado el primer byte (ti), tanto el nodo maestro como los nodos esclavo pasan del funcionamiento en modo UART a modo directo (t_M2). Durante el intervalo t_M3, también denominado ventana de respuesta, está formado por un único slot de respuesta, donde los nodos esclavos que tengan que manifestar un estado afirmativo del bit de referencia, envían un pulso dominante dentro de este intervalo. En el intervalo t_M4, tanto el nodo maestro como los nodos esclavos, pasan del modo directo al modo UART. El nodo maestro da por finalizada la trama al final del intervalo t . El nodo esclavo finaliza antes, al final del intervalo t_S . Esto es necesario con objeto de garantizar que el nodo esclavo está en condiciones de tratar la siguiente trama tan pronto como el nodo maestro la ponga en el bus. El nodo esclavo detecta el fin de trama dentro de este intervalo por una temporización iniciada localmente al final del intervalo t^ de valor fijo t₂₃, al que posteriormente añade el valor t_S . La temporización incluida en los nodos esclavos para detectar el final del intervalo de respuesta (zona 3), además de configurar la trama, protege al bus de los efectos de posibles desincronizaciones internas de este tipo de trama sobre las siguientes tramas que aparezcan en el bus. La Trama MultiSlot, mostrada en las Figs. 7 a 9, se usa para consultar, desde el nodo maestro, mediante una breve consulta, el estado ("afirmativo" o "negativo") de un determinado bit (en adelante bitX ó bit de referencia) en cada uno de los nodos esclavos constituyentes del bus. Puede haber diferentes bits a consultar, por lo que cada trama de este tipo SingleSlot deberá especificar el tipo de bit a consultar (implícito en el campo A/C). En concreto los servicio AR_nPoll y BA_nPoll son los únicos en esta versión de protocolo que usan esta trama.

El byte inicial de esta trama contiene los dos campos habituales de los otros tipos de trama: campo A C y campo extra. El campo A/C, según el servicio podrá ubicar caracteres especiales que indiquen que se trata de una trama de difusión (para ser escuchada por todos los nodos) e implícitamente indicará el bit sobre el cual se realiza la consulta (bit de referencia). El significado del campo extra dependerá del campo A/C.

La forma de operación de esta trama MultiSlot consiste básicamente en el envío de un byte en el modo UART desde el nodo maestro (ver intervalo ti en figura Fig. 7), seguido de un intervalo (t_M2) para cambiar a modo directo. Durante el intervalo o ventana de respuesta (t_M3), los nodos esclavos deben manifestar el estado de un determinado bitX dentro de su subintervalo o slot correspondiente, empleando el modo directo. Para ello, la capa física del bus debe trabajar con niveles dominante/recesivo. La respuesta con un pulso dominante dentro del slot correspondiente se considera que el bit de referencia es tiene el valor lógico 0. La respuesta a nivel recesivo (sin pulso dominante de respuesta) se considera que el bit de referencia tiene el valor lógico 1 o que el nodo esclavo está desconectado (o sin capacidad de comunicación debido a un malfuncíonamiento). En el ejemplo de la figura Fig. 7, los nodos 1 y N responden afirmativamente. Esta inversión de la relación bit / nivel de señalización respecto de la trama SingleSlot es para tomar la ausencia de respuesta como caso más desfavorable.

Durante el intervalo (t _M) el nodo maestro pasa del modo directo al modo UART y al finalizar ésta se da por terminada la trama. Como ya ocurría en la trama SingleSlot el trama finaliza con anterioridad en los nodos esclavos (después del intervalo t_S ). Ha de destacarse que esta Fig. 7 corresponde a la solución concreta expuesta en la reivindicación 16, de sincronismo por tren de pulsos. Para la identificación de los diferentes slots de que se compone la ventana de tratamiento temporal, el nodo maestro genera un tren de pulsos, tal como se muestra en la Fig. 7. Este espacio temporal está formado por N slots de igual duración. N es el número máximo de nodos (esclavos + maestro) previsto en la configuración particular del bus. Los slots se numeran de Slot₀ a Slot_N-ι. A cada nodo esclavo SLV_X le corresponde el slot_x.

El slot 0 no corresponde a ningún nodo esclavo y puede ser empleado para facilitar la implementación del método o protocolo, para sincronizar el nodo esclavo en el slot anterior al que le corresponda y evitar así el efecto de la latencia sobre el tiempo de respuesta del nodo esclavo en su slot. En la Fig. 8 que ilustra la trama MultiSlot en modo asincrono, se aprecia que dicha trama se usa para consultar, desde el nodo maestro, mediante una breve consulta, el estado ("afirmativo" o "negativo") de un determinado bit (en adelante bitX ó bit de referencia) en cada uno de los Nnodos esclavos constituyentes del bus. El procedimiento de interacción maestro esclavos es el siguiente: Esta trama consta de 4 partes (t-i, t_M2, t_M3 y t_M en la Fig. 8. En el intervalo t1 el nodo master envía un carácter al bus. en el intervalo t_M2 todos los nodos (maestro y esclavos) cambian a modo directo. Durante el intervalo o ventana de respuesta (t_M3), los nodos esclavos deben manifestar el estado de un determinado bitX dentro de su subintervalo o slot correspondiente, empleando el modo directo. Para ello, la capa física del bus debe trabajar con niveles dominante/recesivo. Durante el intervalo t_4M el nodo maestro pasa del modo directo al modo UART y al finalizar ésta se da por terminada la trama. Como ya ocurría en la trama SingleSlot el trama finaliza con anterioridad en los nodos esclavos (después del intervalo ts ).

La respuesta con un pulso dominante dentro del slot correspondiente se considera que el bit de referencia es tiene el valor lógico 0. La respuesta a nivel recesivo (sin pulso dominante de respuesta) se considera que el bit de referencia tiene el valor lógico 1 o que el nodo esclavo está desconectado (o sin capacidad de comunicación debido a un malfuncionamiento). En el ejemplo de la figura Fig. 8, los nodos 1 y N responden afirmativamente. Esta inversión de la relación bit / nivel de señalización respecto de la trama SingleSlot es para tomar la ausencia de respuesta como caso más desfavorable.

Para la identificación de los diferentes slots de que se compone la ventana de tratamiento temporal, todos los nodos realizan una división del tiempo t ₃ en N slots de igual duración. De hecho, todos nos nodos tiene ya preestablecida dicha duración.

Durante este tiempo t_M3 no hay ninguna señal de sincronismo, lo cual da nombre a esta versión de trama Multislot. Por este motivo el número máximo de slots se limita a 16.

El slot 0 no corresponde a ningún nodo esclavo, y su uso, reservado, puede utilizarse para otras posibles versiones.

En la Fig. 9 se muestra una trama MultiSlot alternativa, con modo respuesta orientado a carácter. Básicamente consiste en el envío de un byte desde el nodo maestro (ver intervalo t-i en figura Fig. 9) y posteriormente un intervalo de funcionamiento en modo "respuesta" al bus (intervalo t₃). Durante t₃, los nodos esclavos deben manifestar el estado de un determinado bitX dentro de su subintervalo o slot correspondiente. Existen dos formas de acceso al bus: Modo "UART": Acceso al bus con el formato estándar de carácter y velocidad

(v_s) de la trama Normal. Modo "Directo": Acceso al bus actuando directamente sobre el transceptor, sin el uso de la UART (como en la trama Multislot estándar).

El primer byte de esta trama MultiSlot es tratado por el modo normal (intervalo ti). El resto de bytes (respuesta de los nodos esclavos) se tratan por el modo respuesta

(intervalo t₃). Los intervalos t₂ y t₄ básicamente tiene la función de permitir el cambio de modo en los diversos nodos del bus: t₂ para pasar de modo normal a modo respuesta, y t₃ para pasar de modo respuesta a modo normal, antes de finalizar la trama MultiSlot.

En la Fig. 10 se muestra la trama SlotContention así como la forma de operación de dicha trama de contienda que consiste básicamente en el envío de un byte en el modo UART desde el nodo maestro (ver intervalo t, en la Fig 10), seguido de un intervalo (t_M2) para cambiar a modo directo. Durante el intervalo o ventana de respuesta (t_M3) todos los nodos esclavos con una petición de atención en curso intentan manifestar ésta sobre el bus, de las cuales sólo la petición de más prioridad consigue acceder totalmente al bus. El resto se retiran, esperando la finalización de la trama. Finalmente el Intervalo (t₄) permite pasar al modo de funcionamiento UART.

Para la identificación de los diferente slots de que se compone la ventana de tratamiento temporal, el nodo maestro genera un tren de pulsos, tal como se muestra en esta Fig. 10. Este espacio temporal está formado por 8 slots de igual duración.

El byte de prioridad de una petición de atención está formada por 7 bits [r₆,...,r₀]. La ventana de respuesta dispone de 8 slots o intervalos de tiempo. El primer slot, denominado sloto existe sólo a efectos de facilitar la implementación del mecanismo y no interviene en la contienda. El resto de slots [slot₁,...slot₇] están asignados correlativamente a un bit del byte de petición [r₆,...,r₀], de forma que se empieza transmitiendo en el slo^ el bit de mayor peso (bit r₆), tal como se puede observar en la Fig. 10.

El mecanismo de contienda se lleva a cabo en cada slot. Cuando varios nodos tiene una petición, ponen en el bus el bit de su byte de petición correspondiente al slot en curso. De estos nodos, los que detecten que el slot ha adoptado el mismo nivel que ellos han enviado, continuarán luchando en el próximo slot. El resto, habrán detectado un nivel en el bus contrario al enviado, retirándose del proceso de contienda durante el resto de la ventana de respuesta. Finalmente sólo un nodo conseguirá poner los 7 bits de la petición. En la citada Fig. 10 se muestra un ejemplo en el que los esclavos 2, 1 y 5 tienen peticiones en curso de prioridad pr_f¡_na| 62(hex), 61 (hex) y 45(hex), respectivamente. La petición del esclavo 2 es la de mayor prioridad. El esclavo 5 pierde la contienda en el slot-i, por lo que ya no envía ningún bit al bus durante el resto de trama. El esclavo 1 le sucede lo mismo pero en el penúltimo slot. El esclavo 2 es el único que supera la contienda al haber puesto en el bus su petición pr_f¡_πaι completa (7 bits). El mecanismo inherente a esta trama requiere que la capa física trabaje con niveles dominante/recesivo. En cada slot, la respuesta a nivel dominante se considera un "1" lógico y si es a nivel recesivo se considera "0" lógico. En la Fig. 11 se muestra, a título de ejemplo, el procedimiento para la ejecución de un servicio tal como el Send PPUDR citado, exponiendo el comportamiento de la entidades parejas u homologas, a ambos lados del canal. El proceso comprende las siguientes etapas: 1. El SC del nodo maestro envía la trama de tipo normal al bus según los parámetros indicados por el usuario del nodo maestro. El contenido del campo cmd se adopta internamente en el servicio con el valor CMDJJDR.

Al finalizar el envío de la trama pone en marcha una temporización con valor límite timeout (parámetro indicado por el usuario) y queda a la espera de recibir una trama tipo normal.

2. El SC del nodo esclavo activa la primitiva indication si recibe una trama de tipo normal libre de error, con el campo cmd conteniendo el valor CMDJJDR.

3. Posteriormente a la activación de la primitiva indication, el controlador del protocolo del nodo esclavo esperará indefinidamente la petición de la primitiva de respuesta de confirmación de su usuario local hasta que se dé uno de los casos siguientes: a. El usuario accede a la primitiva response con parámetros válidos. En este caso el SC local envía la trama de tipo normal correspondiente, con el mismos campos nseq y debug que los de la trama anteriormente recibida. Al finalizar la transmisión de este trama, el SC local del nodo esclavo pasa a la espera de la detección de un nuevo servicio. b. Se detecta un carácter en el bus. En este caso el SC local del nodo slave descarta dicha recepción, deshabilita una posible respuesta de su usuario y pasa a la espera de la detección de un nuevo servicio. Esto evita que el SC se quede bloqueado por un error en la aplicación local.

4. El SC del nodo maestro finaliza el servicio, activando la primitiva confirm, cuando finaliza la recepción de una trama normal, con o sin error, o cuando ha transcurrido un desbordamiento de tiempo (el temporizador ha alcanzado el valor límite). Para que el servicio se dé por finalizado correctamente en el nodo maestro, se debe recibir una trama normal como la indicada en el punto 3, antes del desbordamiento de tiempo. El contenido de los campos cmd y debug no se chequean. El campo debug empleado para identificar el tipo de usuario a confirmar la finalización del servicio no se chequea, dado que el SC del nodo maestro ya conoce dicho valor a partir del parámetro pasado inicialmente en la petición del servicio. Si la trama recibida es correcta, pero el campo nseq de la trama recibida no coincide con el campo nseq de la trama enviada inicialmente se indica el error con el valor STA_ERR_GEN. Si la trama recibida ha finalizado con error de cualquier tipo o se ha producido un desbordamiento de tiempo se indica con el valor correspondiente. A partir de la Fig. 12 se exponen diferentes posibilidades de distribución de un ciclo de bus. Todas ellas se basan en un ciclo repetitivo que, en la medida de lo posible se intenta mantener de la misma duración.

En primer lugar se expone una distribución de mensajes por el bus basada en una planificación estática ordenada por tiempo (TT - Time Tríggere ), adecuada para las transacciones entre bases de datos.

En segundo lugar se considera el hecho de que alguna aplicación puede plantear una comunicación adicional de mensajes fruto de la ocurrencia de ciertos eventos (ET - Event Tríggered) de baja prioridad en los usuarios locales, de forma que se reserve parte del ciclo de bus (un cierto ancho de banda) a la posible aparición de estos mensajes. Estos mensajes sólo podrán ser transmitidos al bus desde un nodo esclavo, como respuesta a un servicio SendPPUDR iniciado en el nodo maestro. Por ello, el nodo maestro realiza una serie de consultas al bus preguntando si algún nodo esclavo requiere su atención.

En tercer y último lugar se considera la posibilidad de que la aplicación global realice, además de las acciones anteriores, una detección de eventos de alta prioridad. Esto puede ser útil en aquellos casos donde un nodo esclavo desea comunicar un fallo en el sistema que puede llevar de forma inminente a la pérdida total del control.

Planificación TT

En este tipo de planificación, el acceso al bus está definido previamente a la ejecución del sistema distribuido. Dicha planificación reside en una tabla cuyo contenido marca el acceso a realizar al bus en cada instante (tabla MDL). Dicha tabla puede ser sustituida por un algoritmo determinista. Tanto la tabla como el algoritmo deberían residir en el nodo maestro, dado que es el gestor del bus.

Planificación con periodo único La Fig. 12 muestra el diagrama temporal de acceso al bus correspondiente a un sistema distribuido donde los diferentes nodos tienen un acceso al bus equitativo, con igual frecuencia de acceso al mismo para el intercambio de datos. El nodo maestro realiza una secuencia de servicios SendPPUDR (escritura/lectura de buffer local) para cada nodo esclavo, formando un ciclo repetitivo. En dicha figura se muestra el mensaje de ida y el de vuelta de cada transacción. Planificación orientada a múltiples grupos de nodos con diferente período

En algunos casos, en un mismo bus convivirán diversas subaplicaciones, cada una de ellas compuestas de varios nodos y con una determinada frecuencia de refresco de sus bases de datos. En dicha circunstancia puede confluir, además, que las frecuencias de las diversas subaplicaciones sean distintas.

La capa DCS puede resolver esta situación, creando un hiperciclo de bus que sea el mínimo común múltiplo de los periodos de refresco de cada subaplicación.

La Fig. 13 muestra el diagrama temporal de un ejemplo con tres grupos de nodos: grupo 1 {5,6} ; grupo 2 {1...4} ¡grupo 3 {7...F}. Cada uno de estos grupos con frecuencia de transmisión, con respecto a la frecuencia básica de bus f_Hc, de 3, 2 y 1 , respectivamente. En este caso, para resolver la coincidencia de intervalos de acceso al bus por parte de más de un grupo, se ha empleado un esquema de prioridad de tipo rate-monotonic. Las flechas verticales de la Fig. 13 muestran el instante de inicio del periodo de refresco de cada grupo o subaplicación. En esta figura cada recuadro representa una transacción consistente en un servicio SendPPUDR (un mensaje de ida y otro de vuelta).

Planificación TT + ET regular de baja prioridad

A la planificación estática disparada por tiempo, se le puede añadir el tratamiento de mensajes disparados por eventos de menor prioridad que los estáticos. Hay que destacar que aún cuando se trata de mensajes ET, éstos son guiados por el nodo maestro. En cierta manera son mensajes fruto de peticiones asincronas desde los usuarios de los nodos esclavos, finalmente sincronizados por el nodo maestro. Además de las soluciones planteadas utilizando servicios ARjnPoll, también podría emplearse servicios AR nprPoll si se pretende identificar de una sola vez la petición de mayor prioridad.

Periodo único (Modo Byteflight / FlexRay)

En este caso, ¡lustrado en la Fig. 14, se presenta la solución más simple. El hiperciclo se divide en dos partes, una para el tratamiento de mensajes TT y otra para los posibles mensajes ET de menor prioridad.

Esta solución es posible siempre que el periodo de refresco de las bases de datos de todos los nodos puede ser igual al hiperperiodo completo (TT+ET). El procedimiento ET consiste en enviar desde el nodo maestro un servicio AR_nPoll y, si se detecta una petición, se realiza la correspondiente consulta a dicho nodo mediante un servicio SendPPUDR. Cada S¡ en esta y en las Figs. siguientes comprende el conjunto S¡M, es decir trama desde master a esclavo i, y trama desde dicho esclavo al maestro, como en la Fig. 12.

Grupos de nodos con diferente periodicidad (Rate monotonic)

En este caso, ilustrado en la Fig. 15, se considera una planificación TT con grupos de nodos empleando diferente frecuencia de refresco. Se ha reservado una zona ET distribuida en pequeños intervalos durante todo el hiperciclo. De esta forma se consigue mantener una periodicidad regular tanto de los grupos 1 , 2 y 3 de planificación

TT, así como un periodo regular en la atención de mensajes ET.

En cualquier caso hay que tener en cuenta que no podrán tratarse más mensajes ET de los que quepan en dichos intervalos.

El procedimiento ET es igual al anterior caso. Aquí, se detecta una petición de atención de un nodo esclavo en el tercer intervalo ET de la figura F. una vez identificado (AR_nPoll) se consulta el nodo con un servicio SendPPUDR.

Planificación TT + ET esporádica de alta prioridad Se trata de intercalar consultas de petición de atención en la planificación. Ello provoca también una inevitable sobrecarga al hiperciclo en funcionamiento regular. Es importante remarcar el calificativo de esporádica, debido a que en, caso contrario, desmantelaría con frecuencia la planificación TT. Si no es esporádica es mejor reservar un ancho de banda fijo dentro de la planificación TT. Se presentan tres posibles planteamientos para tratar estas peticiones: a. Intentando sobrecargar lo mínimo posible el hiperciclo de bus, empleando servicios AR_evPoll. b. Con confirmación de nodo y servicio de consulta en buen estado, mediante servicios AR_nPoll. c. Identificando de una sola vez la petición de mayor prioridad en el bus. a. con mínima sobrecarga de bus (EV_evPoll)

En la Fig. 16 se muestra un hiperciclo conteniendo una planificación TT

(con la misma distribución de grupos que el ejemplo de la Fig. 15, al cual se ha añadido un servicio AR_evPoll cada 4 transacciones. De esta forma, la latencia en la atención de mensajes ET es de 4 transacciones TT. Si existe la posibilidad de acumulación de mensajes ET la latencia se incrementará, en el peor de los casos, a la duración de 4 transacciones más la suma de los servicios ET.

En la Fig. 17 se presenta el mismo sistema, pero en este caso se ha producido una petición crítica en los nodos esclavos Slv1 y Slv2. Como se puede observar, el ciclo se alarga, incumpliendo los tiempos de la zona TT, pero no se pierde el control del bus.

El nodo maestro puede decidir, en función de la gravedad de la petición y del retardo que puede ocasionar al hiperciclo, atenderla inmediatamente o aplazarla para continuar con la planificación del hiperciclo.

Es preciso remarcar que el servicio AR_evPoll ocupa muy poco espacio de bus, pero no detecta los casos en que un nodo esclavo no contesta a la consulta por un error temporal en el canal o por un malfuncionamiento en dicho nodo. En cualquier caso, los nodos son examinados al menos una vez por hiperciclo en las transacciones TT. Si la no-detección de la petición es debida a errores temporales en el canal, en el próximo servicio AR_evPoll se detectaría la petición. b. con confirmación de mensaje recibido y nodo correcto (EV iPoll) Este es el sistema con mayor capacidad de detección de situaciones anómalas, dado que el servicio AR_nPoll interpreta la no-contestación en dicho servicio como un error en la transmisión, un error en un nodo ó o una petición. Dado que todos ellos merecen una atención especial, ello conlleva a un diálogo del nodo maestro con el ó los nodos afectados, como en el caso anterior (AR_evPoll). En la figura 18 se presenta la planificación de bus en funcionamiento normal.

En la Fig. 19 se expone la misma planificación, pero en ella se han detectado una petición de los nodos SlvE y SlvF en el segundo servicio AR__nPoll. c. con identificación inmediata de la petición de máxima prioridad (ARjnprPoll).

Si en vez de utilizar el servicio AR_evPoll se emplea AR_mprPoll, se tiene la ventaja de la identificación inmediata de la petición de máxima prioridad, a expensas de una mayor sobrecarga sobre el hiperciclo, pero inferior a la ofrecida por el servicio AR_nPoll.

En la Fig. 20 se muestra el hiperciclo en condiciones normales y en la Fig. 21 en el caso de aparecer dos peticiones. Después de ser detectada la primera petición, se realiza una servicio punto a punto. A continuación se envía otra consulta AR_mpr, en la que se manifiesta una segunda petición, se atiende y finalmente se realiza otra consulta, la cual no detecta nodo alguno, por lo que se continúa con la planificación.

Planificación TT + ET esporádica de alta prioridad con cambio de modo

Otra forma de plantear la resolución del comportamiento del bus ante situaciones de emergencia, consiste en conmutar a un funcionamiento basado en un hiperciclo adecuado al caso, también denominado cambio de modo. Este hiperciclo de emergencia suele tener como objetivo el mantenimiento de las propiedades básicas del sistema. En la Fig. 22 se plantea el mantenimiento de los servicios de comunicación únicamente a los nodos 1 , 2, 3 y 4, y una serie de consultas de difusión. La primera de estas consultas se dedica a comunicar al resto del bus el evento de emergencia (confirmación de recepción). La última consulta de difusión se emplea para consultar la posibilidad de reenganchar de reiniciar el hiperciclo normal o reanudarlo (en la figura se reinicia).

Para diferentes casos de emergencia pueden existir diferentes hiperciclos o un único hiperciclo de tratamiento común de las situaciones de emergencia. En cualquier caso ello dependerá de los requerimientos de la aplicación.

Planificación TT + ET de alta prioridad + ET de baja prioridad

Por último se presenta una planificación combinada de las anteriores. Esta planificación permite a una aplicación el siguiente planteamiento:

ETesporádicas TT ETregulares

(de alta prioridad) ( a prioridad) mensajes de alarma mensajes periódicos mensajes aperiódicos

La diferencia entre el conjunto ET de alta y baja prioridad se puede establecer empleando el campo de prioridad (dos bits) de los servicios de consulta.

En la figura 23 se muestra una posible solución compuesta de servicios AR_evPoll (ó AR_nPoll si se requiere mas seguridad).

Claims

REIVINDICACIONES 1.- Método de comunicación serie con esquema de funcionamiento de tipo maestro - esclavo, optimizado para una arquitectura basada en un microcontrolador dotado de una UART para cada nodo ya sea maestro o esclavo, cuyo nodo maestro siempre actúa como estación primaria y los nodos esclavo como estaciones secundarias y en donde la planificación de la vía de comunicación consiste en una distribución de unos mensajes que circulan por dicha vía , formados en general por un conjunto de grupos de mensajes de transferencia de datos incluyendo al menos un mensaje de escritura desde el nodo maestro a un nodo esclavo, seguido de, opcionalmente, un mensaje de lectura o respuesta del mismo nodo, encadenados de forma sucesiva formando un ciclo normal de comunicación, caracterizado por comprender la utilización de unas tramas especiales de consulta, de varios tipos, las cuales están previstas para ser intercaladas entre dichos grupos de mensajes, donde sea necesario desde el punto de vista de la aplicación, generando unas consultas o una acción de supervisión capaz de alcanzar a todos los nodos para detectar desde el nodo maestro si en alguno de dichos nodos esclavo se produce alguna situación de urgencia que precise una atención inmediata por parte del nodo maestro, con la posibilidad de que dichas tramas especiales sean empleadas, en otros esquemas de funcionamiento, como un mecanismo básico de distribución de dichos mensajes de datos, precediendo a los mismos.

2.- Método, según la reivindicación 1 , caracterizado porque se aplica en una topología de bus, para el control y gestión del estado de una pluralidad de nodos esclavos conectados a un nodo maestro a través de al menos un bus, operando dentro de un sistema de comunicación que ofrece los servicios de acceso al medio usados para la compartición del bus de comunicación de datos entre múltiples nodos, y demás funcionalidades requeridas para el intercambio de información serie, serialización/deserialización, la interacción con el usuario local del sistema de comunicación y la interacción con una capa física .

3.- Método, según la reivindicación 1 , aplicado a la resolución de la transferencia de información entre el nodo maestro y los nodos esclavos obedeciendo a tres formas de operativa: mensajes cíclicos de datos;

- mensajes acíclicos de datos de baja prioridad; y

- mensajes acíclícos, esporádicos, de datos de alta prioridad.

4.- Método, según la reivindicación 3, en donde la planificación de transferencia de datos es cíclica y para el tratamiento de mensajes acíclicos, esporádicos, de alta prioridad, se procede a la citada inclusión intercalada de dichas tramas especiales de consulta que, en caso de detectar una petición de atención, en al menos uno de los citados nodos esclavo, provoca una atención del nodo maestro con mensajes de transferencia de datos punto a punto que se pueden incluir mediante dos procedimientos: un alargamiento del ciclo de comunicación, en caso de estar justificado por la urgencia o un cambio de modo consistente en una conmutación a un funcionamiento basado en un ciclo de emergencia adecuado al caso.

5.- Método, según la reivindicación 3, caracterizado porque en el caso de tratamiento de mensajes acíclicos de datos de baja prioridad, comprende un mecanismo consistente en un bucle de consulta continuo desde el nodo maestro basado en el empleo de una o varias de las citadas tramas especiales de consulta, consecutivas, hasta la detección de una o varias peticiones de atención, en cuyo caso son atendidas, mediante el empleo de tramas de datos, para posteriormente continuar con las tramas de consulta.

6.- Método, según la reivindicación 3, caracterizado porque la planificación de bus está constituida por una integración de intervalos de transferencia de datos cíclicos junto con intervalos de consulta reservados para la detección de las peticiones de atención de baja prioridad, realizadas mediante inclusión de dichas tramas especiales en dichos intervalos y la atención correspondiente mediante tramas de datos.

7.- Método, según la reivindicación 3, caracterizado porque para resolver el conjunto de las tres formas de operativa emplea intervalos reservados para mensajes cíclicos e intervalos reservados para mensajes acíclicos de baja prioridad, y en donde los primeros además, están sujetos a la inclusión, periódica de tramas especiales de consulta para detectar peticiones de atención de alta prioridad.

8.- Método, según la reivindicación 2, caracterizado porque dichas tramas especiales de varios tipos son las siguientes:

• trama constituida únicamente por un byte para usos específicos,

• trama SingleSlot: constituida por un único slot o ventana temporal de respuesta de los nodos esclavo dedicado a la detección de peticiones de atención de dichos nodos sin identificar cual o cuales la solicitan;

• trama MultiSlot: constituida por múltiples slots o ventanas temporales de respuesta de los nodos esclavo, dedicado a la detección de peticiones de atención de dichos nodos identificando cual o cuales la solicitan;

• trama SlotContention: o de contienda de slot constituida por un número determinado de slots o ventanas temporales de respuesta, cuyo objeto es detectar la petición de atención de máxima prioridad presente en el bus, identificando de que nodo procede y con que prioridad la emite.

9.- Método según la reivindicación 8, caracterizado porque todas las citadas tramas especiales tienen en común el significado de los campos A/C y extra del primer byte de trama, cuyos campos además de formar parte de la cabecera, identifican el tipo de trama de que se trata y porque las tramas de tipo Slot, están compuestas todas ellas por cuatro partes consecutivas: a.- cabecera de trama formada por al menos un byte inicial, que contiene el campo indicador del tipo de trama y un campo extra; b.- intervalo de cambio a modo respuesta; c- intervalo de respuesta constituido por ventanas temporales de respuesta, y d.- intervalo de salida de modo de respuesta, de forma que los intervalos b, c, y d vienen predeterminados por unos valores temporales conocidos por todos los nodos del bus, almacenados en unas tablas residentes en cada uno de los nodos.

10.- Método, según la reivindicación 2, caracterizado porque para la trasferencia de datos entre el nodo maestro y los nodos esclavos en un ciclo normal de bus se utiliza una trama que comprende ocho campos de información: dirección destino (addr), número de secuencia (seq), longitud de datos (dlen), comando u orden asociado (cmd), indicación de servicio de depuración (debug), datos (data), campo redundante para detección de errores (chk) y fin de trama (EOF ó End of Frame), cuya trama es la de uso general empleada por el sistema de comunicación para transferencia entre los usuarios de dicha capa y estando definido el contenido de la mayoría de estos campos por el usuario de la primitiva de servicio request y, en el resto (chk, EOF) viene definido por el propio sistema de comunicación, siendo el formato de trama orientado a carácter.

11.- Método, según la reivindicación 9, caracterizado porque la trama byte está formada por un solo byte, con el bit mp, usualmente el bit destinado a ubicar la paridad, activado, cuya trama byte está prevista para ser leída por todos los nodos del bus y para ser usada en circunstancias donde se requiera una elevada velocidad, a expensas de no disponer de redundancia en la detección de errores, y cuando existen nodos en los que se ha producido una cierta degradación del sistema de comunicación, en donde la recepción y ejecución asociada a una trama de este tipo, tal como caracteres de reset remoto, aumenta las posibilidades de éxito.

12.- Método, según la reivindicación 9, caracterizada porque la trama SingleSlot es de difusión especializada en la consulta y durante el intervalo de respuesta los nodos esclavos manifiestan el estado de un determinado bit, o bit de referencia, dedicado a una indicación de petición de atención, ubicado en cada uno de los nodos esclavos, el estado de cuyo bit es activado internamente por cada nodo, permitiendo detectar, mediante una breve consulta un estado "afirmativo" de dicho bit de referencia en alguno o varios de los nodos esclavos conectados al bus, sin identificar en cual de ellos.

13.- Método, según la reivindicación 12, caracterizado porque durante el citado intervalo o ventana de gestión temporal las UART de todos los nodos se deshabilitan pasándose a un tratamiento del bus basado en el acceso directo al mismo sin el empleo de la UART.

14.- Método, según la reivindicación 12, caracterizado porque en caso de producirse una respuesta por uno o más de los nodos esclavo, dicha respuesta o respuestas se superpone o superponen en el citado intervalo temporal, dominando el nivel dominante sobre cualquier número de respuestas recesivas simultáneas.

15.- Método, según la reivindicación 9, caracterizado porque la trama MultiSlot es de difusión especializada en la consulta y dicho intervalo de respuesta comprende una serie de ventanas de consulta/respuesta para comprobar el estado afirmativo o negativo de un bit X, o de referencia, ubicado en cada uno de los nodos esclavos, asociándose el estado de cada nodo esclavo de forma unívoca a una de las citadas ventanas de respuesta, evitando la superposición de las respuestas y muestreando así, desde el nodo maestro cada respuesta de los correspondientes esclavos, y porque en caso de ser el estado del bit X afirmativo, la ventana de respuesta del citado nodo esclavo se manifiesta a nivel recesivo, equivalente a nivel de bus de reposo o silencio, y en caso de ser dicho estado del bit X, negativo, se manifiesta con un impulso dominante.

16.- Método, según la reivindicación 15, caracterizado por una codificación PWM de las ventanas de respuesta obtenidas a nivel de bus y porque el procedimiento de sincronismo entre nodo maestro y nodos esclavos consiste en un tren de impulsos PWM generado por el nodo maestro, dejando a nivel recesivo gran parte del slot para que el nodo esclavo manifieste, si lo desea, una prolongación del nivel dominante detectable por el nodo maestro y cuya prolongación debe acabar antes del fin de slot para finalizar el slot a nivel recesivo, determinando los flancos descendentes de dichos impulsos el límite de cada una de las citadas ventanas del intervalo de gestión directa asociada a cada nodo esclavo, en cuyo procedimiento se actúa y/o se muestrean las señales de transmisión/recepción, con habilitación de la transmisión de forma directa sin el empleo de las UART de los nodos que se mantienen deshabilitadas a lo largo de dicha serie de ventanas de gestión temporal.

17.- Método, según la reivindicación 15, caracterizado porque el procedimiento de sincronismo y respuesta de peticiones de atención entre nodo maestro y nodos esclavos consiste en la transmisión por parte del nodo maestro, empleando su UART, de unos caracteres con todos los bits de datos Y EL BIT MP a nivel recesivo, de forma que el flanco descendente del bit de inicio (start) marca la ventana de respuesta de los caracteres procedentes de los nodos esclavos que deben responder superponiendo dicho carácter sobre la trama enviada por el citado nodo maestro, de manera que cada nodo esclavo sólo mantiene a nivel dominante, uno de los bits de datos del carácter de respuesta, facilitando su identificación y solo si el bit de referencia es negativo.

18.- Método, según la reivindicación 17, caracterizado porque cada bit de cada carácter está asignado a un nodo esclavo específico y porque los caracteres de respuesta pueden tener una velocidad de transmisión igual o inferior a la velocidad estándar, o la de los caracteres iniciales de trama, igual para todos los nodos y que está especificada en la configuración de bus.

19.- Método, según la reivindicación 18, caracterizada porque en la trama

MultiSlot se reservan unos intervalos temporales para realizar los cambios de velocidad de la configuración de las respectivas UART de todos los nodos.

20.- Método, según la reivindicación 17, caracterizado porque durante todo el período de respuesta los nodos esclavo identifican el carácter de la trama del nodo maestro al cual deben superponerse por el número de caracteres de tipo respuesta enviado hacia dicho nodo maestro.

21.- Método, según la reivindicación 15, en el cual el intervalo de respuesta de los nodos esclavos está constituido por una serie de ventanas, de igual tamaño, cuyos límites vienen definidos por una división temporal de dicho intervalo, sin el empleo de ninguna señal de sincronismo, y porque en cada una de dichas ventanas el nodo esclavo correspondiente responde con un pulso a nivel dominante si la respuesta es negativa y a nivel recesivo si es positiva, y porque previamente al intervalo de respuesta y posteriormente al inicio de trama se añade un byte para sincronizar todos los nodos esclavos en el inicio del intervalo de respuesta.

22.- Método, según la reivindicación 21 , caracterizado porque el nodo esclavo identifica su ventana de respuesta dentro del intervalo por la medida de tiempo transcurrida desde el inicio de dicho intervalo.

23.- Método, según la reivindicación 15, caracterizado porque en el caso de que un determinado nodo esclavo esté en mal estado y no responda, se interpreta como el peor caso posible, es decir como bit de referencia X, afirmativo, equivalente en los usos de esta trama a una petición de atención o como mensaje de datos de difusión, previo, no recibido correctamente.

24.- Método, según la reivindicación 9, caracterizado porque la trama SlotContention es de difusión especializada en la detección de un nodo esclavo con un bit X o de referencia afirmativo, seleccionado de entre los restantes por mecanismos de contienda de slot y dicho intervalo de respuesta está reservado para la transmisión de un byte desde dicho nodo esclavo, cuyo byte está formado por tres campos, los cuales, ordenados por orden de transmisión al bus son: un bit reservado opcional, dos bits de prioridad y cinco bits de dirección correspondientes a la propia dirección del nodo o estación esclava, con el fin de evitar la existencia de dos bytes iguales emitidos desde diferentes nodos esclavos y transmitiendo los bits de cada campo ordenados de mayor a menor peso, y porque durante dicho intervalo de respuesta todos los nodos esclavos, en curso, intentan manifestar dicho estado afirmativo sobre el bus, consiguiendo sólo la petición de más prioridad, acceder totalmente al bus y el resto se retiran, esperando la finalización de la trama.

25.- Método, según la reivindicación 24, caracterizado porque la prioridad de la petición viene determinada por una comparación bit a bit del byte citado, de los diferentes nodos con petición, empezando por el bit de mayor peso del campo de prioridad y siguiendo con el bit de mayor peso del campo de dirección.

26.- Método, según la reivindicación 25, caracterizado porque dicho mecanismo de contienda se lleva a cabo en cada slot de manera que cuando varios nodos esclavo pretenden manifestar el estado afirmativo de su bit de referencia, ponen en el bus el bit del citado byte de petición correspondiente al slot en curso y de estos nodos, los que detecten que el slot ha adoptado el mismo nivel que ellos han enviado, continuarán luchando en el próximo slot, mientras que el resto, habrán detectado un nivel en el bus contrario al enviado, retirándose del proceso de contienda durante el resto de la ventana de respuesta, continuando el proceso hasta que finalmente sólo un nodo consigue poner los dos campos de prioridad y dirección de su byte en la petición de atención.

27.- Método, según la reivindicación 3, en la cual los mensajes cíclicos están agrupados en pares constituyendo cada par un servicio SendPPUDR de escritura/lectura, donde el primer mensaje, denominado de escritura, es transmitido del nodo maestro a un nodo esclavo, y el segundo mensaje, denominado de lectura, es transmitido del nodo esclavo al nodo maestro, de manera que el mensaje de lectura, en situaciones normales, finaliza antes de transcurrido un tiempo máximo prefijado, establecido desde el nodo maestro.

28.- Método, según la reivindicación 27, caracterizado porque en caso de no finalizar la recepción del citado mensaje de lectura en el nodo maestro, antes de transcurrido dicho tiempo máximo, dicho nodo maestro envía un nivel de bus dominante coincidiendo con dicho mensaje de lectura, de duración suficiente para provocar un error en un carácter transmitido de dicho mensaje de lectura procedente del nodo esclavo, permitiendo a este último detectar dicho error y cancelar la transmisión del citado mensaje de lectura.

29.- Método, según la reivindicación 27, caracterizado porque en caso de que transcurrido dicho tiempo máximo prefijado y no recibirse respuesta alguna del nodo esclavo, también se envía desde el nodo maestro un nivel de bus dominante que provoca en el nodo esclavo la cancelación de una posible transmisión retardada de un mensaje de lectura.

30.- Método, según la reivindicación 27, caracterizado porque en caso de encontrarse el nodo esclavo en una situación de recepción de un mensaje de datos, desde el nodo maestro, si dicho nodo esclavo detecta un carácter inicial de trama, cancela el servicio en curso y continua con la recepción de la nueva trama aprovechando este último byte de inicio de trama, evitando que el nodo esclavo se quede bloqueado por una desincronización de trama.

31.- Método, según la reivindicación 11 , caracterizado porque la recepción consecutiva de dos o más tramas tipo byte, con un valor específico que no aparece en las tramas normales, intercaladas en cualquier punto de dichos grupos de mensajes, provoca el reset del sistema de comunicación local del nodo esclavo que los reciba.

32.- Un medio legible por un computador codificado con un programa para realizar un método de construcción de una trama de SingleSlot, conforme a una cualquiera de las reivindicaciones de la 12 a 14.

33.- Un medio legible por un computador codificado con un programa para realizar un método de construcción de una trama de MultiSlot, conforme a una cualquiera de las reivindicaciones de la 15 a la 23.

34.- Un medio legible por un computador codificado con un programa para realizar un método de construcción de una trama de SlotContention, conforme a una cualquiera de las reivindicaciones de la 24 a la 26.

35.- Un medio legible por un computador codificado con un programa para realizar un método de planificación de uso temporal de un bus de comunicación serie de acuerdo a los criterios de la reivindicación 4 a 7.