SISTEMA PARA DISEÑO, SIMULACIÓN E …configuración de los sistemas operativos que los ejecutan, estas tareas no tienen por qué suponer una alta prioridad para el sistema, por lo

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO INDUSTRIAL

SISTEMA PARA DISEÑO, SIMULACIÓN E IMPLANTACIÓN DE SISTEMAS DE

CONTROL BASADO EN SCILAB Y SCICOS

Autor: Fernando Alonso Real Director: Dr. José Daniel Muñoz Frías

Madrid Julio 2014

1

AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO

ABIERTO ( RESTRINGIDO) DE DOCUMENTACIÓN

1º. Declaración de la autoría y acreditación de la misma.

El autor D. Fernando Alonso Real , como alumno de la UNIVERSIDAD PONTIFICIA COMILLAS

(COMILLAS), DECLARA

que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en

relación con la obra “Sistema para diseño, simulación e implantación de sistemas de control

basado en Scilab y Scicos ” (Proyecto Fin de Carrera), que ésta es una obra original, y que

ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como

titular único o cotitular de la obra.

En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el

consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa

cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna

autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la

facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita.

2º. Objeto y fines de la cesión.

Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la

Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que

más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor

CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo

legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de

distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica,

tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se

cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente.

3º. Condiciones de la cesión.

Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de

derechos contemplada en esta licencia, el repositorio institucional podrá:

(a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet;

realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así

como incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua”

o cualquier otro sistema de seguridad o de protección.

(b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica,

incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de

garantizar su seguridad, conservación y preservar el formato. .

2

(c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional,

accesible de modo libre y gratuito a través de internet.

(d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital.

4º. Derechos del autor.

El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad

por medio de su registro en el Repositorio Institucional tiene derecho a:

a) A que la Universidad identifique claramente su nombre como el autor o propietario de los

derechos del documento.

b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través

de cualquier medio.

c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse

en contacto con el vicerrector/a de investigación ([email protected]).

d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para

la obtención del ISBN.

d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras

personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de

propiedad intelectual sobre ella.

5º. Deberes del autor.

El autor se compromete a:

a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún

derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro.

b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la

intimidad y a la imagen de terceros.

c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que

pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e

intereses a causa de la cesión.

d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por

infracción de derechos derivada de las obras objeto de la cesión.

3

6º. Fines y funcionamiento del Repositorio Institucional.

La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y

respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con

fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad

asume los siguientes deberes y se reserva las siguientes facultades:

a) Deberes del repositorio Institucional:

- La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza

ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior

de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia

privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio

comercial, y que no se realicen obras derivadas.

- La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la

responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre

del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del

depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la

Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso

de las obras.

- La Universidad adoptará las medidas necesarias para la preservación de la obra en un

futuro.

b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas:

- retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en

caso de reclamaciones de terceros.

Madrid, a 22 de Julio de 2014

ACEPTA

Fdo……………………………………………………………

Proyecto realizado por el alumno:

Fernando Alonso Real

Fdo.: ……………………………… Fecha 22 / 07 / 2014

Autoriza la entrega del proyecto cuya información no es de carácter confidencial

EL DIRECTOR DEL PROYECTO

Dr. José Daniel Muñoz Frías

Fdo.: ……………………………… Fecha 22 / 07 / 2014

VºBº del Coordinador de Proyectos

Dr. Álvaro Sánchez Miralles

Fdo.: ……………………………… Fecha 22 / 07 / 2014

1

SISTEMA PARA DISEÑO, SIMULACIÓN E IMPLANTACIÓN DE SISTEMAS DE CONTROL BASADO EN SCILAB Y SCICOS.

Autor: Alonso Real, Fernando.

Director: Muñoz Frías, José Daniel.

Entidad Colaboradora: ICAI – Universidad Pontificia Comillas.

RESUMEN DEL PROYECTO

1. Introducción

a. Planteamiento del problema

Hoy en día, existen diversas opciones que permiten conocer el comportamiento de una planta que se desee controlar; así como desarrollar diferentes tipos de controles digitales para hacerlo. Según sea la naturaleza de dicha planta, se pueden requerir especificaciones de rapidez, robustez a errores y perturbaciones, frecuencias de muestreo, etc. Es por ello que se considera de especial relevancia introducir avances y soluciones a dichos requerimientos.

En la búsqueda de dichas soluciones, la solución abordada en el presente proyecto permitirá controlar en tiempo real un control de velocidad de un motor mediante la búsqueda de controladores de cualquier tipo, a pesar de responder a complejas leyes físicas (no siempre modelables).

Actualmente, existen sistemas muy robustos [4] y de gran eficiencia que permiten operar con periodos de muestreo muy reducidos, sin embargo dada la naturaleza de configuración de los sistemas operativos que los ejecutan, estas tareas no tienen por qué suponer una alta prioridad para el sistema, por lo que muestrear a una muy alta frecuencia podría no ser posible. Por ello una de las bases de este desarrollo de controles en tiempo real, será modificar el comportamiento y prioridades de las tareas del sistema para poder operar en tiempo real.

b. Estado del arte

A día de hoy son múltiples los softwares existentes para la realización de simulaciones de sistemas autónomos. Uno de los más importantes es Simulink. La contrapartida de este software es que no se trata de un software gratuito, sino que el usuario debe adquirir licencias de uso. Además, dado que es propiedad industrial de una marca, estará limitado por las actualizaciones que el mismo fabricante haga de su producto.

La solución a este último punto es el natural paso a programas de software libre, donde el sistema se encuentra en continua evolución por parte de los usuarios/desarrolladores que buscan encontrar soluciones a los problemas que plantean sistemas de automatización cada vez más complejos.

2

Cabe destacar la existencia de software basado en sistemas operativos en tiempo real o RTOS. En ellos, mediante diversas herramientas de software se consigue configurar un ordenador convencional para trabajar de manera determinista, siendo éste capaz de atender a las rutinas y tareas críticas definidas por el usuario. Y es aquí donde la apuesta por el software libre lleva ventaja sobre la que no; porque pese a que existen versiones para otros sistemas operativos que permiten las mismas funcionalidades como WindowsCE o VxWorks, entre otros, la robustez de los SO FreeSource es muy elevada.

RTAI (Real Time Application Interface) [1] es uno de estos SO FreeSource, que es capaz de dotar a Linux de funcionalidades en tiempo real, lo cual sumado a las posibilidades de control que ofrecen programas como Scilab, hizo que comenzaran a desarrollarse herramientas de control en tiempo real como RTAI-Lab.

RTAI-Lab puede considerarse un conjunto de programas y herramientas de software que hacen posible implementar sistemas de control en tiempo real haciendo uso de diferentes funcionalidades como diagramas de bloques de control, modificación de parámetros de control o hasta monitorización en tiempo real.

Con todo lo anterior, empiezan a plantearse ideas como la de desarrollar controladores bajo plantas reales, y es de ahí, de donde surge el Hardware in the Loop.

La simulación hardware-in-the-loop (HIL) [13] es una técnica usada para el desarrollo y comprobación de sistemas empotrados en tiempo real complejos. La simulación HIL constituye una plataforma efectiva porque incluye toda la complejidad de la planta que controla el sistema empotrado. Esto lo realiza mediante modelos matemáticos de todos los sistemas dinámicos relacionados con la planta bajo control, formando lo que se denomina como "simulación de la planta". En muchos casos, la forma más efectiva de desarrollar sistemas empotrados es conectar el sistema empotrado a la planta real. En otras palabras, conectar una centralita de motor (sistema empotrado) a un motor real (planta real).

c. Objeto del proyecto

Brevemente se van a exponer los problemas a los cuales dará solución este proyecto:

� Los sistemas de software de control comerciales son programas de pago

� Es complicado encontrar soluciones rentables para desarrollar controladores en

tiempo real.

En el punto actual, tras haber visto las posibilidades y sus principales inconvenientes se procederá a enumerar los puntos a favor del presente proyecto [10-12]:

� Se ha desarrollado un paquete de software libre que será capaz de hacer el mismo

control de una planta (control de velocidad de un motor) que podría hacer su dual

de pago Matlab/Simulink en los laboratorios de control de I.C.A.I.

� Dicho software (tanto su RTOS como RTAI-Lab) es posible instalarse en

cualquier ordenador; así como proporciona la opción al usuario de ejecutarse

desde un CD-Boot.

3

� En RTOS, la prioridad máxima de interrupción está definida para tareas en tiempo

real, con lo que se garantiza optimizar la capacidad del sistema para atender a las

tareas en tiempo real.

� Con Comedi, es posible hacer uso de DAQ propias, ya que el usuario solo tiene

que compilar correctamente el código del driver en C y cargar el modulo en el

sistema, para que pueda ser reconocido como un driver comercial más.

2. Metodología

Con objeto de dar solución a los objetivos anteriormente citados, se lleva a cabo la siguiente metodología, desarrollada en apartados.

� Recopilación de información y software.

� Configuración del PC para trabajar con RTAI

� Instalación de los Comedi-drivers [2]

� Simulaciones en Scicos y Simulink [5-9]

� Ensayos en Scicos y Simulink

� Creación del CD-Boot final estable

3. Resultados

A la finalización del proyecto se han obtenido los siguientes resultados:

� Se creó un CD-boot de arranque con el SO Knoppix-RTAI [14-16] con la última versión de Comedi, capaz de ser instalado en cualquier PC con una partición de disco reducida (unos 800mB).

� Se comprobó la validez de usar Scicos para realizar simulaciones, que previamente habían sido realizadas con Simulink.

� Se elaboraron los bloques de control para los ensayos con la planta, a expensas de encontrar una solución para el error en la configuración de la DAQ-PCI6013

� Se elaboró una extensa lista de posibles errores y soluciones para futuros desarrollos e implementación de nuevas versiones de RTAI

4. Conclusiones

A la vista de los resultados obtenidos, la conclusión es la siguiente: A día de hoy, no ha

sido posible implementar con éxito un sistema en tiempo real para el control de una planta

haciendo uso del software propuesto.

El motivo de fallo, es el error surgido a la hora de configurar la tarjeta de adquisición de

datos PCI6013 con los drivers provistos por Comedi.

4

Es por tanto que en la búsqueda de soluciones a dicho error se pudieron obtener las

siguientes conclusiones del estado de la situación de desarrollos en tiempo real:

� Actualmente, RTAI dispone de dos versiones operativas, la versión 3.8 y la 4.0.

La versión 4.0 fue la que se trató de implementar en un primer momento pero no

resultó con éxito, ya que como el propio desarrollador informa aún está en periodo

de depuración, búsqueda y corrección de bugs. Descartada la opción de instalar la

versión 4.0, se procedió a instalar la 3.8 con alguna de las versiones de Linux que

eran parcheables.

� La versión 3.8 de RTAI, al haber sido desarrollada en el año 2006, requiere de

versiones de Linux un tanto obsoletas como son las 2.6.xx y hay serias dificultades

a la hora de encontrar librerías y compiladores que permitan implementar la

versión modificada del Kernel con el parche de RTAI. Así que se puede concluir,

que la versión 3.8 no resulta fácilmente implementable a día de hoy debido a que

las librerías están desactualizadas.

� Descartadas las dos últimas versiones de RTAI, se inició la búsqueda de

soluciones al problema. Finalmente, se optó por implementar la solución

propuesta en foros de Comedi de hacer uso de un CD-Boot con un RTAI versión

3.5 ya configurado en el arranque. Ésta, fue la única forma viable de tener el

sistema en tiempo real configurado en el PC.

� Una vez se consigue tener el sistema con un RTAI válido, y se pasan con éxito los

test que el propio RTAI provee para su verificación, se instaló el Comedi más

actualizado en el sistema. Ya que la DAQ PCI6013 no estaba recogida en los

drivers de la versión Knopix-RTAI. Tras instalar con éxito y cargar los

correspondientes módulos (también con éxito) se procede a configurar la tarjeta

PCI6013, siguiendo los pasos del propio desarrollador, y es ahí donde ocurre el

error que impide configurarla correctamente pese a que la detección de la tarjeta,

sí se realiza con éxito.

� Con Scicos, la implementación ha sido total y no han surgido problemas a la hora

de disponer de cualquier diagrama de bloques, que permitiese modelar el sistema

al igual que se podría hacer con otro software (Simulink en este caso)

5

5. Referencias

[1] RTAI. https://www.rtai.org/

[2] Comedi, Linux control an measurement device interface. www.comedi.org

[3] LinuxCNC. http://wiki.linuxcnc.org/cgi-bin/wiki.pl?emcknowledgebase

[4] Greg Gagne Abraham Silberschatz, Peter Baer Galvin. Fundamentos de

sistemas operativos. McGraw Hill

[5] Stephen L. Campbell, Jean-Philippe Chancelier, Ramine Nikoukhah.

Modeling and Simulation in Scilab/Scicos with ScicosLab 4.4. Springer

[6] M.G.J.M. Maassen , Scicos as an alternative for Simulink

[7] Roberto Bucher and Simone Mannori, Using Scilab/Scicos with RTAI LAB

[8] Roberto Bucher, Interfacing Linux RTAI with Scilab/Scicos

[9] Bucher,R., L.Dozio y P. Mantegazza (2004). Rapid control prototyping

with Scilab/Scicos an Linux RTAI

[10] Florez, J., Y.F., Cabezas y E. Diaz (2008). Simulacion y control PI de una

planta RC en Tiempo Real con RTAI-Lab. $to IEEE Workshop Colombiano en

Robotica y Automatizacion – CWRA 2008

[11] Schleef, D., F. Hess y H. Bruyninckx (2007). Comedi: The control and

Measurement Device Interface handbook. Article of divulgation.

[12] Pedro Henrique Santana, Glauco Garcia Scandaroli, Felipe Brandäo

Cavalcanti, Geovany Araújo Borges. How to install an RTAI extensión in Linux

2.6.24 Kernel

[13] Hardware in the Loop http://es.wikipedia.org/wiki/Hardware-in-the-loop

[14] Knoppix-RTAI http://www.barbalace.it/rtai3.3/

[15] http://tiemporeal.alumnos.exa.unicen.edu.ar/home/links-2

[16] CD-Boot http://www-lar.deis.unibo.it/people/gpalli/files/rtai_knoppix.iso

[17] Nahim Kheir. System Modeling and computer Simulation . 2nd edition

6

SYSTEM FOR THE DESIGN, SIMULATION AND COMPILATION OF CONTROL SYSTEMS BASED IN SCILAB AND SCICOS

1. Introduction a. Proposal

Nowadays, there are multiple options to understand the behavior of a plant to be controlled. There are also different types of digital controls to do it. Depending on the type of plant, it will require speed specifications, hardiness to errors and changes, sampling, etc. For that reason, it is particularly important to develop and introduce solutions to these requirements. On the search of these solutions, in this project it has been studied one that allows real-time speed control of a motor, also develop controllers of any type, although the plant responds to complex physical laws (not always can be modeled). Currently, there are very robust [4] and highly efficient systems that can operate with very short periods of sampling. However, the nature and configuration of the operative systems could not assign highest priority to sampling tasks. For that reason, it could be impossible to sample at high frequency. Taking this into account, one of the main goals of the project is the change of the behavior and priorities of the system to avoid work on real time.

b. State of art

Today, there is a lot of software to perform simulations of autonomous systems. One of the more important is Simulink. The disadvantage of this software is that it is not free. In addition to this, the software package is an industrial property, and the program will be restricted to the updates of the product. The solution of this problem is the natural change to FreeSource programs, where the system is evolving from users / developers looking for solutions.

However, there are some software based on real time systems or RTOS. On this real time systems if you use various software tools, it can work with a setting up as a deterministic computer, being able to attend critical tasks routines. At this point the FreeSource software takes advantage from the other software. Although there are versions for other operating systems with the same functionality as WindowsCE or VxWorks, the efficiency of the FreeSource SO is very high.

RTAI (Real Time Application Interface) [1] is one of these SO FreeSource, which is able to provide Linux a real-time functionality, also the control options that offer programs like Scilab, which is able to develop tools of control in real time area like RTAI-Lab.

RTAI-Lab can be considered as a set of programs and software tools which make possible implementing control systems in real time using different features such as the block diagrams, the modification of control parameters or even real-time monitoring signals.

7

With this, you can start to consider ideas like developing real plant controls. This is where Hardware in the Loop is used.

Hardware-in-the-loop (HIL) simulation, [13] is a technique which is used in the development and test of complex real-time embedded systems. HIL simulation provides an effective platform for controlling real plants by adding the complexity of the plant to the test platform. The difficulties of the plant are included in the test and the development by adding a mathematical representation of all related dynamic systems. These mathematical representations are referred as the “plant simulation”.

c. Goal project

Briefly it will be exposed the questions that this project will solve:

� Control software systems are payment programs. � It is difficult to find effective solution to develop controls in real time.

After studying the possibilities and the disadvantages of many software, it will proceed to list the interesting points to develop this project [10-12]:

� A free source software has been compiled to make the plant control (speed motor control) on the ICAI’s labs, like his dual MAtlab/Simulink could do.

� This software could be installed on any computer and also can be run as a CD-Boot without installation.

� In RTOS, the highest priority interruption is defined for real-time tasks, so it guarantees to optimize system capacity for real-time tasks.

� With Comedi, it is possible to use DAQ because the user just only needs to compile the driver in C code and load the module in the system.

2. Methodology

To develop the project’s goals, the next methodology will be carried out:

� Compile information and software.

� Configure the PC for work whit RTAI.

� Installation of Comedi-drivers [2]

� Simulations on Scicos and Simulink [5-9]

� Tests on Scicos and Simulink

� Create a final CD-Boot

3. Results

At the end of the project, the next results has been obtained:

� A start CD-Boot with Knoppix-RTAI OS [14-16] has been created with the last Comedi version, and it is able to be installed at any PC with a reduced partition (over 800mB).

8

� It was checked the validity on the use of Scicos to make simulations like in Simulink.

� The control blocks were compiled to make the tests on the plant. This point is hold-on waiting a solution for the DAQ-PCI6013 configuration error.

� A long list of compiling errors and solution for RTAI was written for future developments.

4. Conclusions

To sum up, the satisfactory implementation has not been possible to control a plant on

real time with the software packages of RTAI-Lab. The error was on the DAQ-PCI6013

configuration with the supplied drivers of Comedi.

On the search of solutions to this error, the real conclusions about the current situation of

the project could be described as:

� Currently, RTAI has two working versions, 3.8 and 4.0 versions. The 4.0 was the

first option to compile, but unsuccessful, because the developer of RTAI informs

that it is on develop period and they are looking for bugs and errors. At this point,

the solution was to install the 3.8 version with some valid patch of Linux.

� 3.8 version was created on 2006, and it requires old Linux versions like 2.6.XX

and it is very difficult to find some of the necessary libraries to compile

successfully the Kernel with RTAI’s patch. In conclusion, it is very hard to

compile the 3.8 version because a lot of libraries are out dated.

� After these problems, on the search of solutions, the best one was to download a

user’s CD-Boot with OS Knoppix-RTAI 3.5 provided on Comedi forum. This was

the only effective solution to have a real time operative system.

� With a real time operative system, it is necessary to load the last Comedi version

and his drivers. But before that, it is important to check the RTAI’s test to verify

the PC was working on real time.

On the provided Knoppix-RTAI was not loading the PCI6013’s driver, so it must

necessary to download and compile the last Comedi version. But on this point,

following the developer instructions it appeared an error with the configuration

test of the target.

� With Scicos, everything was correct and there was no problems with make control

diagrams to simulate the plant or the different control.

9

5. Referencies




[4] Greg Gagne Abraham Silberschatz, Peter Baer Galvin. Fundamentos de

sistemas operativos. McGraw Hill

[5] Stephen L. Campbell, Jean-Philippe Chancelier, Ramine Nikoukhah.

Modeling and Simulation in Scilab/Scicos with ScicosLab 4.4. Springer




[9] Bucher,R., L.Dozio y P. Mantegazza (2004). Rapid control prototyping

with Scilab/Scicos an Linux RTAI

[10] Florez, J., Y.F., Cabezas y E. Diaz (2008). Simulacion y control PI de una

planta RC en Tiempo Real con RTAI-Lab. $to IEEE Workshop Colombiano en

Robotica y Automatizacion – CWRA 2008



[12] Pedro Henrique Santana, Glauco Garcia Scandaroli, Felipe Brandäo

Cavalcanti, Geovany Araújo Borges. How to install an RTAI extensión in Linux

2.6.24 Kernel






ÍNDICE DE LA MEMORIA

I

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)


Índice de la memoria

Parte I Memoria .......................................................................................... 5

Capítulo 1 Introducción ................................................................................... 7

1.1 Estudio de los trabajos existentes / tecnologías existentes ........................... 7

1.2 Motivación del proyecto ................................................................................ 16

1.3 Objetivos......................................................................................................... 19

1.4 Metodología .................................................................................................... 19

1.5 Recursos / herramientas empleadas ............................................................. 20

Capítulo 2 Fundamentos del kernel y linux .................................................. 21

2.1 Introducción ................................................................................................... 21

2.2 Definiciones .................................................................................................... 22

2.3 Funcionamiento ............................................................................................. 23

2.4 Implantación en sistemas en tiempo real ..................................................... 24

2.5 Carga de módulos .......................................................................................... 26

Capítulo 3 Software Scicos/Scilab .................................................................. 31

3.1 Introducción ................................................................................................... 31

3.2 Módulos y Drivers de Comedi ...................................................................... 33

Capítulo 4 Fundamentos teóricos de la planta .............................................. 35

4.1 Introducción ................................................................................................... 35

4.2 Leyes físicas .................................................................................................... 37

4.3 Diagramas de bloques en Scicos ................................................................... 40

ÍNDICE DE LA MEMORIA

II



Capítulo 5 Simulación .................................................................................... 41

5.1 Introducción ................................................................................................... 41

5.2 Simulink ......................................................................................................... 42

5.3 Scicos/SciLAB ................................................................................................ 49

5.4 Comparativas ................................................................................................. 50

5.5 Conclusiones................................................................................................... 51

Capítulo 6 Ensayos ......................................................................................... 53

6.1 Introducción ................................................................................................... 53

6.2 Scicos/Scilab ................................................................................................... 53

6.3 Simulink ......................................................................................................... 54

6.4 Conclusiones................................................................................................... 57

Capítulo 7 Futuros desarrollos ...................................................................... 61

ANEXO I Ajuste de la planta por MMM ....................................................... 63

ANEXO II Configuración BootCD ................................................................ 67

ANEXO III Errores y posibles soluciones en compilación .............................. 75

ANEXO IV Plantilla de bloques Scicos ............................................................. 81

Bibliografía 89

Parte II Estudio económico ........................................................................ 91

Capítulo 1 Estudio económico ........................................................................ 93

Capítulo 2 Costes unitarios ............................................................................ 95

Capítulo 3 Sumas parciales ............................................................................ 97

Capítulo 4 Presupuesto general ..................................................................... 99

Parte III Manual de usuario ..................................................................... 101

Capítulo 1 Manual de usuario 1 .................................................................. 103

- 1 -



Índice de figuras

Figura 1. Evolución de los ordenadores…………………………………………. 8

Figura 2. Implantación de sistema de control……………………………………. 9

Figura 3. Ejemplo de entorno grafico de Simulink……………….……………...10

Figura 4. Hardware in the Loop ……………………………………..…………. 13

Figura 5. Esquema de un SOTR…………………...……………………………. 25

Figura 6. Esquema de funcionamiento y comunicaciones de RTAI….………… 26

Figura 7. Modelo de funcionamiento de un PC con RTAI para operar en tiempo

real ……………………………………………………………………………….27

Figura 8. Ejemplo de un diagrama de bloques de Scicos……………..………….32

Figura 9. DAQ PCI6013…………………………………...…………………….33

Figura 10. Regulador de velocidad del motor…………………………………....35

Figura 11. Regulador de velocidad y posición……………..…………………….36

Figura 12. National Instruments PCI-6013………………………...…………….36

Figura 13. Estator de imanes permanentes y circuito del rotor........…………….37

Figura 14. Esquema electromecánico de un motor de CC...…………………….37

Figura 15. Diagrama de bloques en Scicos para ensayos ....…………………….40

Figura 16. Comparación de los posibles modelos y ensayo con escalón de 10 (50-

60%)…………………………………………………………..…...…………….42

Figura 17. Kp=10,2 con Mp=19’80%…………………...………...…………….43

Figura 18. Mando con Kp=10’2…………………………………...…………….43

Figura 19. Polos y ceros de la función de transferencia...………...….………….44

- 2 -



Figura 20. Diagrama de Black …………..………………………...…………….45

Figura 21. Diagrama de Bode …………...………………………...…………….45

Figura 22. Respuesta del mando a un escalón con control PI ..…...…………….47

Figura 23. Respuesta a un escalón con control ….………………...…………….47

Figura 24. Diagrama de bloques de simulación …………………...…………….48

Figura 25. Matlab to Scicos ……………..………………………...…………….49

Figura 26. Comparativa 1 Scicos/Simulink …..…………………...…………….50

Figura 27. Comparativa 2 Scicos/Simulink...……………………...…………….51

Figura 28. Diagrama de bloques para ensayo en Scicos…………...…………….54

Figura 29. Diagrama de bloques para ensayo en Simulink………...…………….54

Figura 30. Comparación con escalón de 15% cambiando punto de trabajo (40-

55%)……………………………………………………...………...…………….55

Figura 31. Comparación con escalón de bajada …………………...…………….56

Figura 32. Comparación con Kp=10 (50-65%) ……….…………...…………….56

- 3 -



Índice de tablas

Tabla 1. Tiempos de respuesta al escalón ……….…………...………………….44

Tabla 2. Valores significativos de la respuesta en frecuencia...………………….46

Tabla 3. Uso de CPU con Scicos y Simulink…….…………...………………….50

Introducción

- 4 -



Introducción

- 5 -



Parte I MEMORIA

Introducción

- 6 -



Introducción

- 7 -



Capítulo 1 INTRODUCCIÓN

En este capítulo se hace una introducción del proyecto. En la sección 1.1

se comentará el estado del arte y cuál ha sido la evolución a lo largo del tiempo de

los sistemas de control, además de cuales han sido sus fortalezas y debilidades; y

cómo estas últimas han sido abordadas por la ingeniería. Posteriormente en la

sección 1.2 se hablará acerca de la motivación de este proyecto y porqué se

considera una materia interesante de estudio y desarrollo para sistemas de control.

Por último, en la sección 1.3 y siguientes, se enumerarán los objetivos y la

metodología propuesta para llevarlos a cabo.

1.1 ESTUDIO DE LOS TRABAJOS EXISTENTES /

TECNOLOGÍAS EXISTENTES

A día de hoy, son múltiples las opciones que se presentan para controlar

una planta haciendo uso de un control digital, y raro es encontrar una rama de

desarrollo o posible innovación tecnológica, donde la ingeniería no haya puesto su

sello.

En lo que se refiere a la implementación de controladores, éstos al inicio

eran desarrollados mediante dispositivos de electrónica analógica. Sin embargo

pronto se comprobó la limitación de los mismos al no ser capaces de desarrollar

algunos tipos de control más complejos, ya que no había circuitos desarrollados

para tales fines.

Por otro lado, la creación de los primeros ordenadores abrió el camino a

infinidad de procesos de aplicación al desarrollo. Aunque el principal problema de

esto al inicio, era que los ordenadores estaban pensados y desarrollados para

tareas de matemática computacional; además, como es sabido por todos, eran

Introducción

- 8 -



aparatos grandes, pesados y sobretodo muy costosos. Con el paso de los años,

estos ordenadores empezaron a distribuirse en versiones más reducidas, eficientes

y accesibles a un mayor público.

Figura 1. Evolución de los ordenadores

La evolución de los dos sucesos expuestos (creación de controladores y

ordenadores de uso accesible) llevaron inevitablemente a tratar de resolver los

problemas de uno, con las capacidades del otro. Es de aquí de donde nacieron los

primeros controles digitales. Con el paso de los años, la informática se desarrolló

a un ritmo exponencial, con lo que empezaron a poderse crear controles digitales

que eran impensables para la electrónica analógica.

Podría parecer que tras lo expuesto, la electrónica analógica no tendría

cabida en el diseño de controladores. Lo que sí es evidente, es que el papel

fundamental del control lo lleva a cabo el controlador digital, que es capaz de

procesar las ecuaciones de control necesarias para gobernar la planta.

Introducción

- 9 -



Un ejemplo de la implantación de estos sistemas de control se puede ver

en la Figura 2; en la que el control digital, haciendo uso de la información

transmitida por los sensores y de entradas de referencia es capaz de controlar los

actuadores que gobernarán la planta.

Figura 2. Implantación de sistema de control

Todo lo anterior podría hacer pensar que ya estaba todo resuelto, y que los

controles digitales habían resuelto todos aquellos problemas que la electrónica

analógica no había sido capaz de resolver. Esto en teoría es cierto, pero en el

momento de su desarrollo, la verdad era otra: los equipos requeridos para la

implementación era grandes y costosos (menos que los primeros, eso sí) además

de que aún eran equipos lentos para ciertas necesidades. A día de hoy, como es

bien sabido, los equipos han evolucionado y son relativamente asequibles y

prácticamente, todo lo rápido que se necesiten. Así que se puede concluir, que las

ventajas actuales de implantar controladores digitales, no dejan lugar a dudas.

Tras haberse conseguido una tecnología económica y robusta en la

implantación de sistemas de control digital, el siguiente paso fue la creación de

entornos gráficos que permitieran al usuario (incluso, si éste no era un experto)

desarrollar controladores para sus propios fines.

Introducción

- 10 -



A día de hoy son múltiples los softwares existentes para la realización de

simulaciones de sistemas autónomos. Quizás el académicamente más conocido es

Simulink (basado en el entorno gráfico de MatLab). En cuanto al número de

licencias instaladas, es de los más importantes, quizás en gran parte debido a su

atractiva interfaz, y que permite ser muy versátil a la hora de realizar

simulaciones. Dicha versatilidad se consigue con la posibilidad de introducir

diagramas de bloques con lo que se llaman ‘cajas negras’ que son subsistemas que

el usuario crea y que no tienen por qué responder a procesos físicos definidos en

la realidad.

Figura 3. Ejemplo de entorno gráfico de Simulink

La contrapartida de este software es que no se trata de un software

gratuito, sino que el usuario debe adquirir licencias de uso. Por lo tanto, dado que

es propiedad industrial de una marca, estará limitado por las actualizaciones que

el mismo fabricante haga de su producto.

La solución a este último punto (y en especial para lo que se buscará la

realización de dicho proyecto) es el natural paso a programas de software libre,

donde el sistema se encuentra en continua evolución por parte de los

usuarios/desarrolladores que buscan cada vez encontrar soluciones a los

problemas que plantean sistemas de automatización cada vez más complejos.

La creación de estos sistemas operativos libres [11], vio su punto de

inflexión cuando en 1991 Linus Torvalds creó el kernel de Linux. Esto supuso un

gran avance al proyecto GNU liderado por Richard Stallman que hizo finalmente

posible el desarrollo de robustos sistemas operativos libres. Tras aquello, el

Introducción

- 11 -



crecimiento ha sido exponencial e innumerables dispositivos han ido adoptando

sistemas basados en Linux, con su SO base. Además para continuar con la

filosofía de código abierto, surgieron múltiples aplicaciones de software como

OppenOffice (ofimática) Gimp (editor de imágenes). La contrapartida de todo

esto, es que en su mayoría son aplicaciones que están en continuo desarrollo y

muchas no están aún optimizadas. Este es el caso, por ejemplo, de aplicaciones

matemáticas y de control como Octave, Scilab y Scipy que distan de sus

competidores más comerciales como el anteriormente citado MatLab o

Mathemathica.

No obstante y en lo que concierne al proyecto, cabe destacar la existencia

de software basado en sistemas operativos en tiempo real o RTOS. En ellos,

mediante diversas herramientas de software se consigue configurar un ordenador

convencional para trabajar de manera determinista, siendo éste capaz de atender a

las rutinas y tareas críticas definidas por el usuario. Y es ahí donde la apuesta por

el software libre lleva ventaja sobre la que no; porque pese a que existen versiones

para otros sistemas operativos que permiten las mismas funcionalidades como

WindowsCE o VxWorks, entre otros, la robustez de los SO FreeSource es muy

elevada.

Esta gran competitividad [11] se inició en el año 1997 con la creación de

RTLinux, así como una variedad considerable de RTOS hasta día de hoy. Y es

sobre una de ellas, RTAI, sobre la que se fundamentará el actual proyecto.

Este RTOS de RTAI (Real Time Application Interface) es capaz de dotar a

Linux de funcionalidades en tiempo real, lo cual sumado a las posibilidades de

control que ofrecen programas como Scilab, hizo que comenzaran a desarrollarse

herramientas de control en tiempo real como RTAI-Lab.

RTAI-Lab [10] puede considerarse un conjunto de programas y

herramientas de software que hacen posible implementar sistemas de control en

tiempo real haciendo uso de diferentes funcionalidades como diagramas de

bloques de control, modificación de parámetros de control o hasta monitorización

en tiempo real.

Introducción

- 12 -



Los principales componentes de RTAI-Lab son los siguientes:

� RTAI: Es, como se dijo anteriormente un RTOS gratuito, que mediante el

parcheo del kernel de Linux, crea un sub-kernel que prioriza las tareas

para que puedan ejecutarse en primer lugar las tareas asignadas al control

en tiempo real.

� RTAI-Lib: Es una librería de bloques y demás utilidades, listas para ser

usadas con el programa Scilab/Scicos y que permiten al usuario crear

bloques de control en una interfaz amigable. Además, incorpora la

posibilidad de crear bloques para tarjetas de adquisición de señales.

� Xrtailab: Es un software que muestra al usuario un osciloscopio en

pantalla, el cual es capaz de poder ser referenciado en cualquier punto del

sistema de control; permitiendo al usuario hacer modificaciones en tiempo

real y ver monitorizadas en pantalla las consecuentes variaciones sobre el

sistema.

� Scilab/Scicos: Scilab [8] es un software CACSD (Computer Aided

Control System Design) FreeSource para calculo numérico. Éste, a su vez

incluye Scicos, que es un editor de bloques para simular y/o controlar

procesos de control.

� Comedi: Suministra librerías de funciones [12], drivers y una API para

controlar un gran número de dispositivos comerciales de hardware de

adquisición de señales, e incluso permite la compilación de propios

drivers, algo muy a tener en cuenta y que no permiten otros programas que

no sean FreeSource.

La simulación [16] hardware-in-the-loop (HIL) es una técnica usada para el

desarrollo y comprobación de sistemas empotrados en tiempo real complejos. La

simulación HIL constituye una plataforma efectiva porque incluye toda la

complejidad de la planta que controla el sistema empotrado. Esto lo realiza

mediante modelos matemáticos de todos los sistemas dinámicos relacionados con

la planta bajo control, formando lo que se denomina como "simulación de la

planta". El sistema empotrado que se está comprobando interactúa con esta

Introducción

- 13 -



simulación de la planta. En muchos casos, la forma más efectiva de desarrollar

sistemas empotrados es conectar el sistema empotrado a la planta real. En otras

palabras, conectar una centralita de motor (sistema empotrado) a un motor real

(planta real).

Figura 4. Hardware in the loop

En otros casos, la simulación HIL es más eficiente. El baremo que determina

qué utilizar depende entre otros factores del coste, la duración y de la seguridad.

El coste dará una medida del coste total de todas las herramientas y el esfuerzo

requerido. La duración del desarrollo y testeo determinará el tiempo de ciclo de

producto hasta su comercialización. El factor de seguridad y duración están

supeditados al coste económico.

Las condiciones en las que el uso de simulación hardware-in-the-loop es

adecuado incluyen:

� Cortos ciclos de desarrollo de software:

La planificación de ciclos cortos de desarrollo asociados a la mayoría de

proyectos en la industria automotriz, aeroespacial y en programas de

defensa no permiten esperar a la disponibilidad del primer prototipo para

testeo del sistema empotrado. Es más, en la mayor parte de las

planificaciones de proyecto se asume que la simulación hardware-in-the-

Introducción

- 14 -



loop se usará en paralelo con el desarrollo de la planta. Por ejemplo, en el

momento en el que el primer prototipo de motor está disponible para

testeo, el 95% del testeo de la centralita de motor ha sido completado a

través de simulación hardware-in-the-loop. Los ciclos de desarrollo más

cortos se dan en la industria aeroespacial y defensa. Programas de

desarrollo de aviones y vehículos militares usan en paralelo PC y HIL

simulación para mejorar el diseño, testeo e integración.

� Modelo de planta fiable y económico:

En muchos casos, la planta es más costosa que un simulador fiable en

tiempo real y por ello es más recomendable su simulación. Por

consiguiente, es más económico el desarrollo y testeo conectado a un

simulador HIL que a la planta real. Para fabricantes de motores, la

simulación HIL es parte fundamental del ciclo de desarrollo del motor. El

desarrollo de centralitas digitales para control de motores de aviones es un

ejemplo de reducción de costes a través de simulación HIL. Cada motor

puede costar millones de euros. Por el contrario, el uso de simuladores

HIL puede reducir a una décima parte ese coste.

� Desarrollo de interacción usuario-sistema de control:

La simulación HIL es un paso clave en el proceso de análisis de la

interacción del entorno HIL con el usuario, asegurando la consistencia del

sistema optimizando la ergonomía del software. La tarea de la tecnología

en tiempo real es tomar datos de usuarios para testeo de componentes que

tendrán una interfaz humana. La alternativa a este caso sería el uso de un

modelo de usuario (por ejemplo, un modelo de conductor en el caso de un

entorno HIL de vehículo completo).

Introducción

- 15 -



� Posibilidad de automatización

El entorno HIL es automatizable. Es decir, el testeo se puede llevar a cabo

sin la presencia de un usuario como sería el caso si el modelo de planta

fuera un componente real. Por ello, el testeo en entornos HIL es

consistente, rápido y eficiente.

Introducción

- 16 -



1.2 MOTIVACIÓN DEL PROYECTO

Una vez expuesta la evolución y situación actual de algunos programas de

software de control, se procederá a explicar al lector el porqué de este proyecto.

Brevemente voy a exponer los problemas a los cuales pretende dar solución

este proyecto:

� Los sistemas de software de control comerciales como Matlab/Simulink,

aunque bien desarrollados, son programas costosos con licencias que hay

que estar pendientes de renovar.

� Si se busca compaginar el control y monitorización en tiempo real del

sistema, las opciones no son mucho mejores, ya que aquí las opciones son

aún más reducidas y frecuentemente tienen problemas de incompatibilidad

de diversa índole. Por ejemplo, VxWORKS es un sistema operativo en

tiempo real (de pago) cuyas aplicaciones actuales se centran en desarrollar

funciones de control de equipos aeroespaciales; algo que sería un

sinsentido usar en el control de velocidad de un simple motor.

� Actualmente la limitación de potencia, rendimiento o incluso frecuencias

de funcionamiento no es un impedimento. Pero una cosa es la existencia

de dicha tecnología, y otra que sea rentable adaptarla a nuestros

propósitos. Y es por tanto, labor de un ingeniero, analizar otras opciones y

estudiar si su implantación puede ser igual de efectiva a la par que

rentable.

En el punto actual, tras haber visto las posibilidades y sus principales

inconvenientes se procederá a enumerar los puntos a favor en pos de la realización

del presente proyecto:

� Se ha desarrollado un paquete de software libre y gratuito que será capaz

de hacer el mismo control de una planta (control de un motor) que podría

Introducción

- 17 -



hacer su dual de pago Matlab/Simulink en los laboratorios de control de

ICAI.

� Dicho software (tanto su RTOS como RTAI-Lab) es posible instalarse en

cualquier ordenador, así como proporcionar la opción al usuario de

ejecutar desde un CD-Boot sin preocuparse de tener que instalar ningún

sistema operativo; y que éste corra directamente de una unidad de CD o

USB. En resumen, el usuario aun en caso de desconocer hasta los

principios más básicos de Linux-kernel o RTOS, podrá usar todo lo

desarrollado en este proyecto desde su pc sin preocuparse.

� Dado el reducido espacio que ocupará en disco, unos 800mB, y que

correrá con una de las versiones más ligeras y básicas de Linux, podrá ser

ejecutado desde algún ordenador empotrado como un PC/104.

� Como se dijo anteriormente, la tecnología tiene un coste, y si se busca ser

capaz de realizar controles en tiempo discreto, el poder elegir una

frecuencia de muestreo muy pequeña puede acabar por ser imposible, o

bien, muy costosa. Esto es debido a que una gran parte de la capacidad de

procesos del ordenador suelen estar dedicada a entornos gráficos o

aplicaciones secundarias. Esto es algo que no sucede con sistemas RTOS

en los que la prioridad máxima de interrupción, está definida para tareas

en tiempo real, con lo que nos garantizamos optimizar la capacidad del

sistema para atender a las tareas que de verdad importan. Y esto, es algo

que puede conseguirse al usar programas FreeSource donde el código es

abierto.

� Una ventaja, que aunque pudiera no ser demandada por todos los usuarios;

es que en todos los programas que no son FreeSource el código es cerrado,

esto es, que el usuario no puede acceder a su modificación. Esto en general

podría ser una garantía de que el usuario no va a usar mal el software, es

cierto; pero también impide que si el usuario diseña un sistema propio,

éste no pueda ser usado al carecer de drivers. Pero esto, gracias a Comedi,

es posible arreglarlo, ya que el usuario solo tiene que compilar

Introducción

- 18 -



correctamente el código en C y cargar el modulo en el sistema, para que

pueda ser reconocido como un driver comercial más.

Es por todo lo anterior que se considera una atractiva opción el realizar este

proyecto. Porque además, ya que se ha pensado para darle uso en los laboratorios

de control de ICAI, puede servir a futuras generaciones para familiarizarse con

otros sistemas operativos y de control que a priori resultan más costosos de

entender que los convencionales basados en Microsoft Windows.

Introducción

- 19 -



1.3 OBJETIVOS

El primer objetivo es instalar y configurar el ordenador destinado al

proyecto, Optiplex GX-280, un SOTR como RTAI y verificar mediante los

programas de test que la propia aplicación provee, su correcto funcionamiento.

En segundo lugar, haciendo uso de Scicos, se modelará la planta y sus

controladores para poderse realizar tanto ensayos como simulaciones.

Por último, el objetivo final del proyecto es el de implementar en un

RTOS, el control en tiempo real que permita controlar el sistema dinámico de

velocidad de un motor de CC, mediante el entorno grafico de Scilab/Scicos.

Finalmente como objetivo adicional, se buscará implementar todo el

sistema citado (RTOS+RTAILab) en un dispositivo empotrado como el PC104.

1.4 METODOLOGÍA

Con objeto de tratar de dar solución a los objetivos anteriormente citados, se

llevará a cabo la siguiente metodología, desarrollada en apartados.

� Recopilación de información y software.

� Configuración del PC para trabajar con RTAI

� Instalación de los Comedi-drivers

� Simulaciones en Scicos y Simulink

� Ensayos en Scicos y Simulink

� Creación del CD-Boot final estable

� Implementación en PC/104

� Ensayos con PC/104

Introducción

- 20 -



1.5 RECURSOS / HERRAMIENTAS EMPLEADAS

Para el desarrollo del proyecto, se ha hecho uso de herramientas de

software y hardware, así como diverso material académico y divulgativo de

consulta.

A continuación se enumeran los elementos de hardware utilizados:

� Ordenador Dell Optiplex GX-280

� Periféricos básicos: Pantalla, ratón y teclado

� Tarjeta PCI-6013 de National Instruments

� Banco de ensayos de motor

Los siguientes programas han sido utilizados en la realización del proyecto;

aunque en capítulos sucesivos se hablará más en profundidad de todos ellos:

� Kernel 2.6 vanila de Linux

� RTAI 3.5

� Comedi y ComediLib

� Scicos y ScicosLab

� Matlab/Simulink

Fundamentos del kernel y linux

- 21 -



Capítulo 2 FUNDAMENTOS DEL KERNEL Y

LINUX

2.1 INTRODUCCIÓN

En el presente capítulo, se explicará el modo de interacción de las diversas

partes del sistema operativo que permiten operar en tiempo real al sistema.

Como se introdujo en el capítulo anterior, un sistema en tiempo real es

aquel sistema capaz de garantizar que tareas y procesos que se encuentran bajo su

dependencia sean atendidos bajo condiciones de latencias estrictas y definidas.

Todos los sistemas [11] informáticos (sobretodo los actuales), tienen una

muy baja latencia, pero su diferencia con los sistemas en tiempo real, es que dicha

latencia permanece constante e invariante aun cuando la carga del procesador se

incremente.

Existen dos clasificaciones [5] posibles de tiempo real:

� Tiempo Real Estricto: Donde la atención a las tareas se desarrollan en un

intervalo de tiempo especificado (Hard Time).

� Tiempo Real Flexible: En el cual pueden dejarse de atender algunas tareas,

puntualmente, pero el tiempo de respuesta disminuye con el paso del

tiempo


- 22 -



2.2 DEFINICIONES

En primer lugar, se procederá a introducir algunos conceptos [20] clave que

permitan al lector conocer algunos de los términos fundamentales en la temática

del proyecto.

� Kernel: Es el principal responsable de facilitar a los distintos programas

acceso seguro al hardware de la computadora o en forma básica, es el

encargado de gestionar recursos, a través de servicios de llamada al

sistema. Como hay muchos programas y el acceso al hardware es limitado,

también se encarga de decidir qué programa podrá hacer uso de un

dispositivo de hardware y durante cuánto tiempo, lo que se conoce como

multiplexado. Acceder al hardware directamente puede ser realmente

complejo, por lo que los núcleos suelen implementar una serie de

abstracciones del hardware. Esto permite esconder la complejidad, y

proporciona una interfaz limpia y uniforme al hardware subyacente

� Sub-kernel: Separa las tareas comunes del kernel y las tareas de tiempo

real, dando una mayor prioridad a éstas últimas. Su función es ser el nuevo

administrador de las funciones centrales del sistema

� Tarea de propósito general: Son aquellas tareas que el sistema reserva

principalmente para ser asignadas a las peticiones de usuario.

� SOTR: Sistema Operativo en Tiempo Real (por ejemplo, RTAI)

� Módulos: se refiere a un controlador de un dispositivo o servicio que

puede cargarse o descargarse cuando el usuario o algún dispositivo lo

solicita dinámicamente.

� Compilador: Es un programa que permite traducir el código fuente de un

programa en lenguaje de alto nivel, a otro lenguaje de nivel inferior

(típicamente lenguaje de máquina). De esta manera un programador puede

diseñar un programa en un lenguaje mucho más cercano a cómo piensa un


- 23 -



ser humano, para luego compilarlo a un programa más manejable por una

computadora

2.3 FUNCIONAMIENTO

El proceso de implementación de un sistema operativo en tiempo real,

consiste en colocar una capa intermedia que comunique el hardware con el kernel

original del sistema; algo que se podría denominar como un sub-kernel.

Este sub-kernel, se encarga de controlar la ejecución de las tareas en

tiempo real con una mayor prioridad de interrupción que el kernel. De este modo,

tareas no asociadas a tiempo real se ejecutarán únicamente cuando las tareas en

tiempo real hayan sido atendidas.

Con esta modificación de las prioridades de atención, se garantiza que la

latencia de atención a tareas asociadas a tiempo real sea lo menor posible y como

consecuencia de ello se reduce considerablemente la carga al procesador.

A su vez, a la hora de compilar el sub-kernel, es habitual que si se desea

que el dispositivo trabaje con aplicaciones destinadas al control en tiempo real, se

puedan suprimir ciertas partes del kernel que no aportan nada al proceso; con lo

que se consigue un sistema más fluido.


- 24 -



2.4 IMPLANTACIÓN EN SISTEMAS EN TIEMPO REAL

Cualquier sistema operativo de propósito general [5], basa su

funcionamiento en la atención a procesos como: gestión de memoria, interacción

con el hardware, comunicaciones,… Todas estas tareas tienen asignadas

prioridades que generalmente se modifican en el transcurso del tiempo y que

permiten que otras con mayor prioridad las interrumpan. Esto sucede así, debido a

que los sistemas operativos de propósito general están pensados para atender

prioritariamente a las peticiones del usuario.

Por otro lado, los sistemas operativos en tiempo real se desarrollan para ser

capaces de atender las tareas prioritarias en un plazo de tiempo determinado.

Además, esta atención se centra en dar prioridad a las interrupciones del

procesador y los periféricos, de forma que garantice que ninguna tarea ligada al

tiempo real quede sin atenderse.

Al implantar el nuevo sistema, se crea como se dijo anteriormente, una

nueva capa o sub-kernel cuya función es ser el nuevo administrador de las

funciones centrales del sistema. Dicho sub-kernel, separa las tareas comunes del

kernel y las tareas de tiempo real, dando una mayor prioridad a estas últimas. Así,

se puede garantizar que ninguna tarea de propósito general sea prioritaria (ni

interrumpa) a las tareas asignadas a tiempo real.

Para hacer operativa esta nueva capa intermedia que gobierne el sistema,

es necesario parchear el kernel original del Linux (también conocido como

“vanila version”) el cual permite desarrollar los cambios de prioridad

anteriormente citados.

El parcheo del kernel, se lleva a cabo con la interfaz de RTAI (Real Time

Application Interface), el cual permite además de asignar las nuevas prioridades y

crear el sub-kernel, convertir el sistema operativo estándar basado en GNU/Linux,

en un SOTR.


- 25 -



Figura 5. Esquema de un SOTR

Como se puede apreciar en la Figura 5, el denominado micro-kernel (o

sub-kernel) procesa las interrupciones del hardware y ejecuta las tareas asignadas

a tiempo real vinculadas a dichas interrupciones con la menor latencia posible.

Este principio de funcionamiento es también el usado por el SOTR, RTLinux.


- 26 -



2.5 CARGA DE MÓDULOS

Una parte fundamental de RTAI, es la de la carga de módulos. Este uso de

módulos, permite de manera dinámica su escritura en particiones del kernel como

bloques y sub-bloques que pueden ser cargados de manera independiente para

satisfacer los propósitos de ejecución del SOTR.

En la siguiente figura, se muestra un esquema básico de funcionamiento de

RTAI.

Figura 6. Esquema de funcionamiento y comunicaciones de RTAI


- 27 -



Figura 7. Modelo de funcionamiento de un PC con RTAI-Lab para operar en tiempo real

La estructura del kernel de Linux, usa una arquitectura de arranque

predefinida desde el inicio del sistema. Dicha arquitectura contiene diversos

módulos que permite el manejo de archivos, controladores, periféricos,.. Por otra

parte existen módulos que son posibles ser cargados una vez inició el sistema, y

que a cada reinicio, deberán ser nuevamente cargados. Éstos son los módulos de

los que se vale RTAI para manejar el sistema en tiempo real.

Los módulos del kernel, son principalmente archivos que contienen rutinas

y/o instrucciones a cargar en el espacio del kernel. De este modo, el módulo

convive con el resto de los elementos del kernel, y en caso de ser requerido por

alguna aplicación, el kernel facilita su ruta de acceso para su posterior ejecución.

Los principales comandos para la carga y manejo de módulos en Linux son

(en una ventana de comandos y como superusuario #sudo):

� #insmod “modulo” (Inserta el modulo en el kernel)

� #rmmod “modulo” (Borra el modulo del kernel)

� #lsmod (Muestra un listado de los módulos existentes)


- 28 -



La carga de RTAI implica la carga de los siguientes módulos en el kernel:

� rtai: Es el módulo del núcleo de funcionamiento que posibilita que

todas las tareas en tiempo real se ejecuten. RTAI inicializa las

variables de control y estructuras, así como las funciones específicas

que posibilitan las interrupciones. Para la carga del módulo, cuando es

requerido por otras instrucciones, se hace una llamada a la función

rt_mount_rtai() que lo activa; y a la función rt_unmount_rtai() para

desactivarlo y mandar RTAI a hibernación. Mientras RTAI

permanezca operativo, filtrará las interrupciones que llegarán al Linux

y asignará las prioridades pertinentes.

� rtai_sched: Es el módulo del planificador, el cual se encarga de

repartir los recursos de la CPU para cada una de las respectivas tareas.

Dicho planificador entra en ejecución, cuando varias tareas llaman al

sistema para su ejecución. El planificador, por medio de su

temporizador asigna prioridades de atención para ser capaz de ejecutar

las tareas en tiempo real prioritariamente. RTAI considera la prioridad

0 como la mayor, y la 0x3FFFFFFFF a la menor de ellas (Linux recibe

la prioridad 0x7FFFFFFFF). Los servicios de atención del planificador

son:

o Funciones de tareas

o Funciones de semáforos

o Funciones de buzón

o Funciones de comunicación entre tareas

� rtai_fifo: Es el módulo responsable de encolar tareas en el espacio del

kernel. Para ello se crean colas tipo FIFO, donde la primera tarea requerida

para su atención, es la primera en ser atendida. De este modo en caso de

recibir llamadas para otras funciones de menor prioridad, se permite

asegurar que hasta que las tareas en tiempo real sean atendidas, no se

dedicaran recursos de CPU para su atención.


- 29 -



� rtai_shm: Es el módulo de RTAI que permite compartir memoria entre

tareas de tiempo real y las tareas de propósito general.

� LXRT: Es el módulo que implementa las funciones requeridas por el

planificador de RTAI. Es decir, permite compartir memoria dinámica,

semáforos, etc en sistema Linux-Linux, Linux-RTAI y RTAI-RTAI.

� rtai_pqueue, rtai_rtheat, rtai_utils: Son los módulos que permiten

ejecutar el sistema en Hard Time (tiempo real estricto).


- 30 -



Software Scicos/Scilab

- 31 -



Capítulo 3 SOFTWARE SCICOS/SCILAB

3.1 INTRODUCCIÓN

Scilab [9] es un paquete de software numérico, que permite al usuario

realizar multitud de aplicaciones científicas y de ingeniería.

Como se mencionó al comienzo de este proyecto, Scilab es software de

código abierto y es distribuido gratuitamente en internet para usuarios de diversos

sistemas operativos. Debido a esto, Scilab es un paquete de software que es

distribuido a un gran número de empresas y entornos docentes por todo el mundo.

Gracias a sus características de código abierto, hay un gran número de

desarrolladores que constantemente actualizan los campos y características del

programa, para ofrecer al usuario una experiencia lo más satisfactoria posible.

Por otra parte, Scicos [8] es un modelador gráfico de simulación y

sistemas dinámicos. Mediante el uso de diagramas de bloques, el usuario puede

desarrollar sistemas de control para una gran multitud de aplicaciones, así como

simularlas en un entorno gráfico.


- 32 -



Figura 8. Ejemplo de diagrama de bloques con Scicos

Con Scicos se puede:

� Modelar, compilar y simular sistemas dinámicos.

� Combinar simulaciones o ensayos en tiempo real y/o discreto.

� Hacer uso de bloques estandarizados.

� Programar nuevos bloques en C,Fortran,…

� Generar código C de los modelos de bloques desarrollados.

� Simular en tiempo real dispositivos reales por medio de Scicos-HIL

(hardware in the loop).

� Adición de toolboxes personalizados.


- 33 -



3.2 MÓDULOS Y DRIVERS DE COMEDI

Comedi [2] es un paquete de software gratuito, que distribuye drivers,

utilidades y librerías específicas para una gran cantidad de tarjetas de adquisición

de datos (DAQ). Todo este proyecto [12] está sustentado por numerosos

desarrolladores que implementan la programación necesaria para proporcionar al

usuario drivers de diversos dispositivos.

El paquete básico se compone de dos archivos: comedi y comedilib. Cada

uno de ellos, cuenta con diversos módulos que son cargados en el kernel.

El primero de ellos, comedi, posee los controladores para las tarjetas DAQ

que hacen uso de un módulo general que se carga en el kernel, y posteriormente

deja preparados una multitud de módulos a espera de que el usuario cargue los

más convenientes para sus desarrollos.

Figura 9. DAQ PCI-6013

Por otra parte, el segundo archivo, llamado comedilib es una librería de

diversos materiales de interfaz de usuario, así como de aplicaciones de calibración

y configuración.


- 34 -



Tras la instalación y posterior configuración de estos drivers, ya se poseen

las directrices necesarias para hacer posible la comunicación del hardware del

sistema con la DAQ. Esta comunicación, permite al dispositivo configurar, leer e

interactuar con la tarjeta de adquisición para realizar las tareas de control

requeridas por el usuario.

Las principales señales con las que Comedi permite interactuar con las

distintas DAQ se pueden clasificar en:

� Digitales

� Analógicas

� Pulsatorias: Principalmente temporizadores, encoders,…

Fundamentos teóricos de la planta

- 35 -



Capítulo 4 FUNDAMENTOS TEÓRICOS DE LA

PLANTA

4.1 INTRODUCCIÓN

Para realizar los test de funcionamiento para control de plantas, se hará uso

del sistema de control de velocidad [25] de un motor existente en uno de los

laboratorios de control de I.C.A.I.

Estos sistemas constan de las siguientes partes, que pueden ser contempladas

en la Figura 10:

� Encoder Incremental

� Dinamo

� Motor

� Reductora

� Encoder Absoluto

Figura 10. Regulador de velocidad del motor


- 36 -



Adicionalmente a estos componentes, se incluirá el regulador de velocidad

y posición de ICAI DEA (Figura 11), que además de conectar la DAQ PCI6013

con la planta, permitirá darle puntos de carga, así como realizar un control

inercial.

Figura 11. Regulador de velocidad y posición.

Además, como se introdujo con anterioridad, la DAQ que hará de nexo

entre el PC y la planta es la National Instruments PCI-6013 (Figura 12)

Figura 12. National Instruments PCI-6013


- 37 -



4.2 LEYES FÍSICAS

En el presenta capitulo se mostraran algunos esquemas de funcionamiento

y de simulación de la planta a controlar. Asimismo, se incluirán las formulas

físicas a las cuales atienden estos procesos [25].

Figura 13. Estator de imanes permanentes y circuito del rotor

Figura 14. Esquema electromecánico de un motor de CC


- 38 -




- 39 -




- 40 -



4.3 DIAGRAMAS DE BLOQUES EN SCICOS

A continuación se muestran los correspondientes diagramas de bloques

que permitirán el control dinámico de la planta.

Para el control y seguimiento del desarrollo en la implementación se hará

uso de diversos Scopes que mostraran las señales inicialmente en el propio Scicos

y posteriormente se tratará de exportar al osciloscopio virtual existente con el

paquete X-RTAILab.

A su vez, para evitar excesivos problemas de control, se introducirá a la

entrada del sistema una señal cuadrada con valor medio; la cual servirá de señal

de referencia para el motor.

Por otra parte, se han introducido diversos bloques de saturación para

evitar daños electromecánicos en el conjunto.

Figura 15. Diagrama de bloques en Scicos para ensayos

Simulación

- 41 -



Capítulo 5 SIMULACIÓN

5.1 INTRODUCCIÓN

En el presente capítulo se realizarán algunas simulaciones para poder

elegir el/los controladores más adecuados para posteriormente usarlos en los

ensayos.

En primer lugar se realizaran las simulaciones, asumiendo una

simplificación de la planta basada en un ajuste [24-25] por método de mínimos

cuadrados desarrollado en Simulink (Anexo I). De ahí, se obtendrá un modelo de

planta aproximado que será usado para diseñar los controladores.

Como el proyecto está pensado para hacer controles en tiempo real, no se

realizarán discretizaciones en Simulink, sino que se emplearán periodos de

muestreo lo más pequeños posibles.

Simulación

- 42 -



5.2 SIMULINK

Tras hacer una estimación de los parámetros del modelo de la planta por

medio del anteriormente citado procedimiento (Anexo I), se obtiene un modelo de

planta para simulación de segundo grado con zero, que es el que mejor responde

al modelo real de la planta, como se muestra en la Figura 16.

Ecuación 1. Aproximación de la planta

Figura 16. Comparación de los posibles modelos y ensayo con escalón de 10 (50%-60%)

Simulación

- 43 -



� Control P:

A continuación en la Figura 17, se muestra el control P elegido (Kp=10.2), que cumple con que para un escalón del 50% al 65% en la referencia, proporciona una respuesta lo más rápida posible y con un sobrepaso inferior al 20%. En la Figura 18 se puede comprobar como el mando no satura (±300)

Figura 17. Kp=10.2 con Mp=19,80%

Figura 18. Mando con Kp=10.2

Simulación

- 44 -



La función de transferencia de lazo cerrado entre referencia y salida es la siguiente:

Cuya ganancia estática F(0)=0.9638

Y sus polos son los que se muestran en la Figura 19.

Figura 19. Polos y ceros de la función de transferencia

Una vez diseñado el control, se procederá a analizar la respuesta a un escalón unitario en la referencia y se verificara la validez de las características de régimen permanente (el error) y su régimen transitorio.

Tiempo de alcance 0.00966 segundos

Tiempo de pico 0.0143 segundos

Tiempo de establecimiento al 5% 0.0204 segundos

Sobrepaso (Mp) 19.8%

Tabla 1. Tiempos de respuesta a escalón unitario

Simulación

- 45 -



Como puede comprobarse, son todos valores aceptables y dentro del rango de sobrepaso del 20%.

Seguidamente, se va a representar el diagrama de Black de lazo abierto y el diagrama de Bode de ganancia de lazo cerrado, de donde se obtendrán los índices más significativos de la respuesta en frecuencia (márgenes de estabilidad y pulsaciones asociadas, pulsación de resonancia, pico de resonancia y pulsación de corte).

Figura 20. Diagrama de Black

Figura 21. Diagrama de Bode

Simulación

- 46 -



Frecuencia (rad/s)

Margen de Fase 49.6º 188

Margen de Ganancia 11.1dB 511

Resonancia 1.63dB 205

Corte -3dB 379

Tabla 2. Valores significativos de la respuesta en frecuencia

� Control PI:

Se ha diseñado un control PI por margen de fase con un retraso

de y =118rad/s utilizando las fórmulas de PI

Se comprueba que el mando no satura como puede verse en la Figura 22.

Simulación

- 47 -



Figura 22. Respuesta del mando a un escalón con control PI

Figura 23. Respuesta a un escalón con control PI

� Control PID:

Se ha diseñado un control PID por margen de fase con un

retraso de ,

, y =221rad/s utilizando las fórmulas de PID

Simulación

- 48 -



A la vista de los controles propuestos, el usuario podrá elegir el que más le

convenga, e incluso modificarlo si así lo considerase oportuno para cumplir sus

propias especificaciones.

Figura 24. Diagrama de bloques de simulación.

Simulación

- 49 -



5.3 SCICOS/SCILAB

Para una mayor comodidad, Scicos [6] ofrece la posibilidad de importar algunos

tipos de archivos de Matlab. Esto no garantiza la compatibilidad de la totalidad de

dichos formatos de archivo, ya que aún es una opción en desarrollo; pero puede

resultar útil en algún caso para no tener que duplicar las tareas a realizar. Para

importarlo se deben seleccionar las siguientes opciones:

->Applications->m2sci

Figura 25. Matlab to Scicos

A continuación se muestran algunas de las simulaciones citadas en el anterior

apartado, pero haciendo uso del programa Scicos. Ello no aportara nuevos datos al

proyecto, pero se muestra al lector la validez de hacer uso de Scicos en vez de

otro software (Simulink en este caso), consiguiendo idénticos resultados.

Simulación

- 50 -



5.4 COMPARATIVAS

En primer lugar, y dado que una de las bases del proyecto es el

aprovechamiento de los recursos, se presenta en la Tabla 3 el porcentaje de uso

(media aritmética) del ordenador durante las diferentes simulaciones realizadas

con Simulink y con Scicos.

Con Scicos Con Simulink

Uso de la CPU [%] 23.6 67.9

Tabla 3. Uso de CPU con Scicos y Simulink

A la vista de lo anterior, se puede concluir que el sistema operando en

tiempo real con RTAI y el programa Scicos, es más eficiente y consume menos

recursos del sistema que Simulink en Windows 7.

En las siguientes figuras se muestra por otra parte la validez de los

resultados obtenidos con Scicos, comparando las salidas de las simulaciones con

las de Simulink, y apreciándose únicamente diferencias de formato.

Figura 26. Comparativa 1 Scicos/Simulink (de Figura 16)

Simulación

- 51 -



Figura 27. Comparativa 2 Scicos/Simulink (Figura 23)

5.5 CONCLUSIONES

A la vista de lo enunciado en los anteriores puntos, se puede concluir que

ambos programas, tanto Scicos como Simulink, permiten a nivel de simulación

obtener resultados prácticamente idénticos.

Puede destacarse, que Simulink proporciona herramientas extra para el

análisis de las funciones de transferencia y controladores que Scicos aún no es

capaz de hacer de manera igual de intuitiva.

Así mismo, como se dijo en 5.4. el uso de los recursos del sistema es

mucho más eficiente haciendo uso del SOTR-RTAI con Scicos, que con Windows

7 y Simulink.

Simulación

- 52 -



Ensayos

- 53 -



Capítulo 6 ENSAYOS

6.1 INTRODUCCIÓN

En el presente capitulo se mostraran algunos de los ensayos obtenidos para

controlar la planta, con los principales controladores diseñados en el Capítulo 5.

Los ensayos sin éxito, serán justificados en su respectivo apartado.

6.2 SCICOS/SCILAB

Tras diversos intentos de realizar los ensayos usando RTAI-Scicos, se

concluye que no ha sido posible su correcta implantación.

El problema radicó en la configuración de la tarjeta de adquisición de

datos PCI6013 por parte de Comedi. Tras iniciar los comandos de detección de

drivers, el sistema reconocía la tarjeta, pero la versión de Comedi existente (la

más actualizada) no era capaz de configurar correctamente las entradas y salidas

de la tarjeta. Por tanto, la comunicación que debía existir entre los sensores de la

planta y el ordenador quedaba cortada.

Si en un futuro se consiguiera solventar esta dificultad, bien corrigiendo el

código de la respectiva librería del driver PCI6013 (ni_pcimio.h) en Comedi o

bien probando con alguna otra tarjeta de adquisición de datos que usuarios en red

hayan verificado su correcto funcionamiento (por ejemplo la PCMCIA 6024E con

su driver ni_mio_cs [8]) podrían iniciarse los ensayos desde el propio SciLab

viendo en tiempo real las señales en el osciloscopio xrtailab.

Dejando a un lado el problema citado, el diseño a introducir en el diagrama

de bloques de Scicos sería el siguiente, donde únicamente habría que seleccionar

Ensayos

- 54 -



el pin de entrada/salida de las señales provenientes de la planta en el bloque de las

entradas y salidas.

Figura 28. Diagrama de bloques para ensayo en Scicos

6.3 SIMULINK

Los ensayos con Simulink han resultado más satisfactorios que con Scicos,

ya que éste tenía correctamente configurada la detección de esta tarjeta de

adquisición de datos y su configuración se realizó con éxito.

Figura 29. Diagrama de bloques para ensayos en Simulink

Ensayos

- 55 -



A continuación se muestran algunos de los ensayos obtenidos.

Figura 30. Comparación con escalón de 15% cambiando el punto de trabajo (40%-55%)

Ensayos

- 56 -



Figura 31 Comparación con escalón de bajada (50%-35%)

Figura 32. Comparación con Kp=10 (50%-65%)

Ensayos

- 57 -



6.4 CONCLUSIONES

A la vista de los resultados obtenidos, la conclusión es la siguiente: A día

de hoy, no ha sido posible implementar con éxito un sistema en tiempo real para

el control de una planta haciendo uso del software propuesto.

El motivo de fallo es, como se comentó anteriormente, el error a la hora de

configurar la tarjeta de adquisición de datos PCI6014 con los drivers provistos por

Comedi.

Es por tanto que en la búsqueda de soluciones a dicho error se pudieron

obtener las siguientes conclusiones del estado actual de la situación de desarrollos

en tiempo real:

� Actualmente, RTAI dispone de dos versiones operativas, la versión 3.8 y

la 4.0. La versión 4.0 fue la que se trató de implementar en un primer

momento pero no resulto con éxito, ya que como el propio desarrollador

informa aún está en periodo de depuración y búsqueda y corrección de

bugs.

Having tested it intensively already, we do not foresee many other

tests releases. What is likely needed the most is to have it

tested to verify building for different environments (Linux, gcc,

configure/build tool chain, hardware).

Only a few minor fixes. We are mostly interested in checking that

CPU isolations work, based just on the boot isolcpus kernel param

and IsolCpusMask at rtai_hal insmod. People using such feature are

encouraged to try it and feedback.

Dicha cita esta extraída de la web del desarrollador donde se informa que

aún hay aspectos por depurar y donde se requiere de la colaboración de los

usuarios para ir informando y solventando los bugs existentes.

Descartada la opción de instalar la versión 4.0, se procedió a instalar la 3.8

con alguna de las versiones de Linux que eran parcheables.

Ensayos

- 58 -



� La versión 3.8 de RTAI, al haber sido desarrollada en el año 2006,

requiere de versiones de Linux un tanto obsoletas como son las 2.6.XX y

hay serias dificultades a la hora de encontrar librerías y compiladores que

permitan implementar la versión modificada del Kernel con el parche de

RTAI. Así, que se puede concluir que la versión 3.8 no resulta fácilmente

implementable a día de hoy debido a que las librerías están obsoletas.

� Descartadas las dos últimas versiones de RTAI, se inició la búsqueda de

soluciones al problema. Finalmente, se optó por implementar la solución

propuesta por en foros de Comedi de hacer uso de un CD-Boot con un

RTAI versión 3.5 ya configurado en el arranque. Ésta fue la única forma

viable de tener el sistema en tiempo real configurado en el PC, ya que las

librerías inexistentes actualmente en la red, fueron usadas en su momento

para configurar el kernel del sistema operativo del CD-Boot, el cual trae

una versión de Linux llamada Knoppix.

� Una vez se consigue tener el sistema con un RTAI válido, y se pasan con

éxito los test que el propio RTAI provee para su verificación, hay que

instalar el Comedi más actualizado en el sistema. Ya que la DAQ PCI6013

no estaba recogida en los drivers de la versión Knoppix-RTAI.

Tras instalar con éxito y cargar los correspondientes módulos (también con

éxito) se procede a configurar la tarjeta PCI6013, siguiendo los pasos del

propio desarrollador, y es ahí donde ocurre el error que impide

configurarla correctamente pese a que la detección de la tarjeta sí se

realiza con éxito.

� Con Scicos, como se pudo comprobar en anteriores apartados, la

implementación ha sido total y no han surgido problemas a la hora de

disponer de cualquier diagrama de bloques, que permitiese modelar el

sistema al igual que se podría hacer con otro software (Simulink en este

caso).

Ensayos

- 59 -



Estas son las principales conclusiones a las que se ha podido llegar a la

finalización del proyecto. En resumen, se puede decir que hay un gran problema

de incompatibilidad de librerías así como de librerías en Linux desactualizadas, lo

cual ha hecho imposible implementar de una manera efectiva la comunicación

entre la planta y el PC en tiempo real.

Ensayos

- 60 -



Futuros desarrollos

- 61 -



Capítulo 7 FUTUROS DESARROLLOS

La viabilidad de este proyecto para el futuro, pasa por encontrar una

solución a la incompatibilidad de los drivers con la DAQ.

La opción más rápida, aunque menos económica, seria sustituir la tarjeta

por alguna otra de la que se tiene la seguridad que su implantación ha sido

satisfactoria (por ejemplo la PCMCIA 6024E) que el propio Roberto Bucher,

desarrollador de RTAI, asegura en su manual que es válida.

Las otras dos opciones serian: modificar el driver y volver a compilar

Comedi o por el contrario, aguardar la versión final y depurada de RTAI-Comedi

4.0

Modificar el driver, es posible, y es precisamente una de las ventajas que

aporta este proyecto de software libre al desarrollador. Por el contrario requiere un

grado elevado de conocimientos en configuración y programación de drivers.

Por otra parte, si se espera a que los desarrolladores terminen sus

proyectos hasta conseguir una versión estable, nos podemos encontrar con dos

problemas básicamente: el primero es el tiempo que les puede llevar, y el segundo

es que ello no garantiza que tras ello el error con el driver se solvente. Para su

implementación, ya que no se sabe si habría alguna versión como la existente de

Knoppix-RTAI; se adjuntará un resumido manual de usuario con los principales

puntos a tener en cuenta para configurar de cero dicho sistema.

Es por todo lo anterior, que se recomienda prioritariamente adquirir una

tarjeta compatible con los Drivers de Comedi, que haya sido testada por usuarios.

En lo referente a la consecución de objetivos del proyecto, quedaría

implementar todo el sistema operativo y configuraciones, en un nuevo CD-Boot

que sea posible correr en el sistema empotrado PC/104. Pero dado que se trataría

de una copia del sistema a modo de CD de rescate, puede programarse para que se

ejecute automáticamente en cuanto el sistema del PC/104 arranque.

Futuros desarrollos

- 62 -



Como aplicaciones futuras, se podría pensar en trasladar el contenido del

citado CD con el Knoppix-RTAI a algún dispositivo de ordenador portátil, y

conectarlo a una planta diferente, de modo que haciendo uso del sistema en

tiempo real y el osciloscopio provisto se pueda mediante ensayos, obtener

controladores validos que luego puedan ser volcados nuevamente al PC/104. Se

conseguiría así, tener controladores en tiempo real para prácticamente cualquier

aplicación sin necesidad de conocer las leyes físicas que regulan el

comportamiento de la planta.

ANEXO I Ajuste de la planta por MMM

- 63 -



ANEXO I AJUSTE DE LA PLANTA POR MMM

plot([ref(:,2) vel(:,2) mando(:,2)]) disp( 'Hacer zoom en la zona de interés de la figura' ) disp( 'Después, pulsar cualquier tecla' ) pause [aux1,aux2]=ginput(2); aux1=ceil(aux1); time=ref(aux1(1):aux1(2),1)-ref(aux1(1),1); tfin=time(end); ent=mando(aux1(1):aux1(2),2); ent=ent-ent(1); %ent=ent-mean(ent(1:30)); sal=vel(aux1(1):aux1(2),2); sal=sal-sal(1); %sal=sal-mean(sal(1:30)); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%% ALGORITMO DE AJUSTE DE UN SISTEMA %%%%%%%%%%%%%%% %%%%%%%%%% POR MINIMOS CUADRADOS %%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %clear all clear theta thaux dgn J format compact format short e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%% PARAMETROS Y VALORES INICIALES %%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %th=[]; % 2º orden: th(1)/(th(2)*s+1)/(th(3)*s+1) %th=[]; % 2º orden + cero: th(1)*(th(4)*s+1)/(th(2)*s+1)/(th(3)*s+1) %th=[]; % 3er orden: th(1)/(th(2)*s+1)/(th(3)*s+1)/ (th(4)*s+1) %th=[]; % 3er orden + cero: th(1)*(th(5)*s+1)/(th(2)*s+1)/(th(3)*s+1)/(th(4)*s+ 1) %th=[]; % Primer orden + integrador: th(1)/(th(2)*s +1)/s %th=[]; % Primer orden + integrador + cero: th(1)*(th(3)*s+1)/(th(2)*s+1)/s %th=[]; % Segundo orden + integrador: th(1)/(th(2)*s+1)/(th(3)*s+1)/s %th=[]; % Segundo orden + integrador + cero: th(1)*(th(4)*s+1)/(th(2)*s+1)/(th(3)*s+1)/s theta=th; Np=length(theta); % Numero de parametros


- 64 -



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% PARAMETROS DEL ALGORITMO %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %tfin=length(time)-1; % Tiempo final de simulaci on Tsamp=ts; % Intervalo fijo de integracion Nd=tfin/Tsamp; % Numero de datos en el ajuste tol1=1; % Tolerancia (variacion de la funcion objetivo 'V') tol2=1; % Tolerancia (variacion de los parametros 'theta') V=1; % Inicializacion del valor anterior la funcion obje tivo Vaux=0.01; % Inicializacion del valor nuevo de la funcion obje tivo dgn=ones(1,Np); % Direccion de Gauss-Newton (incremento de los parametros) niter=0; % Numero de iteraciones %%%%%%%%%%%%%% CHEQUO DE LA ESTABILIDAD INICIAL % Matriz de estado del sistema (linealizacion) [A,B,C,D]=linmod( 'sistema' ); % Flag de estabilidad (¿la parte real de todos los % autovalores de 'A' son negativas?) stb=all(real(eig(A))<=0); if stb==0 disp( 'SISTEMA INESTABLE. MODIFICA LOS PARAMETROS DEL REGULADOR') return end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%% ALGORITMO DE AJUSTE %%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % El algoritmo se ejecuta mientras (bucle while) la variacion de % la funcion objetivo en % es mayor que 'tol1' o el maximo incremento % en % de los parametros es mayor que 'tol2'. % Tambien se puede usar como criterio el numero de iteraciones. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% while (100*(V-Vaux)/Vaux>tol1 | 100*max(abs(dgn./theta)) >tol2) %& niter<10 niter=niter+1; % Se incrementa el numero de iteraciones %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Actualizacion de los parametros th=theta; %h0=theta(2); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Simulacion del sistema %[t,x,ys,ym,error]=sim('sistema',tfin); sim( 'sistema' ,tfin) ys=y; ym=sal; error=ys-ym;


- 65 -



% Funcion objetivo (error cuadratico medio) V=sqrt(sum((error).^2)/Nd); % Construccion de la matriz Jacobiana por diferenci as finitas for i=1:Np thaux=theta; h=.001*abs(theta(i)); % Incremento para las derivadas if abs(theta(i))<10*sqrt(eps) h=.01*sqrt(eps); end thaux(i)=theta(i)+h; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Actualizacion de los parametros th=thaux; %h0=thaux(2); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %[t,x,yaux,ym,error]=sim('sistema',tfin); sim( 'sistema' ,tfin) yaux=y; ym=sal; error=yaux-ym; J(:,i)=(yaux-ys)/h; end % Representacion grafica de 'ys', 'ym' y del error= ys-ym clf plot(time,ym, '-r' ,time,ys, '-b' ,time,error, '-g' ) disp( 'PAUSE' ) pause disp( 'VALE' ) grid dgn=(J\(ym-ys))'; % Direccion de Gauss-Newton % BUSQUEDA DE 'MU' (ajuste del paso en la direccion de Gauss- % Newton para garantizar una disminucion de la func ion objetivo mu=2; % Inicializacion de mu Vaux=V+10; % Inicializacion de la funcion objetivo en el nuevo punto stb=1; % Flag de estabilidad del sistema (0-inestable: 1-estable) % Busqueda de 'mu' mientras no se reduzca la funcio n objetivo o % el sistema sea inestable while Vaux > V | stb==0 mu=mu/2; % Reduccion del paso


- 66 -



thaux=theta+mu*dgn; % Actualizacion de parametros %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Actualizacion de los parametros del regulador th=thaux; %h0=thaux(2); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Matriz de estado del sistema (linealizacion) [A,B,C,D]=linmod( 'sistema' ); % Flag de estabilidad (¿la parte real de todos los % autovalores de 'A' son negativas?) stb=all(real(eig(A))<=0); % Simulacion con los nuevos parametros if stb==0 yaux=zeros(size(yaux)); else %[t,x,yaux,ym,error]=sim('sistema',tfin); sim( 'sistema' ,tfin) yaux=y; ym=sal; error=yaux-ym; end % Actualizacion de la funcion objetivo Vaux=stb*sqrt(sum((yaux-ym).^2)/Nd); end % Parametros y funcion objetivo en pantalla theta=thaux Vaux end % Matriz de covarianzas de los parametros (Sensibil idades) %P=Vaux^2*inv(J'*J); %disp('Coeficientes de dispersión') %disp(100*sqrt(diag(P)')./theta)

ANEXO II Configuración BootCD

- 67 -



ANEXO II CONFIGURACIÓN BOOTCD

Dada la naturaleza de este CD de arranque [13], no es necesario instalar su

contenido en disco duro ni hacer particiones de disco para instalar el nuevo

sistema operativo. Todo el proceso se ejecuta automáticamente desde arranque del

sistema y se detectan y configuran los periféricos existentes para su uso. No

obstante, si se desea hacer una copia permanente de todo el sistema operativo en

alguna partición, existe la posibilidad de instalar en disco duro.

Después de arrancar Knoppix desde CD, abrir una consola de root y

escribir #knx2hd. Tras esto no hay más que seguir los pasos de instalación que

guiarán al usuario para instalar el contenido en disco. A continuación se muestran

algunas capturas de imagen del proceso:


- 68 -



� Novato: Sistema multiusuario con detección hw o Utiliza detección de

hardware en cada arranque del sistema. o Permite múltiples usuarios. o Hereda los comandos en el arranque (boot:) al nuevo sistema

� Knoppix: Sistema Knoppix como desde el CD o Copia el CD al disco duro.

o Funciona exactamente igual que desde el CD con la excepción de que se puede utilizar el comando apt-get para instalar nuevo software y que el sistema se monta en modo lectura-escritura.

o NO PERMITE MÚLTIPLES USUARIOS.

o Hereda los comandos en el arranque (boot:) al nuevo sistema • Debian: Sistema tipo Debian o Sólo hereda los comandos en el arranque (boot:) al nuevo sistema: acpi, noapic, nosmp, pci, pnpbios y noapm.

o Permite múltiples usuarios.

o Es la más similar a una instalación Debian convencional.

Se recomienda escoger la instalación tipo Debian


- 69 -



Posteriormente, se inician una serie de diálogos de petición de nombres de usuario

y contraseñas, que no se consideran relevantes citar aquí.


- 70 -



Se procede a reiniciar el equipo y encontrara en el inicio la opción de arrancar desde cualquier sistema operativo con que cuente el computador. Al iniciar el Knoppix desde el disco duro se deberá cargar el “xrtailab”, de la siguiente manera: • Abrir una consola Shell – konsole • Ingresar como root, digitando en la consola “su” • Luego digitar # modprobe rtai_msg # modprobe rtai_netrpc # cd /usr/realtime/bin # xrtailab


- 71 -



Para acceder a Scilab se debe abrir una consola Shell – konsole y se digita scilab, unos segundos después aparecerá la ventana scilex de scilab 4.0, donde se digitara scicos para acceder al Scicos.

Prueba de latencia: Abrir una consola Root y escribir: # cd /usr/realtime/testsuite/kern/latency # ./run Para parar la aplicación basta pulsar: Ctrl + c


- 72 -



Cargar los módulos: En una consola Root introducir: # modprobe rsrc_nonstatic # insmod /usr/realtime/modules/rtai_hal.ko # insmod /usr/realtime/modules/rtai_up.ko # o rtai_lxrt.ko # insmod /usr/realtime/modules/rtai_fifos.ko # insmod /usr/realtime/modules/rtai_sem.ko # insmod /usr/realtime/modules/rtai_mbx.ko # insmod /usr/realtime/modules/rtai_msg.ko # insmod /usr/realtime/modules/rtai_netrpc.ko # insmod /usr/realtime/modules/rtai_shm.ko # insmod /usr/realtime/modules/rtai_leds.ko # insmod /usr/realtime/modules/rtai_signal.ko # insmod /usr/realtime/modules/rtai_tasklets.ko # modprobe comedi # modprobe kcomedilib # modprobe comedi_fc # insmod /usr/realtime/modules/rtai_comedi.ko


- 73 -




- 74 -



ANEXO III Errores y posibles soluciones en compilación

- 75 -



ANEXO III ERRORES Y POSIBLES

SOLUCIONES EN COMPILACIÓN

� En Kernel

o Make menuconfig

Error: /usr/include/bits/socket.h:305:24: asm/socket.h: No such file or directory make[1]: *** [scripts/basic/fixdep] Error 1

make: *** [scripts_basic] Error 2

Solucion: Crear un nuevo link de referencia

# rm /usr/include/asm

# ln -s /usr/src/linux/include/asm-i386 /usr/include/asm

# make menuconfig

o Make

Error:

include/linux/kernel.h:10:20: stdarg.h: No such file or directory In file included from include/linux/cpumask.h:76, from include/asm/adeos.h:27,from include/linux/adeos.h:25,from include/linux/sched.h:8,from arch/i386/kernel/asm-offsets.c:7: include/linux/kernel.h:82: syntax error before "va_list" include/linux/kernel.h:82: warning: function declaration isn't a prototype include/linux/kernel.h:85: syntax error before "va_list" include/linux/kernel.h:85: warning: function declaration isn't a prototype include/linux/kernel.h:88: syntax error before "va_list" include/linux/kernel.h:88: warning: function declaration isn't a prototype include/linux/kernel.h:92: syntax error before "va_list" include/linux/kernel.h:92: warning: function declaration isn't a prototype include/linux/kernel.h:102: syntax error before "va_list" include/linux/kernel.h:102: warning: function declaration isn't a prototype make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1

make: *** [arch/i386/kernel/asm-offsets.s] Error 2

Solución: Copiar la librería


- 76 -



# cp /usr/local/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/stdarg.h /usr/src/linux-2.6.10-rtai-3.2/include/stdarg.h

# make

Error:

drivers/block/ps2esdi.c:42:30: linux/mca-legacy.h: No such file or directory drivers/block/ps2esdi.c: In function `cleanup_module': drivers/block/ps2esdi.c:209: warning: implicit declaration of function `mca_mark_as_unuse d' drivers/block/ps2esdi.c:210: warning: implicit declaration of function `mca_set_adapter_p rocfn' drivers/block/ps2esdi.c: In function `ps2esdi_geninit': drivers/block/ps2esdi.c:300: warning: implicit declaration of function `mca_find_adaIn file included from /usr/include/sys/types.h:31, from /usr/src/rtai/base/math/mathP.h:21, from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/bits/types.h:31:20: stddef.h: No such file or directory In file included from /usr/src/rtai/base/math/mathP.h:21,from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/sys/types.h:147:20: stddef.h: No such file or directory In file included from /usr/include/sys/types.h:266, from /usr/src/rtai/base/math/mathP.h:21, from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/bits/pthreadtypes.h:50: syntax error before "size_t" /usr/include/bits/pthreadtypes.h:50: warning: no semicolon at end of struct or union /usr/include/bits/pthreadtypes.h:53: syntax error before "__stacksize" /usr/include/bits/pthreadtypes.h:53: warning: type defaults to ìnt' in declaration of `__stacksize' /usr/include/bits/pthreadtypes.h:53: warning: data definition has no type or storage class /usr/include/bits/pthreadtypes.h:54: warning: type defaults to ìnt' in declaration of `pthread_attr_t' /usr/include/bits/pthreadtypes.h:54: warning: data definition has no type or storage class make[5]: *** [/usr/src/rtai/base/math/e_acos.o] Error 1 make[4]: *** [_module_/usr/src/rtai/base/math] Error 2 make[4]: Leaving directory `/usr/src/linux-2.6.10-rtai-3.2' make[3]: *** [rtai_math.ko] Error 2 make[3]: Leaving directory `/usr/src/rtai-3.2/base/math' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/rtai-3.2/base' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/rtai-3.2' make: *** [all] Error 2pter' drivers/block/ps2esdi.c:300: `MCA_NOTFOUND' undeclared (first use in this function) drivers/block/ps2esdi.c:300: (Each undeclared identifier is reported only once drivers/block/ps2esdi.c:300: for each function it appears in.)


- 77 -



drivers/block/ps2esdi.c:311: warning: implicit declaration of function `mca_set_adapter_n ame' drivers/block/ps2esdi.c:317: warning: implicit declaration of function `mca_mark_as_used' drivers/block/ps2esdi.c:318: `MCA_ProcFn' undeclared (first use in this function) drivers/block/ps2esdi.c:318: syntax error before "ps2esdi_getinfo" drivers/block/ps2esdi.c:335: warning: implicit declaration of function `mca_read_stored_p os' include/asm/mca_dma.h: At top level: drivers/block/ps2esdi.c:267: warning: `ps2esdi_getinfo' defined but not used make[2]: *** [drivers/block/ps2esdi.o] Error 1 make[1]: *** [drivers/block] Error 2

make: *** [drivers] Error 2


# cp /usr/src/linux-2.6.10-rtai-3.2/include/mca-legacy /usr/src/linux-2.6.10-rtai-3.2/include/linux/mca-legacy.h)

# make

� En RTAI

o Make

Error:

In file included from /usr/include/sys/types.h:31, from /usr/src/rtai/base/math/mathP.h:21, from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/bits/types.h:31:20: stddef.h: No such file or directory In file included from /usr/src/rtai/base/math/mathP.h:21, from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/sys/types.h:147:20: stddef.h: No such file or directory In file included from /usr/include/sys/types.h:266, from /usr/src/rtai/base/math/mathP.h:21, from /usr/src/rtai/base/math/e_acos.c:42: /usr/include/bits/pthreadtypes.h:50: syntax error before "size_t" /usr/include/bits/pthreadtypes.h:50: warning: no semicolon at end of struct or union /usr/include/bits/pthreadtypes.h:53: syntax error before "__stacksize" /usr/include/bits/pthreadtypes.h:53: warning: type defaults to ìnt' in declaration of `__stacksize' /usr/include/bits/pthreadtypes.h:53: warning: data definition has no type or storage class /usr/include/bits/pthreadtypes.h:54: warning: type defaults to ìnt' in declaration of `pthread_attr_t' /usr/include/bits/pthreadtypes.h:54: warning: data definition has no type or storage class


- 78 -



make[5]: *** [/usr/src/rtai/base/math/e_acos.o] Error 1 make[4]: *** [_module_/usr/src/rtai/base/math] Error 2 make[4]: Leaving directory `/usr/src/linux-2.6.10-rtai-3.2' make[3]: *** [rtai_math.ko] Error 2 make[3]: Leaving directory `/usr/src/rtai-3.2/base/math' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/rtai-3.2/base' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/rtai-3.2'

make: *** [all] Error 2


# cp /usr/local/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/stddef.h /usr/include/stddef.h

� Scilab

o Make all

Error:

In file included from ../graphics/Math.h:12, from ../stack-c.h:8, from javasci_globals.h:16, from javasci_globals.c:1: /usr/include/stdlib.h:583: syntax error before "__size" /usr/include/stdlib.h:739: syntax error before "size_t" /usr/include/stdlib.h:743: syntax error before "size_t" /usr/include/stdlib.h:812: syntax error before "size_t" /usr/include/stdlib.h:815: syntax error before "size_t" /usr/include/stdlib.h:819: syntax error before "size_t" /usr/include/stdlib.h:822: syntax error before "size_t" /usr/include/stdlib.h:830: syntax error before "size_t" /usr/include/stdlib.h:833: syntax error before '*' token /usr/include/stdlib.h:837: syntax error before "wchar_t" /usr/include/stdlib.h:841: syntax error before "mbstowcs" /usr/include/stdlib.h:841: syntax error before '*' token /usr/include/stdlib.h:844: syntax error before "wcstombs" /usr/include/stdlib.h:845: syntax error before '*' token /usr/include/gconv.h:176: warning: array `__data' assumed to have one element make[1]: *** [javasci_globals.o] Error 1 make[1]: Leaving directory `/usr/src/scilab- 3.1.1/routines/Javasci'

make: *** [scilex-lib] Error 2

Solucion: Desactivar componentes de Java.

# ./configure—without-java

#make all


- 79 -



� RTAI-Lab

o Make install

Error:

Starting Compilation Running Scilab ../../bin/scilex: error while loading shared libraries: libg2c.so.0: cannot open shared object file: No such file or directory generating lib and names Running Scilab ../../bin/scilex: error while loading shared libraries: libg2c.so.0: cannot open shared object file: No such file or directory End of compilation make[1]: Leaving directory `/usr/local/scilab-

3.1.1/macros/RTAI'

Solución: No puede encontrar las librerías mencionadas, así que se

crea un link que las referencie.

# ln -s /usr/local/gcc-3.2.3/lib/libg2c.so /usr/local/lib/libg2c.so

ln -s /usr/local/gcc-3.2.3/lib/libg2c.so.0 /usr/local/lib/libg2c.so.0

# ldconfig

� Xlib

Error:

Xlib: connection to ":0.0" refused by server Xlib: No protocol specified

Can't open display ":0.0"

Solución: Introducir como usuario (no como #sudo)

# xhost+


- 80 -



ANEXO IV Plantilla de bloques Scicos

- 81 -



ANEXO IV PLANTILLA DE BLOQUES SCICOS

//########################## EDIT THIS PART ############################ function [x,y,typ]=FunctionName_CHANGE_THIS(job,arg1,arg2) if job == 'set' | job == 'define' //only assign values to variables when needed num_inputs = 1 //the number of input ports num_outputs = 1 //the number of outports ports num_evtin = 1 //the number of event input ports num_evtout = 0 //the number of event output ports firing = [] // firing: a vector whose size is equal to the size of evtout> It contains output ini tial event dates (Events generated before any input event arises). N egative values stands for no initial event on the corresponding po rt. // Default value: [] state = [] // state:state: column vector, the initial continuous state of the block. Must be [] i f no continuous state. // Default value: [] dstate = [] // dstate: column vector, the initial discrete state of the block. Must be [] if no discrete state. // Default value: [] blocktype = "c" // blocktype:a character with possible values: // :'c' block output depend continuously of the tim e. // :'d' block output changes only on input events. // :'z' zero crossing block // :'l' logical block // Default value: "c" dep_u = %t //dep_u must be true if output depends continuously of the input dep_t = %f //dep_t must be true if output depends continuously of the time dep_ut = [dep_u, dep_t] // dep_ut:1x 2 vector of boolean [dep_u, dep_t], default value: [%f,%f] nzcross = 0 // nzcross: Number of zero crossing surfaces . // Default value: 0 nmode = 0 // nmode: Number of different modes . // Default value: 0 initial_label = "" // label: a character string, used as a label. // Default value: "" initial_name = "BlockName" //default blockname cfunctionname_prefix = "FunctionName_" //functionname = cfunctionname_prefix + blockname


- 82 -



initial_parameters = [initial_name; '1'; '2'; '3'] //vector of Appendix C 2 character strings, initial parameters expressions //in this example the blockname is the first parame ter (default value = initial_name), you can modify the dialog co de to change this //separate parameters with a semicolon (;)! initial_icon = 'xstringb(orig( 1),orig( 2),[''Block Caption'';name],sz( 1),sz( 2),''fill'');' //vector of character strings, initial icon definition instructions //mind the name variable (name is not quoted), a value to this variable is assigned when job == 'plot' initial_blocksize = [ 3 3 ] //2 vector, giving the initial block width and height end //########################## END EDIT ############# ############### x=[];y=[];typ=[]; select job case 'plot' then graphics=arg1.graphics; exprs=graphics.exprs; name=exprs( 1)( 1); standard_draw (arg1) case 'getinputs' then [x,y,typ]=standard_inputs(arg1) case 'getoutputs' then [x,y,typ]=standard_outputs(arg1) case 'getorigin' then [x,y]= standard_origin (arg1) case 'set' then x=arg1 model=arg1.model; graphics=arg1.graphics; exprs=graphics.exprs; while %t do //########################## EDIT THIS PART ############################ description=['' 'Parameter dialog description' 'next line' '']; // CHOOSE between a xchoices or getvalue dialog and REMOVE the other code or build your own gui dialog //########### xchoice dialog #################### //name, default value, options l1= list ('Name', 1,[exprs( 1)( 1),'change name (after closing this dialog)']); l2= list ('Parameter1', evstr (exprs( 1)( 2)),['option1','option2']); l3= list ('Parameter2', evstr (exprs( 1)( 3)),['option1','option2']); l4= list ('Parameter3', evstr (exprs( 1)( 4)),['option1','option2','option 3']); rep= x_choices (description, list (l1,l2,l3,l4)); if rep == [] then break , end name = exprs( 1)( 1); exprs( 1) = string (rep'); if rep( 1) ~= 1


- 83 -



Appendix C 3 [ok,nametemp]= getvalue ( "" , "Name:" , list ( "str" , 1),[name]); if ok name=nametemp; end end exprs( 1)( 1)= name; rpar = []; // rpar:column vector, the vector of floating point block parameters. Must be [] if no f loating point parameters. // Default value: [] ipar = [exprs( 1)( 2); exprs( 1)( 3); exprs( 1)( 4)]; // ipar:column vector, the vector of integer block par ameters. Must be [] if no integer parameters. // Default value: [] //########### end xchoice dialog ################## ## //########### getvalue dialog #################### [ok, name, param1, param2, param3, allans] = .. getvalue (description, .. ['Name'; 'Parameter1'; 'Parameter2'; 'Parameter3'], .. list ('str', 1, 'vec', 1, 'vec', 1, 'vec', 1), exprs( 1)) if ~ok then break , end exprs( 1)=allans rpar = [param1; param2]; // rpar:column vector, the vector of floating point block parameters. Must be [] if no f loating point parameters. // Default value: [] ipar = [param3]; // ipar:column vector, the vector of integer block parameters. Must be [] if no integer paramete rs. // Default value: [] //########### end getvalue dialog ################# ### //########################## END EDIT ############# ############### funam = cfunctionname_prefix + name; [ok,tt]=getCode(funam) if ~ok then break , end [model,graphics,ok]=check_io(model,graphics, ones (num_inputs, 1), .. ones (num_outputs, 1), ones (num_evtin, 1), ones (num_evtout, 1)) if ok then model.sim = list (funam, 2004 ) model.in = ones (num_inputs, 1) model.out = ones (num_outputs, 1) model.evtin = ones (num_evtin, 1) model.evtout = ones (num_evtout, 1) model.state = state model.dstate = dstate model.rpar = rpar model.ipar = ipar model.blocktype = blocktype model.firing = firing model.dep_ut = dep_ut model.nzcross = nzcross model.nmode = nmode x.model = model


- 84 -



exprs( 2) = tt graphics.exprs = exprs x.graphics = graphics break Appendix C 4 end end case 'define' then model = scicos_model () model.sim = list (' ', 2004 ) model.in = ones (num_inputs, 1) model.out = ones (num_outputs, 1) model.evtin = ones (num_evtin, 1) model.evtout = ones (num_evtout, 1) model.state = state model.dstate = dstate model.rpar = [] model.ipar = [] model.blocktype = blocktype model.firing = firing model.dep_ut = dep_ut model.nzcross = nzcross model.nmode = nmode model.label = initial_label exprs= list (initial_parameters,[]) x=standard_define (initial_blocksize,model,exprs,initial_icon) end endfunction function [ok,tt]=getCode(funam) //########################## EDIT THIS PART ############################ cfunctionsname = 'C_Function_Name' //the device name you choose using the "gen_dev" utility measure_input_time = %t //measure the time in the function inp_<cfunctionsname>_input, //in this function data is transferred from you c-file / hardware input to sci cos block output ports measure_output_time = %t //measure the time in the function out_<cfunctionsname>_output, //in this function data is transferred from scicos block input to your c-file / hardware output ports textmp ='#ifndef MODEL' textmp( $+1)='#include <math.h>' textmp( $+1)='#include <stdlib.h>' textmp( $+1)='#include < scicos / scicos_block .h>' textmp( $+1)='#endif' textmp( $+1)=''; if (measure_input_time | measure_output_time) textmp( $+1)=' #include <rtai_msg.h>', end textmp( $+1)='void '+funam+'( scicos_block *block, int flag)'; textmp( $+1)='{' textmp( $+1)=' #ifdef MODEL'


- 85 -



if measure_input_time textmp( $+1)=' static int mi_count;', textmp( $+1)=' static RTIME mi_time, mi_totaltime;', end if measure_output_time textmp( $+1)=' static int mo_count;', textmp( $+1)=' static RTIME mo_time, mo_totaltime;', end //############ DEFINE VARAIBLES ###################################### textmp( $+1)=' int i;' //needed in input and output code textmp( $+1)=' double y[' + string (num_outputs) + '];' //needed in C-FILE/HARDWARE INPUT to BLOCK OUTPUT CODE textmp( $+1)=' double u[' + string (num_inputs) + '];' //needed in BLOCK INPUT to C-FILE/HARDWARE OUTPUT CODE textmp( $+1)=' double t = get_scicos_time();' textmp( $+1)=' static int port;' Appendix C 5 //############ END DEFINE VARAIBLES ################################## textmp( $+1)=' switch(flag) {' //############ INITIALIZATION CODE ################################### textmp( $+1)=' case 4:' if measure_input_time textmp( $+1)=' mi_count = 0;', textmp( $+1)=' mi_time = 0;', textmp( $+1)=' mi_totaltime = rt_get_cpu_time_ns();', end if measure_output_time textmp( $+1)=' mo_count = 0;', textmp( $+1)=' mo_time = 0;', textmp( $+1)=' mo_totaltime = rt_get_cpu_time_ns();', end //function calls textmp( $+1)=' port = inp_' + cfunctionsname + '_init();' textmp( $+1)=' port = out_' + cfunctionsname + '_init();' //end function calls textmp( $+1)=' break ;'; //############ END INITIALIZATION CODE ############################### //############ C-FILE/HARDWARE INPUT to BLOCK OUTPU T CODE ############ textmp( $+1)=' case 1:' if measure_input_time textmp( $+1)=' mi_count++;', textmp( $+1)=' mi_time = mi_time - rt_get_cpu_time_ns();', end //function calls textmp( $+1)=' inp_' + cfunctionsname + '_input(port, y, t);' //end function calls if measure_input_time, textmp( $+1)=' mi_time = mi_time + rt_get_cpu_time_ns();', end textmp( $+1)=' for (i= 0;i<' + string (num_outputs) + ';i++) block->outptr[i][ 0] = y[i];' textmp( $+1)=' break ;' //############ END C-FILE/HARDWARE INPUT to BLOCK O UTPUT CODE ######## //############ BLOCK INPUT to C-FILE/HARDWARE OUTPU T CODE ############ textmp( $+1)=' case 2:' textmp( $+1)=' for (i= 0;i<' + string (num_inputs) + ';i++) u[i]=block->inptr[i][ 0];' if measure_output_time textmp( $+1)=' mo_count++;', textmp( $+1)=' mo_time = mo_time - rt_get_cpu_time_ns();', end //function calls


- 86 -



textmp( $+1)=' out_' + cfunctionsname + '_output(port, u, t);' //end function calls if measure_output_time, textmp( $+1)=' mo_time = mo_time + rt_get_cpu_time_ns();', end textmp( $+1)=' break ;' Appendix C 6 //############ END BLOCK INPUT to C-FILE/HARDWARE O UTPUT CODE ######## //############ FINALIZATION CODE ##################################### textmp( $+1)=' case 5:' //function calls textmp( $+1)=' inp_' + cfunctionsname + '_end(port);' textmp( $+1)=' out_' + cfunctionsname + '_end(port);' //end function calls if measure_input_time len = ( 16 - length (cfunctionsname)) / 2; s1 = []; for i= 0:len- 1 s1=s1+ "=" ; end ; s2 = []; for i= 0:len-0.5 s2=s2+ "=" ; end ; textmp( $+1)=' printf ( "" \n //=' + s1 + '= ' + cfunctionsname + ' c-input >> blk-output measurement times =' + s2 + '=\\\\\n"");' textmp( $+1)=' printf ( "" || Total runtime in seconds: %16f ||\n "" , (rt_get_cpu_time_ns() - mi_totaltime) / 1e9 );' textmp( $+1)=' printf ( "" || Number of function calls: %16d ||\n "" , mi_count);' textmp( $+1)=' if (mi_count != 0) { printf ( "" || Mean time (ns) in function : % 16d ||\n "" , mi_time / mi_count );}' textmp( $+1)=' printf ( "" \\\\=============================================== ======== =======//\n\n"");' end if measure_output_time len = ( 16 - length (cfunctionsname)) / 2; s1 = []; for i= 0:len- 1 s1=s1+ "=" ; end ; s2 = []; for i= 0:len-0.5 s2=s2+ "=" ; end ; textmp( $+1)=' printf ( "" \n //=' + s1 + '= ' + cfunctionsname + ' blk-input >> c-output measurement times =' + s2 + '=\\\\\n"");' textmp( $+1)=' printf ( "" || Total runtime in seconds: %16f ||\n "" , (rt_get_cpu_time_ns() - mo_totaltime) / 1e9 );' textmp( $+1)=' printf ( "" || Number of function calls: %16d ||\n "" , mo_count);' textmp( $+1)=' if (mo_count != 0) { printf ( "" || Mean time (ns) in function : % 16d ||\n "" , mo_time / mo_count );}' textmp( $+1)=' printf ( "" \\\\=============================================== ======== =======//\n\n"");' end textmp( $+1)=' break ;' //############ END FINALIZATION CODE ################################# textmp( $+1)=' }' textmp( $+1)='#endif' textmp( $+1)='}' //########################## END EDIT ############# ###############


- 87 -



tt=textmp ok = %t

endfunction


- 88 -



Bibliografía

- 89 -



BIBLIOGRAFÍA



[3] dSPACE.http://www.dspace.com/en/inc/home/applicationfields/researcheducatio

n/ecutesting.cfm


[5] Greg Gagne Abraham Silberschatz, Peter Baer Galvin. Fundamentos de sistemas

operativos. McGraw Hill

[6] Stephen L. Campbell, Jean-Philippe Chancelier, Ramine Nikoukhah. Modeling

and Simulation in Scilab/Scicos with ScicosLab 4.4. Springer




[10] Bucher,R., L.Dozio y P. Mantegazza (2004). Rapid control prototyping with

Scilab/Scicos an Linux RTAI

[11] Florez, J., Y.F., Cabezas y E. Diaz (2008). Simulacion y control PI de una planta

RC en Tiempo Real con RTAI-Lab. $to IEEE Workshop Colombiano en Robotica

y Automatizacion – CWRA 2008



[13] Luisa Fernanda Pineda, René Valverde, Yamir Hernando Bolaños. Guia para la

instalación de Knoppix 5 con RTAI.

[14] Joäo Monteiro. RTAI Installation Complete Guide 2008

[15] Pedro Henrique Santana, Glauco Garcia Scandaroli, Felipe Brandäo Cavalcanti,

Geovany Araújo Borges. How to install an RTAI extensión in Linux 2.6.24

Kernel


Bibliografía

- 90 -



[17] http://www.linuxforums.org/

[18] http://ubuntuforums.org/





[23] Ramon Rodriguez Pecharroman, Juan Luis Zamora Macho, Adolfo Anta

Martinez, Manual de referencia de MATLAB&SIMULINK. E.T.S.I. ICAI

Departamento de Electronica y Automatica

[24] Utiles de Simulink

http://sifo.upcomillas.es/pluginfile.php/196925/mod_folder/content/0/LabCD.zip

?forcedownload=1

[25] Laboratorio de Control Digital de ICAI

http://sifo.upcomillas.es/pluginfile.php/196927/mod_resource/content/2/Laborato

rio%20de%20Control%20Digital.pdf

[26] Backups http://www.dea.icai.upcomillas.es/romano/linux/tricks.html

Bibliografía

- 91 -



Parte II ESTUDIO

ECONÓMICO

Bibliografía

- 92 -



Estudio económico

- 93 -



Capítulo 1 ESTUDIO ECONÓMICO

En el presenta capitulo se recogen los costes de los equipos informáticos

utilizados, así como la mano de obra imputable.

� Hardware y Software

Descripción Cantidad Horas de Proyecto Horas de uso al año

Ordenador

OptiPlex GX-280

1 400 1500

Sistema de

control de

velocidad del

motor

1

30

500

Microsoft Office

2013

1 80 600

Sony Tablet S 1 450 1500

DAQ PCI-6013 1 400 1500

MatLAB/Simulink 1 30 500

Scicos 1 20 20

Estudio económico

- 94 -



� Mano de obra

Actividad Horas

Recopilación de información 80

Compilación Kernel-RTAI 150

Drivers de Comedi 90

Depuración de errores 40

Simulaciones en Simulink 20

Ensayos 20

Documentación del proyecto 50

Horas totales 450

Costes unitarios

- 95 -



Capítulo 2 COSTES UNITARIOS

A continuación se enumeran los precios unitarios de los componentes

utilizados para la realización del proyecto.

� Equipos y software

Elemento Precio (euros/ud.)

Ordenador OptiPlex GX-280 2.000,00

Sistema de control de

velocidad del motor

200,00

Microsoft Office 2013 140,00

Sony Tablet S 300,00

DAQ PCI-6013 690,00

MatLAB/Simulink 500,00

Scicos Software Libre

Costes unitarios

- 96 -



� Mano de obra

Actividad Precio (euros/h)

Recopilación de información 5

Compilación Kernel-RTAI 10

Drivers de Comedi 10

Depuración de errores 15

Simulaciones en Simulink 10

Ensayos 5

Documentación del proyecto 5

Sumas parciales

- 97 -



Capítulo 3 SUMAS PARCIALES

En el presente capitulo se asignan los importes de cada una de las actividades y

recursos, en referencia a su uso y amortización.

� Hardware y software

Descripción Ud Horas de

Proyecto

Horas de

uso al año

Precio

(€/ud.)

Amortización

anual

Coste

(€)

Ordenador OptiPlex

GX-280

1

400

1500

2.000,00

25%

133,33

Sistema de control de

velocidad del motor

1

30

500

200,00

25%

3,00

Microsoft Office 2013 1 80 600 140,00 25% 4,67

Sony Tablet S 1 450 1500 300,00 25% 22,50

DAQ PCI-6013 1 400 1500 690,00 25% 74,75

MatLAB/Simulink 1 30 500 500,00 25% 7,50

Scicos 1 20 20 Software

Libre

� 0,00

TOTAL 245,75

Sumas parciales

- 98 -



� Mano de obra

Actividad Horas Precio

(euros/h)

Coste Total

(euros)

Recopilación de

información

80 5 400,00

Compilación Kernel-RTAI 150 10 1.500,00

Drivers de Comedi 90 10 900,00

Depuración de errores 40 15 600,00

Simulaciones en Simulink 20 10 200,00

Ensayos 20 5 100,00

Documentación del

proyecto

50 5 250,00

Horas totales 450 3.950,00

Presupuesto general

- 99 -



Capítulo 4 PRESUPUESTO GENERAL

Contabilizando los costes de los anteriores capítulos, se concluye que el

presupuesto por el proyecto es el siguiente:

Concepto Coste (euros)

Hardware y Software 245,75

Mano de obra 3.950,00

TOTAL 4.195,75

Presupuesto general

- 100 -



Presupuesto general

- 101 -



Parte III MANUAL DE

USUARIO

Presupuesto general

- 102 -



Manual de usuario 1

- 103 -



Capítulo 1 MANUAL DE USUARIO 1

En este capítulo se darán algunas pautas de instalación y configuración del

SOTR [14]. En primer lugar hay que destacar que como ya se introdujo al

comienzo de los primeros capítulos, el sistema operativo a utilizar debe ser Linux.

� Preparando la instalación:

Se debe descargar una versión no modificada (o “vanila”) de Linux que a su

vez sea compatible con el parcheo de RTAI. La versión 2.6.24 es de las últimas

versiones estables y sobre la que se basa este proyecto. Para descargarla puede

visitarse el index de http://www.kernel.org y descargarse la citada versión. Si por

el contrario se opta por alguna otra versión, se deberá comprobar la existencia de

su respectivo RTAI-patch.

A continuación se debe descargar el paquete 3.6 RTAI de la página web

http://www.rtai.org (rtai-3.6-cv.tar.bz2)

Una vez descargados ambos ficheros, es necesario descomprimirlos en la

carpeta de sistema /usr/src con licencia de superusuario. Para ello pueden seguirse

las siguientes líneas de código en la ventana de comandos:

$ sudo su # cp rtai-3.6-cv.tar.bz2 /usr/src # cp linux-2.6.24.tar.bz2 /usr/src # cd /usr/src # tar xfj rtai-3.6-cv.tar.bz2 # tar xfj linux-2.6.24.tar.bz2

# mv linux-2.6.24 linux-2.6.24-rtai

Manual de usuario 1

- 104 -



� Linux-kernel

Una vez descomprimidos ambos paquetes en la citada carpeta de sistema, se

crearan los siguientes links a los archivos, para facilitar el proceso de instalación.

# cd /usr/src # ln -s linux-2.6.24-rtai linux # cd /usr/src # mkdir modules # cd modules

# ln -s ../rtai-3.6-cv rtai

Para continuar con la instalación se recomienda (si no se posee) la

instalación de las siguientes librerías haciendo uso del comando apt-get install

# apt-get install gcc-3.4 g++-3.4 make

# apt-get install libncurses5-dev

# apt-get install module-init-tools

� Parchear con RTAI

Antes de comenzar el compilado del kernel, es necesario parchear el mismo.

Es por ello que se requiere una versión ‘vanilla’ del kernel. Para ello, se

introducirán las siguientes instrucciones en la ventana de comandos (como

superusuario):

# cd /usr/src/linux-2.6.19

# patch -p1 -b < ../rtai-3.5/base/arch/i386/patches/hal-linux-2.6.19-i386-1.7-01.patch

� Configurar el Kernel

Esta es una tarea compleja y que requiere de un cierto grado de conocimiento

del equipo, para su correcta implementación. Es por ello que lo primero será hacer

una copia de la configuración del kernel actual, la cual será parcialmente

modificada para el propósito de RTAI.

# cd /usr/src/linux-2.6.19

# cp /boot/config-2.6.19-generic .config

# make menuconfig CC=/usr/bin/gcc-3.4 CXX=/usr/bin/g++-3.4

Manual de usuario 1

- 105 -



Si todo fue correctamente, se deberá haber accedido a una nueva ventana

de configuración en la que lo primero se deberá cargar el archive .config en la

opción ‘Load an Alternate Configuration File’. Una vez realizado, se procederá a

configurar el resto de elementos tal y como sigue a continuación:

_ Code maturity level options -> Nothing selected

_ General Setup -> [*] Support for paging of anonymous memory (swap) [*] System V IPC { Allows Inter Process Communication. [*] BSD Process Accounting { Allows to obtain user application information's.

_ Loadable Module Support -> [*] Enable loadable module support [*] Module unloading. [*] Source checksum for all modules. [*] Automatic Kernel module loading .

_ Block Layer -> Nothing selected

_ Processor type and features -> [*] Generic x86 support [*] Preempt The Big Kernel Lock [*] Interrupt pipeline [ ] Local APIC support on uni processors [*] Math [*] MTRR support [ ] Use register arguments [*] Compact VDSO support

_ Power management options -> [*] Legacy Management Debug Support ACPI Support >

[*] ACPI Support [M] Button [M] Video [M] Fan [M] Processor [M] Thermal Zone

CPU Frequency Scaling {> [*] CPU Frequency scaling [*] Relaxed speedstep capability checks

_ Bus options -> [*] PCI Support

_ Executable _le formats -> [*] Kernel support for ELD binaries

_ Networking -> Networking Options {>

[*] Packet socket: mapped IO [*] Unix domain sockets [*] TCP/IP networking [*] Network packet _ltering [*]QoS and/or fair queueing

_ Device Drivers -> Generic Driver Options >

[*] Prevent _rmware from being built.

Manual de usuario 1

- 106 -



[*] User space _rmware loading support. Memory Technology Devices (MTD) {>

[*] Write support for NFTL. Plug and Play support {>

[*] Plug and Play support. _ Kernel Hacking ->

[ ] Compile the kernel with frame pointers

� Compilación del kernel

Después de haber configurado el kernel la manera más fácil de compilar la nueva versión, ya parcheada, es crear un archivo .deb Por ello se deben descargar los siguientes paquetes: # apt-get install kernel-package fakeroot

Y para compilar el kernel, proceso que dura aproximadamente 2 horas, se deben introducir las siguientes instrucciones: # make-kpkg clean # fakeroot make-kpkg --initrd --app\end-to-version=-rtai \kernel_image kernel\_headers # cd /usr/src # dpkg -i *.deb

Si todo fue correctamente, el sistema deberá reiniciarse con el nuevo kernel y seguidamente se procederá a configurar RTAI.

� Configuración de RTAI $ sudo -s # cd /usr/src/rtai-3.5 # mkdir build # cd build # make -f ../makefile CC=/usr/bin/gcc-3.4 CXX=/usr/bin/g++-3.4.

En la ventana de configuración deberán dejarse todos los parámetros como están, y verificar los siguientes: General -> Installation directory { Leave the default as /usr/realtime General -> Linux Build Tree { The path to the configured kernel /usr/src/linux-2.6.9 # make install

Documents

SISTEMA PARA DISEÑO, SIMULACIÓN E …configuración de los sistemas operativos que los ejecutan, estas tareas no tienen por qué suponer una alta prioridad para el sistema, por lo