¿Cómo equilibrar AUTOSAR, IEEE y TSN?
Varias funciones del sistema en el vehículo requieren una sincronización precisa de la referencia de tiempo básica entre las ECU. Debido a la aplicación de Ethernet en automóviles, los desarrolladores y arquitectos de sistemas necesitan resolver las medidas de sincronización de tiempo de alguna manera. Porque el método existente no se puede utilizar para Ethernet. Expertos en diferentes campos han establecido comités dedicados a aplicar Ethernet a tareas que requieren alta precisión de tiempo.
La aplicación Ethernet en el automóvil tiene una amplia gama. Además de los sistemas avanzados de asistencia al conductor (ADAS) que utilizan cámaras y sensores (radar), transmisión de audio / video en tiempo real y sincronización de la red troncal con varios dominios físicos, la grabación de datos a bordo también es parte de tales casos de uso. Además, los dispositivos conectados a través de una red Ethernet ciertamente deben sincronizarse con otros sistemas físicos (como CAN y FlexRay).
Ethernet es un estándar basado en la premisa de las redes informáticas y los entornos de oficina, y no tiene el rendimiento en tiempo real necesario para las aplicaciones técnicas. La topología Ethernet de la conexión del conmutador reduce los conflictos innecesarios durante el acceso a la red, pero esto no logra un comportamiento completamente determinista. En particular, la tarea precisa de sincronización de tiempo requiere cualquier información sobre el tiempo de propagación en la ruta de transmisión y el tiempo de retardo asociado con conmutadores y pasarelas.
Este es un problema inevitable cuando se controlan sistemas conectados a Ethernet, razón por la cual varias organizaciones de estandarización están trabajando arduamente para agregar rendimiento en tiempo real a Ethernet, incluidos los mecanismos de sincronización de tiempo. En la actualidad, el método principal de sincronización de tiempo utilizado en la industria automotriz es formular AUTOSAR 4.2.2, IEEE802.1AS y el grupo de tareas de puente de audio / video (ahora grupo de tareas TSN (Time Sensitive Networking)). Basado en el IEEE802.1AS-rev revisado.
El concepto de hora global de AUTOSAR
El concepto AUTOSAR 4.2.2 proporciona un GlobalTime Master (GTM) definido estáticamente. La ECU asigna la hora más precisa de toda la red al GTM. Los subdominios derivados se pueden extender a diferentes medios físicos. Time Gateway comienza desde un puerto esclavo y pasa el tiempo al punto final (Time Slave) u otros Time Gateways a través de uno o más puertos maestros. El tiempo de sincronización debe modificarse de acuerdo con el tiempo de retardo requerido para el procesamiento interno de estas pasarelas. Como otra forma, AUTOSAR también permite que las bibliotecas de tiempo independientes se configuren por separado, y la hora actual se "inyecta" en ellas desde cada puerta de enlace.
Los detalles del proceso de sincronización dependen del tipo de red. Si es CAN o Ethernet, Time Slave comparará la marca de tiempo del remitente con su propia marca de tiempo de recepción para corregir la base de tiempo global recibida. FlexRay es un sistema determinista con un tiempo de ciclo fijo y se ejecuta estrictamente de acuerdo con un modo de tiempo predefinido, por lo que la sincronización es más simple que esto, y el tiempo lo proporciona implícitamente el reloj FlexRay. CAN siempre calcula la marca de tiempo en el software, mientras que Ethernet lo calcula en el software o el hardware. Además, CAN y FlexRay pueden realizar hasta 16 dominios de tiempo. Por el contrario, Ethernet solo funciona en un dominio de tiempo, el "Dominio de tiempo global".
La base de la sincronización de la ECU de Ethernet: IEEE802.1AS
A partir de AUTOSAR 4.2.1, ahora está disponible Synchronized Time Library Manager (StbM). Abstrae los generadores basados en tiempo específicos de bus FlexRay, CAN y Ethernet (módulo proveedor de sincronización BusTime) como un entorno de tiempo de ejecución para utilizar el "tiempo de demostración" en las aplicaciones. Los protocolos individuales utilizados en cada bus físico se implementan en el módulo TimeSync. Ethernet BusProvider se basa en el "tiempo de precisión generalizado" IEEE802.1 utilizando el "Protocolo (GPTP)". Para hacerlo compatible con casos de uso comunes en automóviles, se deben realizar varios cambios, adiciones y, a veces, restricciones dentro del alcance de AUTOSAR.
Al presentar la diferencia entre Ethernet, CAN y FlexRay, primero introduzcamos las características básicas de la sincronización de CAN y FlexRay.
Ambos tienen 16 bibliotecas de tiempo sincronizado y hasta 16 bibliotecas de tiempo de compensación conectadas estáticamente. En CAN, la información horaria se transmite a través de dos mensajes. El primer mensaje contiene información de segundos y el segundo mensaje contiene información de nanosegundos. Por lo tanto, para detectar desbordamientos que pueden ocurrir en el rango de nanosegundos, el segundo mensaje contiene detección de desbordamiento. "Time Gateway Synchronization Status" se utiliza para detectar si la aplicación está sincronizada con el subdominio y el Global Time Master. También utiliza recuento de secuencia y verificación de redundancia cíclica (CRC).
Realización de gPTP para automóvil
IEEE 802.1AS especifica un método estándar para sincronizar la hora en una red Ethernet conectada a través de un conmutador. Consiste en tres procesos centrales: transferencia de tiempo de sincronización (Sync / Follow_Up), medición del tiempo de retardo de propagación de mensajes (Pdelay) y mejor algoritmo de reloj maestro (BMCA) .La sincronización real son los dos compuestos por mensaje de sincronización y paso de mensaje de seguimiento. Pdelay es un protocolo especial que se utiliza para medir el tiempo de retardo de propagación de mensajes entre dos puertos. No solo eso, la ECU también puede usar Pdelay para detectar si pertenece a un "sistema de sincronización de tiempo", es decir, una red con una función de sincronización de tiempo. A través del mejor algoritmo de reloj maestro, determine el nodo de la red, si es posible, configure dinámicamente la ECU que proporcione el mejor tiempo del sistema para los nodos incluidos en la red y configúrelo como el Maestro Global.
Sin embargo, la implementación en el automóvil es muy diferente del estándar IEEE. IEEE permite configuraciones dinámicas como la topología de red y BMCA (selección Global Master), mientras que la mayoría de los autos están predefinidos estáticamente. Esto es necesario para crear una descripción del sistema única y optimizar la matriz de comunicación. Otras diferencias son que el software / hardware admite marcas de tiempo, ya sea que haya datos de carga útil y su contenido, y el vehículo debe estar equipado con VLAN por razones de seguridad.
Proporcionar información sobre el puerto a través del controlador de conmutador extendido
Un desafío importante que dificulta la sincronización horaria precisa en Ethernet es que AUTOSAR 4.2.2 tiene una respuesta limitada a las funciones del conmutador Ethernet. En otras palabras, el controlador del conmutador no puede reenviar el número de puerto del mensaje recibido a la capa superior. Como resultado, la transmisión de puertos específicos de mensajes Sync y Follow_Up se vuelve difícil, y el mecanismo Pdelay en el conmutador básicamente no está disponible. El mecanismo Pdelay no puede asignarlos a cada puerto de comunicación, porque la solicitud Pdelay enviada activará múltiples respuestas (Pdelay_Resp / Pdelay_Resp_Follow_Up). Por lo tanto, Pdelay no proporciona información útil. Además, la especificación actual no permite que los conmutadores establezcan individualmente marcas de tiempo específicas del puerto. Es imposible determinar el retraso en el cambio, ni hacer una corrección de tiempo precisa. AUTOSAR 4.3 mejora esta situación y se espera que aumente la función IEEE-802.1AS compatible. Específicamente, la información del conmutador específico del puerto es compatible de forma constante desde el controlador del conmutador y el controlador Ethernet hasta los componentes básicos del software en su conjunto, y ahora debería ser posible utilizar los sellos de entrada y salida necesarios.
Datos de carga útil: un elemento indispensable
Cuando se usa IEEE802.1AS en un vehículo, se deben tomar algunas otras medidas. En relación con esto se encuentran cuestiones tales como "datos de carga útil (específicos del fabricante de automóviles)", compatibilidad con múltiples dominios de tiempo, redundancia y estrategias de copia de seguridad. Los datos de la carga útil son información adicional en el mensaje de seguimiento y no están cubiertos por este estándar. Sin embargo, esto es esencial para aplicaciones y funciones especiales, como información de depuración y otra información de estado.
Como contramedida para solucionar este problema. La información adicional requerida se almacena en el campo de valor de longitud de tipo específico (TLV) de AUTOSAR contenido en el mensaje gPTP, y TimeSlave evalúa o ignora este campo de acuerdo con la configuración.
Insuficiencia del dominio del tiempo en los estándares IEEE
IEEE802.1AS actualmente solo proporciona un dominio de tiempo. Sin embargo, las aplicaciones automotrices requieren más dominios de tiempo para evaluar la hora UTC, la hora del GPS y las señales específicas del sensor. Por lo tanto, los números de campo existentes en el encabezado del mensaje gPTP deben tener un número mayor que cero. En IEEE 802.1AS, el número de dominio permitido actualmente es sólo "0" y el nodo ignorará otros valores. La especificación TSN actual (IEEE 802.1AS-ref) incluye recientemente al menos un dominio de tiempo en la forma de ser agregado al IEEE 802.1AS. Sin embargo, esto no es suficiente para cumplir con los requisitos de los automóviles. Para solucionar este problema, AUTOSAR permite la definición de dominios de tiempo adicionales.
Utilice estándares de respaldo para lograr una sincronización tolerante a fallas
En la futura arquitectura del vehículo y la versión AUTOSAR, las personas prestan cada vez más atención a las cuestiones de seguridad y protección. Al mismo tiempo, cuando falla el Global Time Master definido estáticamente, surge repentinamente el problema de cómo el host de respaldo generalmente maneja el concepto de redundancia. Para ello, se necesita al menos otro generador de tiempo que continúe funcionando como host de respaldo. El mejor algoritmo de reloj estándar actual no puede resolver este problema. BMCA es relativamente lento y funciona según la detección del tiempo de espera, por lo que la ECU ha entrado en un estado de tiempo de espera de sincronización que debería haber evitado. El estándar debe prevenir la ocurrencia de tiempos de espera de sincronización, no operando en nombre de cada uno en lugar de en tal forma. El Comité de Desarrollo de Normas seguirá debatiendo una gran cantidad de cuestiones, incluidas estas.
En conclusión
IEEE802.1AS es un material de referencia apropiado para realizar la sincronización de tiempo en Ethernet, y el protocolo gPTP conforme al estándar IEEE se puede utilizar en el campo de infoentretenimiento. Obviamente, habrá más requisitos automotrices en el futuro estándar TSN, pero aún se desconoce hasta qué punto es completo. En cualquier caso, IEEE y AUTOSAR continúan desarrollándose y se complementan. Sin embargo, debido a la diferencia en sus ciclos de lanzamiento, llevará mucho tiempo completarlo.
Es importante que los arquitectos, desarrolladores y proveedores de sistemas puedan hacer avanzar los proyectos de Ethernet de manera eficiente y económica. Las herramientas de desarrollo de operador pueden admitir hardware Ethernet específico, como ECU vectorial y herramientas de prueba de red CANoe y MICROSAR en el software básico AUTOSAR. Estos productos admiten la sincronización de tiempo basada en gPTP basado en AUTOSAR o gPTP compatible con IEEE. También proporciona funciones y soluciones de software para usar el tiempo sincronizado para la transmisión de audio / video, etc.