Con la versión 2.3 de la especificación PROFINET, pasar la prueba de carga (prueba de carga útil) se ha convertido en obligatorio para obtener una certificación. ¿Pueden los MCUs embedded pasar estas pruebas? Sí, si los stacks y los fabricantes de MCU han hecho sus deberes, como este articulo usando el Renesas RX63N y los stacks de PROFINET de port GmbH demuestran.
No hay duda, con el advenimiento del Ethernet industrial en el mundo de la automatización, los requisitos en potencia de computación y complejidad en la implementación se han incrementado. Mientras para dispositivos CANopen simples, un procesador de 8 bits era más que suficiente, este no es el caso para protocolos como PROFINET.
Parcialmente, los responsables de esto son, por un lado los grandes volúmenes de datos y, por otro, la versatilidad de servicios, los cuales, al margen de los protocolos industriales de Ethernet son también ofrecidos por protocolos Ethernet y los extensos protocolos basados en IP.
Así, se vuelve aún más importante examinar estas cargas en paralelo a la comunicación de control estándar.
Sin embargo, antes de evaluar estos retos usando el RX63N como un ejemplo, veamos una breve introducción de los tipos generales de tráfico en redes y como es usado por PROFINET.
Tipos de Trafico en Redes
Para poder entender mejor los test de las pruebas de carga, uno debe considerar primero que situaciones (erróneas) podrían causar que tipos de trafico de red.
Tráfico Indirecto
El tráfico de datos relacionado con tráfico indirecto no está, de hecho, destinado para el dispositivo bajo prueba. Esto puede involucrar al broadcast (para todos los participantes) al multicast (para algunos participantes) o tramas unicast. Los tramas broadcast y multicast en la red, están sumergidos en la capa Ethernet y están por tanto disponibles en cualquier momento en la red Ethernet.
¿Qué es lo que conduce sin embargo al tráfico no dirigido de tramas unicast? En general, esto sucede en el caso de un error. Normalmente, un switch Ethernet se dirige a una tabla de direcciones interna. Si el switch recibe una trama con una dirección MAC desconocida, el puerto en el cual fue recibida la trama es listada en la tabla de direcciones. Este “aprendizaje de direcciones” permite al switch enviar los tramas unicast directamente hacia el objetivo y no inundar estos como en el caso de mensajes broadcast a todos los puertos. Sin embargo, si la tabla de direcciones está llena, cualquier futuro aprendizaje de dirección pondrá al switch en un modo de fallo de seguridad: Las tramas, como en el caso del hub, se reenviarán a todos los puertos. Este comportamiento es explotado deliberadamente por los llamados “MAC flooding” (también conocidos como Switch jamming). El atacante pasa toneladas de tramas Ethernet con falsas direcciones hasta que la tabla del switch se llena. Un puerto Ethernet libre es suficiente para este propósito. El objetivo del atacante es generar sobrecarga intencionadamente o leer información por toda la red.
Tráfico Directo
El tráfico directo trata con datos de tráfico lo cual es pretendido por el dispositivo y no como en el caso del tráfico indirecto, en el que era reenviado por el dispositivo erróneamente. Estos datos pueden ser enviados por unicast, broadcast o multicast.
En este tráfico, el dato puede o bien venir de una conexión PROFINET o bien de otros servicios como un servidor HTTP ejecutándose en el dispositivo. Además, hay también datos de protocolos comunes usados como ARP. Estos datos pueden ser subdivididos tanto en Tiempo Real (RT) como en Tiempo No-Real (NRT). El trafico RT cubre cualquier cosa que sirva para mantener una conexión cíclica PROFINET. El trafico NRT incluye el dato desde el protocolo PROFINET en sí mismo como desde otras tramas Ethernet (e.g. IP traffic).
Una Cuestión de Arquitectura
El MCU de un dispositivo PROFINET debe por tanto tratar con un número relativamente alto de tramas. Esta carga aumenta a medida que aumenta el tamaño de una red proyectada. En particular, en la fase inicial de una red, pueden ocurrir frecuentemente que tramas como LLDP, ARP, etc. revienten.
Tanto el hardware como el software deben ser diseñados adecuadamente para asegurar una comunicación fiable incluso en estas situaciones. Para un ejemplo práctico, primero debe ser considerado qué secuencia de operaciones son necesarias para procesar una comunicación cíclica PROFINET.
La Figura 1 muestra un extracto de un diagrama de tiempos del Stack de PROFINET de port GmbH en un Renesas RX63N. El dato fue obtenido usando el framework de rastreo integrado en el Stack. Muestra cronológicamente los pasos del proceso principal para transmitir una trama RT.
En plataformas embebidas sin un sistema operativo, el stack usa una rutina de timer en la que todos los timers utilizados son monitorizados en intervalos de microsegundos con respecto a su vencimiento. En la Figura 1, el OAL_timer ilustra esto con una línea verde. Primero, se ejecuta el timer para el procesado del paquete cíclico. Esto se ilustra en la figura 1 por Cyclic con la línea amarilla. En Cyclic, la siguiente trama a ser transmitida se compila y se pasa al driver Ethernet. Cuando Cyclic ha finalizado, el resto de timers pueden ser procesados. En este caso, la siguiente trama LLDP a ser transmitido se procesa. El LLDP (Link Layer Discovery Protocol) es un protocolo Layer 2 que gestiona la detección del vecindario, y no es usado solo en PROFINET. La trama se genera en la línea marcada como LLDP y pasada a través del driver Ethernet. Un vez el timer ha completado su tarea, todavía se pueden identificar dos interrupciones de Ethernet. Eso implica una confirmación de que las dos tramas (cyclic y LLDP) han sido transmitidas. La lectura del “marker” en la esquina superior derecha de la figura 1 (resaltada por un rectángulo rojo) muestra que la acción completa se realiza en solo 119 μs. Si la conmutación de la interrupción también se hubiera tenido en cuenta, entonces el tiempo sería de alrededor de 125 μs. La interrupción del timer se dispara aproximadamente cada 1 ms. Con esto, el RX63N aún puede proporcionar mucho tiempo de computación fuera del proceso de comunicación con PROFINET para manipular los siguientes datos a ser enviados. Además, en este periodo, se pueden procesar otros servicios como TCP para un servidor HTTP.
Esto ha sido un ejemplo simple sin datos adicionales de tráfico. ¿Cómo hubiera actuado el sistema cuando se hubieran recibido datos adicionales?
Para este propósito, usando la herramienta “tcpreplay”, paquetes ARP pre-grabados son realimentados adicionalmente a la red lo más ágilmente posible. Esto es ilustrado en la Figura 2. Los paquetes ARP pueden ser reconocidos como una interrupción Ethernet frecuentemente disparada, (línea roja). No obstante, como puede verse en la figura, el tráfico adicional afecta severamente a la comunicación cíclica. ¿Cómo puede explicarse esto? Primero, para esa realización, se necesita un MCU que permita priorización e interrupción de interrupciones. Esta característica está correctamente implementada en el Renesas RX63. El procesamiento o generación de tramas cíclicas es la parte más importante del dispositivo, por lo tanto, a la interrupción del timer se le ha asignado la mayor prioridad. Por tanto se dispara incluso mientras el dispositivo es ocupado procesando un paquete en la rutina de la interrupción de la Ethernet y la interrumpe.
En Segundo lugar, una funcionalidad inteligente del RX63N, que puede aliviar en gran medida la carga de la CPU especialmente durante la densa carga de datos en la red Ethernet, juega un papel importante aquí. El RX63N está equipado con su propio controlador DMA (EDMAC) para el controlador Ethernet (ETHERC). Esto reserva a la CPU desde la tarea de copiar las tramas de Ethernet a ser enviados o recibidos. Por medio de los descriptores, la CPU apunta a la zona de memoria, en la que el paquete a transmitir se encuentra, o en la que el paquete recibido está para ser almacenado. La CPU puede entonces procesar los paquetes. Por lo tanto, es posible procesar un paquete mientras el EDMAC está ya recibiendo o transmitiendo otros paquetes.
Perspectivas
No hay duda que en futuras pruebas de carga será una parte de cada prueba de liberación sino incluso de cada certificación. Aquí, es importante no solo comprobar la comunicación, sino también simular las condiciones de error de la red.
En PROFINET, las pruebas de carga se convertirán en parte de la certificación en un futuro próximo. En pruebas de carga de red, al margen de los datos RT, también diferentes protocolos son alimentados adicionalmente en el tráfico de la red por unicast, broadcast, y también por multicast. De esta manera diferentes niveles de carga desde el tráfico regular de la red hasta la sobrecarga en la red son simulados. Esto se hace dependiendo de la clase de ejecución deseada (clase de carga de red).
Por otro lado, tanto los fabricantes de MCU como de stacks, deben hacer sus deberes también. Tanto el software como el hardware deben estar preparados para gestionar los posibles errores, como es el caso del RX63N.
¿Qué es necesario hacer para empezar?
Para un usuario sin experiencia, las secciones previas pueden sonar relativamente complicadas. Para dar los primeros pasos, es recomendable usar un RSK (Renesas Starter Kit) RX63N porque junto con el stack de PROFINET de port GmbH se ofrece una solución “Ready-To –Go” que ayuda a realizar de manera ágil y rápida el desarrollo de prototipos. El debugger E1 JTAG de Renesas y el entorno de desarrollo e2Studio están disponibles como herramientas de desarrollo. El entorno de desarrollo e2Studio integra todas las herramientas necesarias para escribir y debugar el software. La aplicación demo incluye todos los archivos necesarios para el proyecto para por tanto, contribuir a una suave puesta en marcha del kit de iniciación.
El RSK incorpora un MCU RX63N con 2 Mbytes on-chip Flash y 128 Kbytes on-chip RAM. Este grupo de productos con 165 DMIPS y 100 MHz de CPU y operativa de flash consigue un alto rendimiento de computación. Para poder usarlo en una amplia variedad de productos con diferentes perfiles y requisitos, este grupo de productos cuenta con una amplia escalabilidad. Los RX63N están disponibles en versiones de memoria flash que van desde los 512 Kbytes hasta 2 Mbytes y tamaños de RAM que van de los 128 Kbytes a 256 Kbytes. Con respecto a los encapsulados, hay versiones en diferentes variantes: LQFP, LGA y BGA. Además de la interfaz compatible Ethernet MAC IEEE 802.3 con Media Independent Interface (MII) y Reduced Media Independent Interface (RMII) para conexión simple con una PHY, estos componentes ofrecen interfaces Controller Area Network (CAN) 2.0B con hasta tres canales (aquí, una solución CANopen de port GmbH está también disponible), dos Universal Serial Bus (USB) full speed hosts, USB OTG y funciones device. Los RX están concebidos para proporcionar una alta densidad de integración y un atractivo coste de estructura, combinado con la extremadamente rápida tecnología Flash integrada. Por tanto, son la elección adecuada para aplicaciones que necesitan potentes stacks de comunicaciones como en el área de PROFINET con soluciones mono chip para evitar el uso de memorias externas. Información detallada sobre este tema se puede descargar desde Internet y está por supuesto incluida con el starter kit.
Una Buena combinación
Bajo el programa RXMAX de Renesas, la combinación del MCU de 32-Bit Renesas RX63N y el stack de PROFINET de port, ofrece un particularmente atractivo inicio en el campo de las aplicaciones con PROFINET. El MCU RX63N de Renesas puede trabajar con el PROFINET de port sin restricciones, habilitando el desarrollo de potentes y rentables dispositivos PROFINET I/O (CC-A, RT-1).
La ventaja del coste puede extenderse a través de la estructura simplificada de la red hasta los integradores y sus clientes.
En principio, soluciones como CANopen, EtherNet/IP, POWERLINK y EtherCAT son posibles bajo la misma plataforma.
