Aunque el protocolo CAN en sí tiene una fuerte capacidad de detección y corrección de errores, en el sitio de control industrial, la conexión del enchufe no es sólida, el medio de transmisión está dañado o el controlador del bus está dañado, etc., destruirán la comunicación confiable de CAN. En el sistema de aplicación que requiere alta confiabilidad, estas fallas, si no se detectan automáticamente y se toman las medidas adecuadas para superarlas, harán que el sistema pierda parcial o incluso completamente la capacidad de comunicarse. Una forma eficaz de resolver este problema es utilizar un control de comunicación redundante. Esto asegura que las funciones principales del sistema de comunicación funcionen normalmente, mejorando así la confiabilidad del sistema.
1 Componentes de hardware del sistema
El MB90F543 es un microcontrolador de 16-bit con dos controladores CAN de Fujitsu. El sistema utiliza dos conjuntos de buses (CAN0, CAN1), cada uno de los cuales contiene cables de bus independientes, controladores de bus y controladores de bus, que pueden lograr una redundancia total de los medios físicos, la capa física, la capa de enlace de datos y la capa de aplicación. Los dos conjuntos de buses funcionan en modo de respaldo en caliente: un controlador CAN sirve como CAN predeterminado después de que se enciende el sistema (que puede denominarse CAN maestro); el otro sirve como CAN de reserva del sistema (que se denomina CAN esclavo) y sirve como redundancia para el CAN maestro. Cuando el sistema funciona normalmente, el bus CAN maestro (CAN0) se pone en funcionamiento. Cuando falla el bus CAN maestro, el bus CAN esclavo (CAN1) entra en funcionamiento. Si el -arranque detecta una falla en el bus CAN maestro, el bus CAN esclavo se pone en funcionamiento automáticamente. De esta manera, cuando falla un conjunto de buses, el otro conjunto de buses continuará funcionando automáticamente para garantizar el funcionamiento normal de la función de comunicación de todo el sistema, lo que mejora en gran medida la confiabilidad del sistema y logra el diseño de redundancia integral del bus CAN. Además, según las necesidades del software, también se puede configurar para que adopte el modo redundante o no-redundante. Para el modo no redundante, sólo se utiliza el bus CAN principal.
Diagrama de bloques de la arquitectura del sistema
RT es la resistencia de adaptación de terminación de bus, utilizada para suprimir la interferencia de emisión de señal, RT=100Ω o 120Ω. La red utiliza cable de par trenzado blindado como medio de comunicación.
El controlador CAN integra las funciones de capa física y capa de enlace de datos del protocolo CAN y puede completar el proceso de encuadre de la comunicación de datos, incluido el relleno de bits, la codificación de bloques de datos, la suma de comprobación CRC y la discriminación de prioridad.
El controlador CAN tiene las siguientes características principales:
◇ Cumple con los protocolos CAN2.0A y CAN2.0B.
◇ Admite el envío y recepción de tramas de datos y tramas remotas.
◇ 16 buffers de envío/recepción de mensajes, que admiten identificadores de 11-bit o 29-bits y una estructura de buffer de mensajes multi-nivel; ◇ Admite comparación-de bits completos, comparación de bits completos y comparación de bits completos.
◇ Admite tres métodos de selección de identificación de aceptación: comparación-de bits completos, enmascaramiento-de bits completos y aceptación de enmascaramiento de bits; ◇ Dos registros de identificación de aceptación.
◇ Dos registros de identificación de aceptación admiten formato de marco estándar o marco extendido.
◇ La velocidad en baudios es programable de 10 Kbps a 1 Mbps.
El conductor del autobús adopta PCA82C250 como interfaz entre el controlador CAN y el bus físico para mejorar la capacidad diferencial de transmisión y recepción del autobús.
2 Diseño del software del sistema
2.1 Realización de la función de control redundante CAN dual
En el sistema de redundancia CAN dual, en comparación con la estructura del hardware, el diseño del software es relativamente más complejo. El programa general de comunicación del bus CAN debe incluir tres partes básicas: programa de inicialización CAN, programa de transmisión CAN y programa de recepción CAN. En este diseño de software de sistema redundante, las tres partes anteriores se utilizan como los tres módulos más básicos para que los llamen otros módulos de software del sistema.
MB90F543 puede manejar 256 tipos de fuentes de interrupción, y hay cuatro interrupciones de hardware relacionadas con el controlador CAN: CAN0 RX (CAN0 recibe interrupción completa), CAN0 TX /NS (CAN0 envía interrupción completa/cambio de estado de nodo), CAN1 RX (CAN1 recibe interrupción completa), CAN1 TX /NS (CAN1 envía interrupción completa/cambio de estado de nodo). CAN1 TX /NS (transmisión CAN1 completa/interrupción de cambio de estado de nodo). En este diseño de software, se utilizan el envío de consultas y la recepción de interrupciones. La subrutina de interrupción de cambio de estado de nodo se utiliza para el procesamiento del cambio de estado de nodo. Esto se debe a que el protocolo CAN2.0 especifica que el nodo se encuentra en uno de los tres estados siguientes: error-estado activado, error-estado ignorado y estado fuera-bus. En la serie MB90500, también hay un estado de advertencia adicional, que indica que el valor del contador de errores de transmisión/recepción ha excedido 96, y un cambio en el estado del nodo provocará la interrupción correspondiente.
Dado que el sistema funciona con modo de espera activo con redundancia CAN dual, ambos controladores CAN deben estar en estado de espera activo. Ambos controladores CAN de todos los nodos del sistema se inicializan para estar listos para recibir mensajes en cualquier momento, pero solo un controlador CAN está enviando mensajes. Es decir, en un momento dado, uno y sólo uno de los canales CAN está activo, mientras el otro está escuchando (en funcionamiento normal) o en estado de fallo (en caso de fallo).
La clave de la complejidad del diseño del software de un sistema de control redundante CAN dual en comparación con un sistema de control CAN único radica en la detección de fallas del sistema CAN y la conmutación automática del sistema CAN. Debido al uso de dos conjuntos de medios de transmisión completamente independientes, conductores de autobús y controladores de autobús, se pueden detectar independientemente de sus propios fallos de canal, como cortocircuitos- de CANH y CANL, desconexión de CANH o CANL, cortocircuitos-de CANH y tierra, cortocircuitos- de alimentación y CANL, daños al conductor del autobús, etc. En la depuración real, se encuentra que si CANH, CANL están desconectados o solo hay un transmisor en el bus, hará que el contador de errores de transmisión/recepción aumente a 128, lo que coloca al nodo en el estado de error ignorado; y un cortocircuito-entre CANH y CANL, un cortocircuito-entre CANH y tierra, o un cortocircuito-entre CANL y la fuente de alimentación hará que el contador de errores de transmisión/recepción aumente a 256, lo que coloca al nodo en el estado de bus desconectado. Por lo tanto, al llamar al módulo de redundancia CAN en la subrutina de interrupción de cambio de estado del nodo, podemos lograr el propósito anterior de detección automática de fallas y conmutación automática del sistema CAN. La subrutina de interrupción de cambio de estado del nodo CAN0 es la siguiente:
__interrupt nulo NodeStateTransmitInt0 (nulo)
{
if (CSR0_NT) /* cambio de estado del nodo */
{
CSR0_NT=0; /*Restablecimiento del indicador de interrupción */
if ( (CSR0_NS==2 ) (CSR0_NS==3 ) ) /* interrupción o cortocircuito causado */
{
NoWaitFlg=1; /* una bandera mutuamente excluyente */
Error de autobús0( ); /* Bus0Error( ) detiene CAN0 e inicia la subrutina CAN1 redundante */ { NoWaitFlg=1; /* un indicador mutex */
}
}
RCI00 =3; /* cambia la prioridad de interrupción a la prioridad de interrupción del Timer0 */ }
RCI03 =2; /* Cambiar la prioridad de interrupción para priorizar la interrupción del temporizador 0 */ }
}
Además, en el proceso de comunicación del bus CAN, cuando se completa la transmisión de datos de un determinado búfer de información, el bit correspondiente en el registro de finalización de la transmisión se establecerá en 1. En el proceso de consulta de la transmisión, al juzgar este registro, se puede saber si la transmisión se completó o no. Sin embargo, si el envío no se realiza correctamente, el sistema esperará todo el tiempo y provocará que falle. Por lo tanto, el software debe establecer aquí un período de espera, más allá del cual se llamará al sistema de redundancia CAN para detener el canal CAN maestro y habilitar el canal CAN esclavo.
El diseño del software también debe prestar atención al problema de cómo restaurar la tarea de comunicación original después de que se completa la conmutación CAN de respaldo. La solución es preparar una lista de indicadores de tareas, conmutación CAN en espera, leer la tabla para obtener la tarea original del sistema y lograr la tarea de comunicación original de conmutación confiable.
2.2 Realización de la función de gestión de autobuses.
En el diseño del software de este sistema, además del programa de comunicación de datos-en tiempo real para la transmisión y recepción de datos, también se incluye el programa de gestión de comunicaciones para la gestión de cada nodo. Todos los nodos se dividen en nodos maestros y nodos esclavos. La diferencia entre ellos es que el nodo maestro tiene una función de gestión de bus, que le permite realizar estadísticas de nodos en línea, reconocer nodos fuera de línea y tomar medidas para lidiar con ellos; mientras que el nodo esclavo no tiene esta función. Sólo hay un nodo maestro, mientras que se permiten varios nodos esclavos. El programa de función de gestión del bus para el nodo maestro se llama de vez en cuando para determinar si todos los nodos están en línea: si todos los nodos están en línea, el bus se considera normal; de lo contrario, identifique los nodos fuera de línea y trátelos en consecuencia. La idea del diseño es que el nodo maestro del sistema envía una trama remota a todos los nodos esclavos en el bus a intervalos regulares, y cada nodo esclavo la recibe, coloca su propio número de nodo en una trama de datos y la envía al nodo maestro, y el nodo maestro determina si hay una falla del nodo fuera de línea de acuerdo con el número de nodo que recibe. En este sistema, el número de nodo (dirección del módulo) se establece mediante un interruptor DIP en el módulo.
En el proceso de depuración de software, aunque la estructura de hardware de cada nodo es la misma, debido a las diferencias en el cableado de la placa de circuito y la dispersión de los componentes, a menudo ocurre que no todos los nodos esclavos pueden recibir la información enviada por el nodo maestro, o el nodo maestro no recibe toda la información enviada por los nodos esclavos, es decir, hay un problema de pérdida de trama. Este problema se ha resuelto mediante el retraso del software y la optimización del programa de interrupción de recepción.
3 El entorno de desarrollo y la aplicación deben prestar atención a varias cuestiones.
El banco de trabajo de software Softune V3 es un entorno de desarrollo de software integrado para el desarrollo de programas de microcontroladores de las series Fujitsu FFMC-8L, FFMC-16L/LX y FR, que incluye gestión de desarrollo, depuración de emuladores, simulación suave y un entorno de desarrollo integrado. Su conjunto de herramientas de desarrollo incluye Softune Workbench, compilador de C, ensamblador, enlazador, C Checker y C Analyzer. Softune V3 soporta lenguajes C y ensamblador.
Durante el uso real del MB90F543, se deben tener en cuenta los siguientes problemas.
① La configuración del Registro de selección de marcas de aceptación (AMSR). Cada búfer de mensajes puede seleccionar un método de marcado de aceptación: comparación de bits completos, máscara de bits completa o aceptación de máscara de bits. La comparación de -bits completos significa que el ID de la información recibida por el nodo debe ser exactamente el mismo que el ID establecido por el búfer de información para que la información pase el identificador de aceptación; el enmascaramiento de bits completo-no necesita comparar el ID de la información, lo que puede interpretarse como la transferencia incondicional del identificador de aceptación; La aceptación de enmascaramiento de bit- puede especificar los bits de ID que se compararán y los bits de ID que se enmascararán, es decir, comparar parcialmente la aceptación. En la práctica, este método de identificador de aceptación se utiliza con mayor frecuencia, por lo que se configuran dos de estos métodos en el controlador CAN del chip MB90F543. la configuración de AMSR proporciona una gran flexibilidad para que el desarrollador procese la información del búfer.
② Configuración del Registro de marcado de aceptación (AMR). Después de configurar AMSR en el método de aceptación de bit-enmascarado, se debe configurar AMR para establecer qué bits del ID se compararán y qué bits se enmascararán. AMR tiene un total de cuatro bytes y admite caracteres de ID de 29 bits. Sin embargo, vale la pena señalar que para el carácter ID de 29 bits, se utiliza AM28~AM0; mientras que para el carácter ID de 11 bits, se utiliza AM28~AM18. por lo tanto, el usuario debe tener cuidado al configurar AMR o se producirá un error de recepción. El autor ha sufrido aquí.
③ Una de las características del controlador CAN de Fujitsu es que admite el uso de búferes de mensajes multi-nivel. En el caso de que la recepción se produzca con frecuencia, o se reciban varias tramas de información de ID diferentes, es posible que la CPU no tenga suficiente tiempo para procesar la información recibida, por lo que se pueden formar múltiples buffers de información en un buffer de información multi-nivel para garantizar que la información se pueda procesar de manera oportuna y eficiente. De esta forma, se puede enviar información de más de 8 bytes en 1 trama. Otra ventaja de esta disposición es que la CPU puede leer la información de un determinado búfer de información sin tener que preocuparse de que la información del búfer se reescriba y se pierda inmediatamente.
4 Conclusión
En el proceso de desarrollo del protocolo de capa de aplicación CAN, se toman prestados algunos mecanismos de la especificación DeviceNet, como el soporte de múltiples formas de transmisión de datos (pase selectivo, sondeo, cambio de estado, etc.); sin embargo, debido a las limitaciones de muchos factores, como el ciclo de desarrollo, es necesario mejorar y ampliar la función de diagnóstico del dispositivo, así como la interoperabilidad con productos similares. El sistema de comunicación redundante CAN dual funciona de manera estable en la etapa experimental, la transmisión de datos es confiable, la conmutación de redundancia es practicable y la confiabilidad de la gestión del bus es buena; se puede aplicar al sistema de control de locomotoras u otros sitios de control industrial que requieren alta confiabilidad.