los drivers son accesibles por programas que se ejecuten en el mismo anillo de privilegio o en uno superior; pero un programa que se ejecute en un ...

los drivers son accesibles por programas que se ejecuten en el mismo anillo de privilegio o en uno superior; pero un programa que se ejecute en un anillo de privilegio inferior no podrá acceder a los recursos habilitados por un driver ubicado en un nivel superior. Esta caracterı́stica de Windows® hace que sea posible ejecutar un programa en el anillo de privilegio 0, denominado Kernel, pudiéndose acceder al Timer del sistema y reprogramarse la frecuencia de las interrupciones temporales, ası́ como ejecutar un programa cada vez que acontezca una interrupción temporal. Esta in- terrupción temporal permite ejecutar un programa bajo el paradigma de Tiempo- Real siempre que el código esté basado solamente en tiempo-discreto. Esta propie- dad es explotada por la toolbox de MATLAB/SIMULINK® Real-Time Windows Target®, permitiendo ejecución monotarea soportando distintos tiempos de mues- treo con planificador temporal incluı́do. Resulta necesario que el programa a eje- cutar en modo Kernel termine su ejecución antes de la llegada de la próxima inte- rrupción temporal, para dejar tiempo a Windows® de administrarse, en caso con- trario el sistema se colgará, con el único sı́ntoma de que la pantalla se queda con- gelada. Dependiendo de la complejidad del programa a ejecutar en Tiempo-Real, será más o menos fácil bloquear completamente el sistema, programas que tengan que realizar grandes análisis de datos no son aconsejables, pues es difı́cil que sean puramente deterministas. En el modo Kernel se pierden las capacidades de I/O otorgadas por los drivers de los dispositivos. Tan sólo drivers para hardware de I/O muy especializados otorgan soporte para el modo Kernel. De forma general se puede acceder al puerto serie RS-232 si la placa base del ordenador posee alguno, pues su uso está norma- lizado, y se accede a través del BIOS (”Basic Input Output”). También es posible utilizar el puerto paralelo. Como ventajas de este modo de funcionamiento se encuentra el poder ejecutar un programa bajo el paradigma de Tiempo-Real en Windows®. Como desventa- jas se presenta la imposibilidad de realizar multitarea en Tiempo-Real, tampoco se puede implementar código orientado a su ejecución en tiempo-continuo y se pierde la práctica totalidad de las capacidades de I/O salvo el puerto RS-232 real y el puerto paralelo. También son desventajas la facilidad de bloquear el sistema al operar únicamente en este modo de funcionamiento y el tener que compartir el modo Kernel con los drivers de vı́deo y audio, lo que impedirá establecer un de- terminismo absoluto en la ejecución del programa de control. Existen sistemas RCP utilizados en centros de investigación y educativos que hacen uso del modo Kernel y de la toolbox Real-Time Windows Target® para la eje- cución en Tiempo-Real monotarea de programas de control diseñados en SIMULINK® [50, 51, 52, 53], que utilizan el ordenador para ejecutar el programa de control y se comunican mediante RS-232 con un microcontrolador que hace las funciones de tarjeta de adquisición de datos. Se trata de una metodologı́a de trabajo bastante difundida en centros de investigación, puesto que disponer de un sistema RCP co- mercial resulta por lo general demasiado caro de adquirir y mantener; pero el dis- poner de un ordenador con puerto RS-232 y programar un microcontrolador para adquirir datos con sus periféricos y enviar estos por RS-232 es mucho más barato. Se pueden crear drivers personalizados para dispositivos de I/O, estos drivers no deben hacerse siguiendo las normas de Windows®, sino que son más parecidos a cómo se hacı́an los drivers para el sistema operativo MS-DOS®. En esta sección se ha descrito una metodologı́a de trabajo en Tiempo-Real ba- sada en el modo Kernel de Windows® y como es explotada por la toolbox de MATLAB/SIMULINK® Real-Time Windows Target®. Este principio de funciona- miento es el empleado por el denominado modo externo de SIMULINK®. Además de los inconvenientes ya descritos, se localizan otros derivados de las limitaciones de algunas toolboxes de SIMULINK® de poder operar en modo externo, los vi- sualizadores gráficos de SIMMECHANICS®, y las toolboxes SIMRF® para mode- lado de sistemas eléctricos y SIMHIDRAULICS® entre otras, no funcionan cuando SIMULINK® se comunica con un programa que se ejecuta en modo externo, por lo que se limitan las capacidades de modelado y simulación al utilizar esta metodo- logı́a. 2.5. Sistemas RCP con origen no comercial 77 2.5.4. Modelica® Modelica® es un lenguaje formal basado en ecuaciones para describir sistemas mecánicos, eléctricos, neumáticos... mecatrónicos en general. Aparte de ser un len- guaje textual, la versión actual de Modelica®, versión 3.3, incluye un entorno de simulación y modelado basado en la utilización de lenguajes gráficos, al estilo de SIMULINK®. Modelica® está desarrollado al amparo de una organización sin ánimo de lucro denominada Modelica Association. Fundada en 1996 cuenta con miembros y en- tidades procedentes de Europa, Estados Unidos, Canadá y Asia. Además del uso gratuito, existen versiones comerciales de Modelica® contenidas en MapleSIM®, Wolfram Modeler®, Dymola® que incluyen soporte adicional al gratuito. Respecto al uso de Modelica® y su entorno de modelado basado en gráficos co- mo base para un sistema RCP es posible, pues Modelica® incluye la funcionalidad de convertir a código en lenguaje C los modelos basados en gráficos. La metodo- logı́a de trabajo con Modelica se muestra en la figura 2.28. Figura 2.28: Convirtiendo un modelo gráfico en Modelica® a código fuente en lenguaje C. Fuente: Presentación ”Modelica Overview”, www.modelica.org. La generación automática del código en lenguaje C da lugar a una función que recrea el comportamiento del modelo descrito, pero sin ofrecer respaldo a tiem- pos de muestreo ni planificadores temporales. Esta circunstancia cambia al utilizar 78 Capı́tulo 2. Estado del Arte la librerı́a gratuita ”Embedded Systems”, con origen en el Centro de Robótica y Mecatrónica del DLR37. Utilizando el entorno gráfico de Modelica® y la librerı́a Embedded Systems el DLR diseña los controladores para sus robots. La figura 2.29 ilustra el concepto de la librerı́a Embedded Systems para Modelica®; los bloques gráficos que permiten utilizar los recursos I/O del controlador necesitan ser recon- figurados para adecuarse al hardware que quieras utilizar, ası́ como reescribir todo el código C que genera cada bloque. Figura 2.29: Concepto de la librerı́a para sistema embebidos. Fuente: Presentación ”Modelica Em- bedded Library”, German Aerospace Center (DLR) Una grata particularidad de este sistema de Prototipado Rápido para Control es que permite generar el código fuente en lenguaje C no sólo para un controlador, sino para múltiples controladores al mismo tiempo, e incluso estos controladores pueden ser diferentes entre sı́, siempre que se cuente con una versión personali- zada y reconfigurada de la librerı́a Embedded Systems para cada hardware obje- tivo. Modelica® y Embedded Systems Library conforman la base software de un sistema RCP que permite administrar distintas tareas bajo un sistema operativo en Tiempo-Real, crearlas y detenerlas; son caracterı́sticas propias de sistemas RCP avanzados. La configuración de los periféricos de I/O se realiza mediante paneles de configuración, la figura 2.31 muestra un ejemplo de estos paneles. 37http://www.dlr.de/rmc/rm/en/desktopdefault.aspx/tabid-8016/ , Julio 2014 2.5. Sistemas RCP con origen no comercial 79 Figura 2.30: Esquema de control para el brazo robótico LWR. Fuente: Presentación ”Modelica Embedded Library”, DLR Figura 2.31: Configuración de las opciones de I/O hardware en el entorno gráfico de Modelica®. Fuente: Presentación ”Modelica Embedded Library”, DLR 80 Capı́tulo 2. Estado del Arte 2.5.5. Signal Signal es un lenguaje de programación basado en gráficos que admite múlti- ples tiempos de muestreo para cada una de las partes del algoritmo que se diseñe. Aunque también es un lenguaje textual, inicialmente se concibió para utilizarse de forma gráfica, por los beneficios que el diseño basado en modelos implica. En este sentido es idéntico a MATLAB/SIMULINK®. Se comenzó a diseñar en la década de 1980 en paralelo a los lenguajes Esterel y Lustre. Se diseñó intencionadamente