Determinismo obsesivo compulsivo

Este medio en el que escribo es eminentemente técnico y todos sabrán a lo que me refiero con el término Determinismo (o si se prefiere “Real Time” para aclarar mejor. Se me deberá perdonar el uso de anglicismos, pidiendo disculpas por anticipado, pero el texto se alargaría notablemente.)

Con el devenir del llamado IoT y como pasa con la Eficiencia Energética, el Determinismo es otro aspecto de los requisitos de los sistemas y procesos integrados (o ”embedded”) que crece considerablemente en los nuevos diseños.  Además, debido también a la tasa de innovación del IoT, las Herramientas de Desarrollo necesitan tener la capacidad de evolucionar rápidamente y ofrecer soluciones apropiadas para todos los tipos de desarrolladores.

Según parece (y no soy experto), aunque la velocidad de evolución de las nuevas tecnologías de proceso se esté ralentizando y los costos de desarrollo vayan aumentando, aun queda sitio para la “Ley de Moore” que vaticina que en el 2022 se alcanzarán los 5 nm por transistor en las obleas y, tanto es así, que ya se trabaja con los Qubits en los ordenadores cuánticos. Pero cabe añadir, no obstante, que queda mucho por hacer hasta aprovechar al máximo lo que esa tecnología a nivel de hardware (H/W) nos ofrece ya actualmente.

Hace una década que en una oblea tenemos a nuestro alcance el “multi-core” (con perdón) para mejorar el “multi-threading” (más perdón si cabe) en una evolución imparable desde el aspecto hardware como se ha comentado. Pero en Determinismo, y aunque cueste algún disgusto para los “gurus” del S/W, se debe decir que, pese a que su uso se está extendiendo vertiginosamente (ver todo lo relacionado con circuitos de control deterministas o con los sistemas que requieren una computación en tiempo real hasta el nivel de pocos microsegundos, y pese al esfuerzo del fabricante de chips para satisfacer las necesidades específicas de aplicaciones en segmentos claves como son el de la automoción, el de la industria y el video) hay que decir que, decía yo, que si bien el hardware ya está ahí, la mayoría de los dispositivos que usan este hardware, y hablando apropiadamente sería el de los desarrolladores de esos dispositivos, los que somos los que no aprovechamos las características y prestaciones que incorpora el hardware. Y, a este fatídico hecho se debe hacer especial hincapié al referirse a los Sistemas Operativos (OS) más populares que se quedan mucho más que cortos cuando se requiere de un Determinismo Puro… y Duro (o del tal aclamado “Hard Real Time”).

Cuando una Tableta de 8” con una buena batería de litio, Windows 10, 2 Gb de RAM, 32Gb de SSD, 64Gb en un SD y con una fuente externa diminuta, cuesta en “retail” poco más de 100€, ¿a quien no le entran ganas de dar salida a su ingenio haciendo uso de esta verdadera revolución?…

¡Pues no! Si bien estamos a un paso de alcanzarlo (el H/W ya nos lo ofrece clarísimamente) con todo lo apuntado en el párrafo anterior, nos quedamos a las puertas y debemos pasar por nóminas para poner “parches” o pagar por más H/W innecesario, estrictamente hablando, para que nos proporcione el grado de determinismo deseado en aplicaciones industriales como es la de un CNC (acrónimo de Control Numérico Computarizado) que es, en particular, el caso del que os escribe.

Añadir entonces que a duras penas, de toda esa super-potencia que está al alcance de todos a día de hoy, en los sistemas embedded que requerimos “Hard Real Time” solo necesitaríamos…  primeramente, de UNA SOLA Y TRISTE “thread” del “multi-threading” que tenga la prioridad máxima de ejecución “preemptitiva”, es decir: “preferente, pero que el proceso interrumpido vuelva a ejecutarse una vez acabe esta” (y, si fuera necesario, incluso se podría prescindir de ejecutarla en un “core” aparte). Esta “prioridad total y  preemtitiva” es del todo vital, contando con la posible latencia producida al “saltar de una trama a la otra más prioritaria” y de sus posibles variaciones (productora de Jitter) según que se le esté solicitando que haga el sistema (evidentemente es diferente guardar el estado cuando el procesador, en tiempo real, está realizando un cálculo para un movimiento rectilíneo, circular o helicoidal).

Y la segunda y última cosa que pediríamos a nuestro OS (que con el punto 1 ya sería RTOS) es que pueda utilizar en la “thread determinista” el H/W existente, es decir, utilizar el canal de Ethernet (EtherCAT por ejemplo) en Tiempo Real sin necesidad de “meter un driver con pinzas” como otro parche adicional. Mejor aun si se pudiera usar un USB type-C (con un “USB-Ethernet adapter”) por emplear la tecnología presente o, ya puestos, directamente pasar a una WLAN como Wi-Fi.

Lo que se ha expuesto es un ejemplo paradigmático, como otro cualquiera, que sirve para expresar la gran frustración de los desarrolladores que quisiéramos depender de otros desarrolladores expertos cada uno en su materia.

Dejarme acabar con un llamamiento o “llamado” o “call for papers” para todos aquellos que desearíais participar ACTIVAMENTE en el desarrollo y construcción de un proyecto que se introduce mejor en el vídeo https://youtu.be/Ea5DHyexcUQ (trata sobre el referido CNC al que se hace continua mención a lo largo de este documento).

Por favor, solo aquellos desarrolladores que estéis interesados poneros en contacto a través de inav@inavcnc.com para recibir inmediatamente un escrito explicativo donde, además, podréis aplicar.

Albert Sàenz Coromina 

Ingeniero de telecomunicación (CCET n. 275)