UNIVERSIDAD AUTÓNOMA METROPOLITANAnewton.azc.uam.mx/mcc/02_ingles/11_tesis/tesis/... ·...

UNIVERSIDAD AUTÓNOMA

METROPOLITANA

“Algoritmo de Planificación en un Sistema de Control Distribuido basado en una Arquitectura Multi-agente en Tiempo Real”

TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA:

Tzitziki Ramírez González

Asesores:

Dra. Ana Lilia Laureano Cruces Departamento de Sistemas Universidad Autónoma Metropolitana Azcapotzalco

Dr. Héctor Benítez Pérez Departamento de Ingeniería en Sistemas Computacionales y Automatización Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas Universidad Nacional Autónoma de México

Diciembre de 2006

Dedico esta tesis, A Natalia, dulce fuente de inspiración, quien me impulsó en cada momento a lograr una meta cada día. A Abel, mi amado esposo, por su inmenso apoyo y por reforzar en mi, día a día, el deseo de ver culminado este trabajo. A mi linda Madre, por sus consejos, apoyo, ánimos y disponibilidad en cada momento. A Reyna y Paulina, quienes son una motivación para emprender un nuevo reto en la vida.

Y agradezco, A la Dra. Ana Lilia Laureano Cruces por su apoyo y entusiasmo en cada una de las fases del presente trabajo. Al Dr. Héctor Benítez Pérez por su disponibilidad, entusiasmo y apoyo en todo momento, y por siempre anteponer ante cualquier circunstancia su lado humano.

RESUMEN La problemática de garantizar que un sistema distribuido en tiempo real sea tolerante a fallas, es decir que permanezca funcionando inclusive si se presenta una falla, es lo que inspira y da origen a un planificador dinámico, que permite realizar la planificación de tareas de en tiempo de ejecución dentro de un ancho de banda específico, teniendo así, un abanico de opciones en las cuales se puede transmitir la información de acuerdo a las necesidades del sistema en un instante de tiempo determinado. Mejorando de esta manera, la idea de un planificador estático en el cual se encuentran ya predefinidas las asignaciones de la frecuencia de transmisión para cada tarea y si llegase a ocurrir alguna falla, simplemente se dejaría de transmitir la información. La aproximación que se describe a lo largo de ésta tesis consiste en un sistema multi-agente adaptable al entorno, el cual permite que los agentes reaccionen ante los constantes cambios que produce el sistema dinámico en el que se encuentran inmersos, para lograr esto, se apoyan en una arquitectura de pizarra, la cual contempla la comunicación entre agentes precisamente a través de la información que se encuentra dentro de ella misma. Las arquitecturas multi-agente y de pizarra permiten hacer un mapeo de los diferentes componentes lógicos a un sistema distribuido físico, dada la capacidad de encapsulamiento de los agentes y la comunicación por medio de mensajes ente ellos mismos (la comunicación que puede ser vista como mensajes de un procesador a otro). En el caso de la pizarra, es una estructura de datos con información que se refleja en espejo en cada procesador del sistema distribuido en donde se encuentra alojado cada agente, actualizándose por medio de la comunicación vía mensajes entre los agentes. El caso de estudio al que se aplica ésta aproximación es una planta de levitación magnética, en dónde el sistema de control se encuentra distribuido en tres fases, 1) el sensado, 2) la elección de la ley de control que es utilizada por medio de un algoritmo llamado Takagi Sugeno y 3) la interfaz con la planta, en donde mediante actuadores se realiza la reconfiguración del sistema. Haciendo uso de la S-Function (herramienta de Simulink MATLAB 7.0) se obtiene la clave para lograr la implementación del sistema multi-agente y de pizarra usando XPC Target 2.6 (kernel que permite ejecutar en tiempo real un diagrama realizado en Simulink) ya que permite realizar la programación en lenguaje C.

i

ÍNDICE GENERAL Índice de figuras Índice de tablas I INTRODUCCION 1.1 Problema .......................................................................................................................1 1.2 Contextualización ..........................................................................................................2 1.3 Tecnología ....................................................................................................................2 1.4 Objetivos........................................................................................................................3 1.5 Estructura de la Tesis....................................................................................................3 II ANTECEDENTES 2.1 Sistemas de Tiempo Real .............................................................................................5 2.2 Sistemas de Control ......................................................................................................7 2.3 Sistemas Multi-agente...................................................................................................8 2.4 Las Arquitecturas Multi-Agente, Software Colaborativo .............................................10 2.5 Arquitectura de Pizarra................................................................................................12 2.6 Resumen .....................................................................................................................15 III ALGORITMO 3.1 Análisis Conductual.....................................................................................................16 3.1.1 Definiciones..............................................................................................................16 3.1.2 Características de un agente ...................................................................................16 3.2 Algoritmo ....................................................................................................................18 3.2.1. Atributos del Agente Scheduler...............................................................................20 3.2.2 Métodos del Agente Scheduler ................................................................................21 3.2.3 Métodos del Agente Transmition .............................................................................24 3.2.4 Procesos del Algoritmo ............................................................................................25 3.3 Experimentos con el Planificador Dinámico................................................................28 3.3.1 Fase I – Tareas factibles de ser planificadas...........................................................28 3.3.2 Fase II - Planificación dinámica de tareas en ancho de banda ..............................30 3.3.3 Fase III - Planificación dinámica de tareas en ancho de banda con tolerancia a fallas. ....................................................................................................32 3.4 Resumen .....................................................................................................................33 IV CASO DE ESTUDIO 4.1 Introducción.................................................................................................................34 4.2 Levitador Magnético ....................................................................................................34 4.3 Sistema de Control .....................................................................................................36 4.4 Red tipo CAN- Ethernet...............................................................................................41 4.5 Incorporación del Planificador Dinámico al Caso de Estudio .....................................43 4.5.1. S-Function ..............................................................................................................45 4.5.2 El Sistema Distribuido ..............................................................................................48 4.6 Resumen .....................................................................................................................49

ii

V RESULTADOS 5.1 Introducción.................................................................................................................51 5.2 Escenario Libre de Fallas............................................................................................51 5.3 Escenarios con manejo de fallas ................................................................................53 5.3.1 Manejo de fallas con asignación de frecuencias constante.....................................54 5.3.2 Manejo de fallas manteniendo la frecuencia asignada ............................................60 5.4 Resumen .....................................................................................................................64 VI CONCLUSIONES .........................................................................................................65 APENDICE A ....................................................................................................................68 APENDICE B.....................................................................................................................75

iii

ÍNDICE DE FIGURAS Fig. II.1. Distintas arquitecturas con agentes colaborativos..............................................14 Fig. III.1 Comunicación entre agentes ..............................................................................18 Fig. III.2 Asignación de Frecuencias .................................................................................29 Fig. III.3 Tiempos en la asignación de frecuencias...........................................................29 Fig. III.4 Asignación de frecuencias (Escenario 2)............................................................30 Fig. III.5 Tiempos en la asignación de frecuencias (Escenario 2) ....................................30 Fig. III.6 Asignación de frecuencias (Escenario 3)............................................................32 Fig. III.7 Tiempos en la asignación de frecuencias (Escenario 3) ....................................32 Fig. IV.1 Levitador Magnético............................................................................................35 Fig. IV.2 Integración del caso de estudio a la red de computadoras ................................36 Fig. IV.3 Escenario libre de fallas......................................................................................37 Fig. IV.4 Escenario con fallas............................................................................................37 Fig. IV.5 Integración de la Ley de Control a la Planta.......................................................39 Fig. IV.6 Sistema de lazo cerrado .....................................................................................40 Fig. IV.7 Diagrama simple de una transmisión mediante CANBus en Simulik.................42 Fig. IV.8 Diagrama simple de comunicación vía Ethernet en Simulink.............................42 Fig. IV.9 Implementación de la planta...............................................................................43 Fig. IV.10 Asignación de frecuencias ...............................................................................44 Fig. IV.11 Bloque S-Funtion ..............................................................................................45 Fig. IV.12 Parámetros de la S-funtion ..............................................................................46 Fig. IV.13 Estructura de una S-Funtion.............................................................................46 Fig. IV.13 Diagrama de la S-Function ..............................................................................48 Fig. V.1 Respuesta del error modificando la frecuencia de transmisiónde tres tareas. Libre de falllas .................................................................................................................................52 Fig. V.2 Respuesta de las tareas. Libre de fallas..............................................................53 Fig. V.3 Respuesta del error ante cambios constantes de frecuencia en el período de planificación y poca presencia de fallas............................................................................56 Fig. V.4 Respuesta de las tareas ante cambios constantes de frecuencia en el período de planificación y poca presencia de fallas............................................................................57 Fig. V.5 Respuesta del error ante cambios constantes de frecuencia en el período de planificación con presencia constante de fallas ................................................................58 Fig. V.6 Respuesta de las tareas ante cambios constantes de frecuencia en el período de planificación con presencia constante de fallas ................................................................58 Fig. V.7 Respuesta de error. Escenario híbrido................................................................59 Fig. V.8 Respuesta del error manteniendo la frecuencia en el período de planificación y poca presencia de fallas ............................................................................................................60 Fig. V.9 Respuesta de las tareas manteniendo la frecuencia en el período de planificación y poca presencia de fallas....................................................................................................61 Fig. V.10 Respuesta del error manteniendo la frecuencia en el período de planificación con presencia constante de fallas............................................................................................62 Fig. V.11 Respuesta de las tareas manteniendo la frecuencia en el período de planificación con presencia constante de fallas............................................................................................63

iv

ÍNDICE DE TABLAS Tabla. III.1 Frequency .......................................................................................................21 Tabla. III.2 Priorities ..........................................................................................................21 Tabla. III.3 Frequency. Escenario 1 ..................................................................................28 Tabla. III.4 Priorities. Escenario 1 .....................................................................................28 Tabla. III.5 Frequency. Escenario 2 ..................................................................................29 Tabla. III.6 Priorities. Escenario 2 .....................................................................................30 Tabla. III.7 Frequency. Escenario 3 ..................................................................................31 Tabla. III.8 Priorities. Escenario 3 .....................................................................................31 Tabla. IV.1 Retardos de tiempo en comunicaciones locales ............................................39 Tabla. IV.2 Valores de KP y KI para el controlador ...............................................39 Tabla. IV.3 Protocolos de recepción y transmisión ................................................43

v

CAPÍTULO I___ Introducción

Pág. 1

INTRODUCCION 1.1 Problema Un Sistema de Control Distribuido debe ejecutar sus tareas en un momento específico, para esto hace uso de un algoritmo denominado Planificador, el cual organiza las tareas en el tiempo y garantiza una buena operación del Sistema. Pero algunas veces factores externos modifican esta operación en la etapa de comunicación, así una manera de garantizar que la información llegue a su destino en el momento indicado es haciendo que el sistema sea tolerante a fallas, y pueda transmitir la tarea ya sea más rápido o más lento dependiendo del factor que esté motivando este cambio. Este trabajo se enfoca en realizar la planificación de manera dinámica para que la información pueda ser transmitida a diferentes frecuencias, acotándolas en un rango; es decir, evitar una planificación estática o predefinida de transmisión, y permitir que para cada tarea se seleccione una frecuencia tomando en cuenta varias restricciones: el ancho de banda y la disponibilidad de frecuencias en el que puede ser transmitida, todo esto en tiempo de ejecución. Este trabajo plantea una arquitectura híbrida (arquitectura de pizarra y agentes reactivos) para dar una solución al problema de comunicación en un sistema distribuido, tomando en cuenta las características del problema donde se requiere de autonomía, la cual se logra a través de compartir un conjunto de datos, los que permiten el disparo de las distintas acciones que realizan los módulos (agentes) y actúan de forma distribuida, comunicándose a través de mensajes. El sistema Distribuido tiene varios procesadores trabajando de forma local, cada uno realiza un trabajo específico dentro del sistema y la colaboración entre ellos permite que el funcionamiento del sistema en su totalidad se lleve acabo adecuadamente. En este caso cada agente es parte de cada una de estas segmentaciones, y la coordinación entre ellos permite que la planificación de tareas a transmitir se distribuya en los anchos de banda en que operan cada uno de ellos. En este sistema el uso de una arquitectura de pizarra se vuelve factible, donde los procesadores se comunican de forma indirecta y anónima a través de un recolector de datos por medio de mensajes. Este acercamiento permite múltiples caminos para la elección de la vía más prometedora que lleve a la solución del problema. La pizarra usada en este sistema es una tabla organizada en dos secciones, el ancho de banda y las prioridades, en la cual se refleja que tareas están siendo transmitidas, a qué velocidad y en que rango puede oscilar su transmisión.


Pág. 2

En el caso de las arquitecturas multi-agente la contribución más fuerte es la característica reactiva y autónoma, misma que se convierte en un control descentralizado, contra el control centralizado de la arquitectura de pizarra. 1.2 Contextualización El origen del planificador dinámico para la transmisión de tareas en diferentes frecuencias (dentro del ancho de banda de cada procesador de un sistema distribuido), surge de los sistemas tolerantes a fallas, ya que, si se produce una falla se debe garantizar que la transmisión de la información se lleve acabo utilizando cualquier frecuencia de su ancho de banda. De otra manera, en el caso de una planificación estática, se asigna una frecuencia para cada tarea, previa al proceso de planificación, si ocurre una falla, la tarea no es transmitida dado que solo puede transmitir por una frecuencia determinada. Por lo cual el planificador dinámico es más flexible ya que si se da una falla puede elegir entre diferentes opciones para transmitirla. Ahora bien, de acuerdo a la naturaleza del sistema de control, el cual se encuentra en un ambiente dinámico, es que se considera la aplicación de agentes reactivos, una de sus características principales es la de responder ante los constantes cambios del entorno mediante las percepciones que tienen del mismo [3]. Dichas percepciones, están reflejadas en una arquitectura de pizarra, es decir, existe un recolector de datos que describe el estado en el cual se encuentra el sistema en un momento determinado. El sistema de control que se tiene como base, para incorporar la etapa reactiva se encuentra distribuido en tres etapas, la obtención de los datos y análisis de los mismos, la selección de una ley de control que se aplique dado el resultado del análisis, el uso de la ley seleccionada y análisis del error del sistema dinámico. 1.3 Tecnología La tecnología utilizada es XPC Target versión 2.6, al cual da una solución para crear, probar y desarrollar Sistemas de tiempo real usando hardware de PC estándar. En este entorno se permite utilizar una PC host con MATLAB versión 7.0 y con simulink para crear un modelo y después correr simulaciones que nos permitan observar el comportamiento del sistema, cabe mencionar que la simulación no se da en tiempo real. Para la implementación de los agentes se hace uso de un bloque de Simulink llamado S-Function, que nos permite realizar una programación en C, C++, ADA y


Pág. 3

Fortran, una vez escrito el programa se utiliza un compilador eligiendo el lenguaje utilizado para generar el código ejecutable, el cuál se baja de la PC Host a una PC Target ejecutando el kernel de tiempo real de XPC Target. Una vez hecho esto podemos ejecutar y probar la aplicación objetivo en tiempo real. Es importante hacer notar que no se pueden realizar programas en C++ y correrlos bajo la plataforma de XPC Target, ya que este último no lo soporta. Por lo que para el desarrollo de éste trabajo se utilizó lenguaje C acoplando la estructura de los programas al comportamiento de un agente, cuyo diseño se basó en un análisis conductual [23]. 1.4 Objetivos

• Estudio de la garantía del tiempo real en la transmisión de información en un sistema distribuido dinámico.

• Definir la planificación en tiempo de ejecución mediante agentes reactivos para generar un planificador dinámico.

• Analizar la respuesta del sistema con base en el proceso de monitoreo del error en un caso de estudio.

• Usando distintos anchos de banda para distintos elementos de cómputo garantizar la transmisión entre tareas y agentes.

1.5 Estructura de la Tesis En el Capítulo 2 se revisan conceptos básicos de los sistemas de tiempo real, la importancia de la Inteligencia Artificial Distribuida y en particular de los Sistemas Multi-agente y la Arquitectura de Pizarra. El Capítulo 3 expone el algoritmo de planificación dinámica, el análisis conductual del sistema y la arquitectura de pizarra utilizada. El Capítulo 4 muestra el caso de estudio en el que se encuentra operando el sistema de control y la incorporación de la etapa reactiva utilizando agentes reactivos basados en una arquitectura de pizarra. Así como también se revisa la red tipo CAN/Ethernet. El capítulo 5 muestra los resultados de la evaluación del error y el desempeño del sistema de control utilizando el planificador dinámico. El Capítulo 6 muestra las conclusiones que resultan del análisis del sistema y del uso de la arquitectura híbrida que se plantea en este trabajo.


Pág. 4

El Apéndice A contiene los programas de la S-Function, los métodos utilizados por cada agente y las funciones de apoyo para que los agentes realicen sus acciones. El Apéndice B muestra los diagramas elaborados en Simulink, del sistema de control y la arquitectura multi-agente integrada a la planta. Referencias en las que se basa esta investigación.

CAPÍTULO II__________________________________Antecedentes

Pág.5

ANTECEDENTES 2.1 Sistemas de Tiempo Real “Un sistema de tiempo real es aquel que de acuerdo a las restricciones temporales realiza su trabajo de forma determinística“ [9] En los sistemas de tiempo real se hace énfasis no solo en los datos que se producen al ejecutarse el sistema son también en el momento específico en el que se generan. Para comprender mejor la forma en la que opera un sistema de tiempo real se presentan a continuación los siguientes conceptos: Cada unidad de trabajo que es planificada y ejecutada en un sistema se denomina trabajo (job), y al conjunto de trabajos que de forma conjunta realizan una función del sistema se les denomina tarea. El instante de tiempo en el que un trabajo se ejecuta se le llama Release Time. Por otro lado al instante de tiempo en el que un trabajo debe concluir, o ser completado se le denomina tiempo límite (deadline). Los deadlines pueden ser duros o suaves y esto depende del efecto que produzca al no completarse la ejecución de una tarea, si produce una falla fatal o consecuencias desastrozas se dice que es un deadline duro, si el impacto no es fatal se le denomina deadline suave. Si se tiene un proceso que requiere ejecutar un conjunto de tareas las cuales requerimos planificar, se debe tomar en cuenta que la suma de los tiempos que consumen cada una de ellas debe ser menor al tiempo especificado para ejecutar el proceso. Si las tareas cumplen con esta condición se dice que son factibles de ser planificados. Dicho de otra manera, tomando en cuenta dos parámetros de una tarea Ti, el periodo Pi y un tiempo de proceso Ci, donde 0<Ci<Pi . Se define un parámetro de utilización U=Ci/Pi , éste parámetro nos indica la fracción de tiempo que se invierte en la ejecución de Ti , así, si se tiene un conjunto de tareas la suma del factor de utilización de cada una de ellas debe ser menor a uno, o lo que es lo mismo al tiempo destinado para la ejecución de la tarea especificado por un deadline. De otra manera la tarea quedaría inconclusa con trabajos pendientes. Ver la ecuación 1. m

∑ U=Ci/Pi < 1 (1) i=1


Pág.6

Un sistema de tempo real duro es aquel en el que todas las tareas a planificar son críticas, es decir, tienen un deadline duro. Por otro lado un sistema de tiempo real suave es aquel en el cual puede haber tareas que no son críticas. Un sistema de tiempo real distribuido es aquel cuyos componentes ya sea de hardware o software, están localizados en computadoras en red que se comunican coordinando sus acciones solo por el paso de mensajes[8]. Cada nodo se divide en dos partes, la interfaz de comunicación, que es la que se encarga de transmitir los mensajes entre nodos y el kernel de la computadora, quien se encarga de los procesos del sistema. Cuando se tiene un sistema de tiempo real distribuido, hay que tener en cuenta que debido a la demanda, el sistema de transmisión puede saturarse, por lo que el retraso de tiempo que se produce puede manejarse definiendo un límite de retraso que nos garantice la entrega de mensajes. Trabajos Relacionados En [15] se muestra un algoritmo que permite hacer el cambio en línea de un controlador1 a otro en un sistema de control en tiempo real, donde cada uno de ellos opera con su propia tasa de muestreo, el primero es determinado mediante reglas usuales, y el segundo es basado en tasas bajas las cuales son usadas cuando el sistema está operando cerca del estado estacionario, lo cual de manera física representa liberar recursos del sistema que pueden ser utilizados para otros propósitos, por ejemplo, la ejecución de más tareas, la transmisión de más mensajes en un caso distribuido o incluso ahorrar energía reduciendo la velocidad del CPU o el número de transmisiones. Cabe mencionar que cuando se realiza el cambio de controlador de la tasa nominal a la tasa baja de muestreo no se produce inestabilidad ya que esto ocurre cuando el sistema está cerca de un estado estacionario. En [16] se presenta un método para permitir mayor flexibilidad en la planificación de mensajes en el bus en situaciones de sobrecarga del mismo. El método propone una adaptación en línea del período de muestreo para la carga del bus, tratando que permanezca con los valores más bajos cuando hay sobre cargas, es decir se selecciona un período de muestreo en tiempo de ejecución según convenga. Para asegurar la solución, se implementó un sistema de control adaptable distribuido (en True Time de MATLAB) usando el protocolo FTT-CAN [14], donde las propiedades de los mensajes incluyen un rango de aceptación de calidad del servicio (QoS), para la infraestructura de comunicación un controlador poste-colocación (pole-placement) y un modelo para la identificación de los

1 El controlador es quién ejecuta la ley de control que lleva a un estado de estabilidad al sistema.


Pág.7

parámetros de la planta. Los resultados muestran que solamente hay una pequeña pérdida en el desempeño de control. El protocolo FTT-CAN (Flexible Time-Triggered comunication on Controller Area Network) [14], [16] permite flexibilidad, puntualidad y se basa en una combinación eficiente entre la comunicación disparada por tiempo (Time-Triggered co) y el tráfico de eventos-disparados (event-triggered). Cuando se usa este protocolo el bus es particionado en ciclos elementales (Ecs, Elementary Cicles) con una duración fija. Los nodos son sincronizados al principio de cada elementary cicle (EC) mediante la recepción de un mensaje llamado mensaje de disparo (triggerd message / TM) enviado por el nodo maestro, cada EC es dividido en dos ventanas consecutivas uno para el evento lanzado y otro para el tráfico de tiempo disparado. El TM contiene información acerca de los mensajes que hay para ser producidos en un CE específico. Cada nodo el la red tiene un decodificador de TM y produce los mensajes cuando son requeridos. El protocolo FTT-CAN puede incluir un administrador de calidad en el servicio (Quality-of-Servise, QoS). En la comunicación disparada por tiempo se tiene un control total del entorno por lo que se puede forzar a que la comunicación ocurra en un instante predefinido de tiempo a una velocidad determinada, mientras que si se hace por eventos, por naturaleza estos pueden ocurrir en cualquier momento, siendo el peor de los casos, que ocurran varios de forma simultanea, por lo que tendría que existir un mecanismo que permitiera resolver este tipo de conflictos. 2.2 Sistemas de Control En un sistema de control cuando se tienen diferentes tareas que realizar y organizar en el tiempo de acuerdo a un conjunto de restricciones, para su ejecución, debemos recurrir a un algoritmo conocido con el nombre de planificador. Un planificador dinámico ordena las tareas en tiempo de ejecución, son flexibles y adaptables a diferentes escenarios, requieren una gran demanda de operaciones en el procesador y consumen poca memoria. En cambio los planificadores estáticos son más rápidos y consumen más memoria. Trabajos Relacionados El trabajo de tesis “un método de planificación para reconfiguración en línea de un sistema de tiempo real” [8], provee un método heurístico que obtiene los parámetros adecuados de las tareas de tiempo real, generando un conjunto de


Pág.8

soluciones candidatas para realizar la planificación, en sistemas de computo distribuidos en tiempo real. El método se divide en dos partes, una fuera de línea que genera una tabla (estática) de soluciones variables obtenidas de la planificación de tareas y de la respuesta dinámica del caso de estudio (conocimiento del sistema computacional de la evolución del estado del objeto controlado). En la segunda, se escoge la configuración más adecuada de la tabla, de acuerdo a los cambios presentados, bajo una reconfiguración en línea[8]. Este trabajo de tesis [8] presentado en el 2003 sería un antecedente directo del proyecto propuesto que es motivo de este documento. En [7] se plantea la integración de elementos periféricos inteligentes como parte de un sistema de control distribuido. Se utiliza la información obtenida por un elemento inteligente dentro de un procedimiento de toma de decisiones. Los elementos periféricos generan una medida llamada valor de confidencia el cual indica como ha sido degradado un elemento debido a la presencia de una falla en el sistema. Esto se basa en un procedimiento de toma de decisiones el cual selecciona la ley de control que puede ser utilizada. Se implementaron tres leyes de control, la primera se basa en un comportamiento predictivo, la segunda, en un controlador derivador integrador proporcional (PID), y la tercera se basa en un valor que estabiliza la operación. El planificador que utiliza es estático y deterministico. Para evaluar el tiempo de respuesta, retardos y deadlines, se simulan los modelos en SIMULINK. Ya que la propuesta involucra una reconfiguración estática determinada cuando el sistema está fuera de línea. 2.3 Sistemas Multi-agente Cuando se realiza un nuevo software se piensa en utilizar estructuras y técnicas que permitan manejar más fácilmente la complejidad, por lo que se descompone el problema en problemas más pequeños que a su vez son divididos en otros más pequeños aún, de ésta manera la solución del problema se descompone en pequeñas soluciones. Los sistemas orientados a agentes son una buena alternativa para desarrollar sistemas de software en general (ya que permiten interactuar con el entorno para la toma de acciones) y sistemas de control en particular (control adaptable [5]). Para esto se requiere descomponer el problema en varios componentes autónomos que puedan actuar e interactuar de forma flexible para lograr sus objetivos (agentes reactivos), los cuales tienen el control de ellos mismos (deben


Pág.9

ser activos) y sobre sus propias acciones (deben ser autónomos). Cualquier coordinación o sincronización requerida es manejada a través de una interacción Inter-agente bottom-up. Los sistemas basados en agentes proporcionan una solución descentralizada basada en vistas parciales y locales que provienen del entorno dinámico y proveen al sistema de un alto grado de flexibilidad además de dotarlo de robustez [10]. Los agentes son entidades identificables con objetivos definidos, situados en un entorno particular. Un agente es un sistema localizado y forma parte de un entorno al cual percibe, y en el cual desarrolla acciones a través del tiempo; lo que permite alcanzar sus objetivos[3]. El comportamiento de un agente reactivo involucra la toma de decisiones en tiempo de ejecución usando información incompleta basada en reglas simples de percepción-acción [5] De acuerdo a Luck y d’Inverno [5] un sistema multi-agente es aquel que: contiene una colección de dos o más agentes. Como los objetivos no pueden existir sin haber sido generados por agentes autónomos, es imposible para los agentes existir sin autonomía en un sistema. Así, la definición de un sistema multi-agente es cualquier sistema que contiene dos o más agentes, al menos un agente autónomo y al menos también, una relación entre dos agentes dónde uno satisfaga los objetivos del otro”. Un sistema multi-agente puede ser diseñado para estar abierto lo que permite que podamos seguir añadiendo agentes, como si fuera un mecanismo plug and play, por lo que su mantenimiento es más sencillo. Trabajos Relacionados En [5], se implementa una decisión experta basada en un simulador de perforación de pozos. El objetivo principal es obtener las temperaturas existentes que permiten establecer el potencial de un pozo geotérmico. Lo anterior se logra con la ayuda de un sistema multi-agente constituido por dos agentes: un autónomo y un no autónomo. A continuación se describe proceso de este sistema multi-agente a través de la descripción de los esquemas de dichos agentes. Agente Adjustment: Es un agente de tipo pasivo y es el encargado de controlar el proceso de convergencia de las temperaturas registradas y simuladas.


Pág.10

Agente TempExist: Este agente es el agente reactivo que esta percibiendo el ambiente y controla a Adjustment. En este caso percibe la diferencia entre las temperaturas registrada y simulada para saber si hay convergencia (están dentro de un rango de error). La convergencia indica que se ha logrado obtener las temperaturas existentes. Estas últimas son importantes por que a través de ellas se pueden detectar propiedades geotérmicas. Otro ejemplo es el sistema desarrollado por Iberdrola (utilidad eléctrica española) [10] para la administración de la transportación de electricidad, establece un proceso de monitorización y controla el transporte de energía eléctrica a clientes industriales y domésticos. El sistema operacional consiste de siete agentes corriendo en cinco máquinas diferentes, cada una de estas estaciones tiene su Unidad de Transmisión Remota (RTU) correspondiente, que envía información al cuarto de control despachador (DCR), ubicado en otra máquina, acerca del estatus de sus componentes eléctricos. En el DCR la información es recolectada y puesta de forma disponible para la cooperación entre agentes a través de las funciones de la interfaz de control. El diseño del sistema asegura que cada tarea identificada en el análisis es realizada por lo menos por un agente. El sistema es tolerante a fallas ya que hay varios agentes que pueden cubrir el objetivo de una misma tarea, por lo que si un agente falla, existe otro que puede producir un resultado bastante aceptable. Sin embargo las condiciones óptimas se dan cuando funciona el sistema completo. 2.4 Las Arquitecturas Multi-Agente, Software Colaborativo De acuerdo con Corkill [15], el paradigma del Software Colaborativo se basa en una aproximación muy conocida, “divide y vencerás”, esto para aplicaciones grandes y complejas que requieren de mantenimiento. El sistema se divide en módulos pequeños y los detalles individuales y la complejidad asociada a cada módulo es encapsulada dentro de él. De ésta forma los cálculos requeridos por las funciones involucradas en los distintos módulos se logra a través de la colaboración entre ellos. La computación industrial se vuelve día con día más compleja y maneja un gran número de subsistemas de distinta naturaleza; que incluyen distintas funciones así como la interacción con distintos especialistas – humanos. Lo anterior implica una distribución física del conocimiento.

Las aplicaciones industriales a gran escala tales como: a) La supervisión de redes (telecomunicación, transporte y distribución de potencia, materiales y productos terminados). b) La supervisión y administración de subsistemas, están naturalmente distribuidas en nodos que conforman una red y que utilizan una gran


Pág.11

cantidad de técnicas y programas que tienen que trabajar de forma conjunta para llevar a cabo el objetivo común; para lograrlo es necesario hacer funcionar al sistema de forma organizada y congruente. Cada persona involucrada cuenta tan sólo con una vista parcial que cubre lo que ella tiene que hacer, con base en sus capacidades, pero todo el sistema reacciona de la forma deseada si todas las acciones son coordinadas de forma eficiente. A continuación se enumeran las necesidades a cubrir por los sistemas distribuidos:

• Los problemas están físicamente distribuidos: con frecuencia la solución de los problemas complejos está físicamente distribuida.

• Los problemas son ampliamente distribuidos y heterogéneos en términos funcionales: nadie puede tener todo el conocimiento acerca de un problema o tener el suficiente conocimiento que se requiere para crear un determinado sistema. Todos estos expertos mezclan su conocimiento para crear el mejor coche posible.

• Redes: en la era interplanetaria, cuando todos los datos y el procesamiento de la mismos esta distribuido en un número considerable de sitios, debemos pensar en sistemas abiertos, esto es, en términos de de la interoperabilidad de los sistemas de cómputo. De aquí que los SMA puedan ser vistos como candidatos serios en la construcción de sistemas con arquitecturas: abiertas, distribuidas, heterogéneas y flexibles, capaces de ofrecer alta calidad de servicios en trabajo colectivo, sin imponer ninguna estructura a priori.

• La complejidad de los problemas exige puntos de vista locales: cuando los problemas son muy extensos para ser analizados como un todo, soluciones basadas en vistas locales con frecuencia permiten resolverlo de forma más rápida. Por ejemplo: control de tráfico aéreo, o el cálculo de temperaturas existentes. El hábito de pensar de forma local inducida por la kinética constituye un aspecto prometedor para resolver los complicados problemas a gran escala. Se hace simple obtener resultados; evitando las dificultades ligadas a la ineficiencia de algoritmos que se pretende funcionen sobre todo el ancho del problema, y al mismo tiempo proporciona resultados comparables que emergen de las interacciones locales.

• Los sistemas deben ser capaces de adaptarse a los cambios estructurales y estar situados en el entrono: ya no es suficiente saber como diseñar de forma eficiente, rentable y exacta sistemas computacionales. Considerando los elementos que aporta la complejidad, es necesario tener en cuenta la forma en que el software pueda adaptarse a los cambios en el contexto de operación ( cambios en el sistema operativo, el manejo de bases de datos, interfaces gráficas, agregar nuevo software). En el contexto de los SMA debido a su inherente naturaleza distribuida. Dado que en ellos se asume que el razonamiento es siempre local y dado que se permite que los agentes


Pág.12

aparezcan y desaparezcan, aún durante la ejecución del sistema. Son arquitecturas especialmente situadas en el entorno que consideran la evolución y adaptación necesaria para el funcionamiento del sistema.

• La ingeniería de software se mueve hacia el diseño y uso de conceptos de unidades autónomas que interactúan: la historia del desarrollo del software muestra una tendencia hacia la construcción de sistemas que se diseñan ensamblando entidades distribuidas y autónomas. La IS esta creando módulos autónomos que pueden interactuar con otros aún cuando sean desarrollados por diferentes personas o equipos. De aquí que se tenga que conjuntar flexibilidad en computación, distribución en los procesos y formas heterogéneas de realización. Los SMA juegan un papel importante al actuar como posibles sucesores de los sistemas orientados a objetos y combinar comportamientos locales con autonomía y toma de decisiones distribuida.

2.5 Arquitectura de Pizarra Un Sistema Multi-agente fuertemente acoplado es aquel que utiliza una memoria compartida para trabajar de forma distribuida. Ahora bien esa distribución puede ser de diferentes formas de acuerdo al tipo de representación de pizarra que se utilice. Corkill [15], proporciona una gama de matices para utilizar arquitecturas multi-agente combinadas con el concepto de pizarra, a continuación se ofrece una breve explicación de ellas. Una forma de combinar un conjunto de diversos módulos de software es conectarlos de acuerdo a los requerimientos de su flujo de datos. Lograr de forma apropiada que los módulos aparezcan varias veces en la gráfica de comunicación implica conexiones predeterminadas y directas. Esta forma de comunicación es una elección correcta cuando tanto el conjunto de módulos como las comunicaciones entre ellos son estáticas. En caso de que la intervención de los módulos este sujeta a cambios y/o cuando el orden de la aparición de los módulos no pueda ser determinado hasta que valores específicos de datos se vuelvan conocidos durante la ejecución, entonces la interacción debe ser a través de protocolos privados de comunicación entre módulos. En este caso el uso de una arquitectura de pizarra se vuelve factible, donde los módulos se comunican de forma indirecta y anónima a través de un recolector de datos.


Pág.13

Una pizarra es entre otras cosas un repositorio de datos en el cual se plasman todos los posibles caminos para llegar a una solución. Estos caminos son seleccionados a través de las competencias de los distintos módulos que concentran de forma independiente fuentes de conocimiento con el fin de encontrar las mejores soluciones. La información que contiene es pública, esto es, se encuentra accesible para cualquier módulo que lo solicite. Los tres componentes de una Arquitectura de Pizarra son:

• La fuente de conocimiento (FC), contiene toda la pericia para poder resolver el problema. Funciona como un par condición - acción; que se activa cuando el estado de la pizarra satisface ciertas condiciones. El resultado es una acción que consiste en: 1) Generación de una nueva hipótesis y/o 2) Modificación de una hipótesis ya existente[3].

• La pizarra, es un repositorio de datos global y contiene los datos de entrada, posibles soluciones, soluciones parciales y / o soluciones finales. En donde cada modificación a la pizarra puede provocar la activación de nuevas FCs. Desencadenándose así un conjunto de actividades asíncronas. Estas actividades son producto de: 1) interpretaciones locales y parciales sobre los datos contenidos en la pizarra.

• El controlador es quién realiza la selección en tiempo de ejecución de la

fuente de conocimiento que va a interactuar, lo que lleva a la solución del problema. Elige la alternativa más prometedora.

Cabe mencionar que toda la interacción entre los FCs se lleva acabo a través de la generación o modificación de hipótesis que se desarrolla en la Pizarra. Si partimos de un sistema multi-agente basado en una arquitectura de pizarra de acuerdo a Corkill [15], podemos contar con distintos tipos de comunicación. Para realizar una comunicación ínter-agente, podemos partir del esquema más básico, es decir podemos mandar mensajes de un agente a todos los demás o a un subconjunto de ellos, y recibir mensajes de todos o solo de algunos de ellos (apoyándose en una pizarra interna), como lo muestra la Fig.II.1 (a). Si a este esquema le agregamos un agente Pizarra, tenemos que los agentes pueden ahora interactuar indirectamente uno con otro vía la pizarra y eliminamos la pizarra interna del esquema anterior, Fig.II.1(b). Teniendo en cuenta que los agentes tienen un control local, podemos hacer que estos lo deleguen al agente Pizarra el cuál ahora se convierte en el administrador de los demás agentes. Fig. II.1(c). La última configuración es similar a la Fig.II.1(a) solo que en esta ocasión se cuenta con una pizarra y una Fuente de conocimiento en cada agente permaneciendo la comunicación inter-agente mediante el envío de mensajes. Fig.II.1 (d).


Pág.14

Agente A

Agente B

Agente D

Agente C

Agente +

Pizarra

b) Interacción Indirecta vía un agente Pizarra

Agente A

Agente B

Agente D

Agente C

Pizarra

Pizarra

Pizarra

Pizarra

a) Interacción Directa

Agente A

Agente B

Agent D

Agente C

Agente Pizarra

+ Control

c) Interacción Indirecta vía un agente Pizarra el cual controla a todos los agentes

Agente A + Pizarra

+ FC

Agente B + Pizarra

+FC

Agente D + Pizarra

+ FC

Agente C + Pizarra

+ FC

d) Distribución Homogénea (Full Fledged)

Fig. II.1. Distintas arquitecturas con agentes colaborativos


Pág.15

2.6 Resumen Como se ha visto a lo largo del capítulo las diferentes ramas de la inteligencia artificial pueden ser aplicadas a muchas de las áreas de otras ciencias. En este caso, en sistemas de control de tiempo real, quienes desde el punto de vista de la Inteligencia Artificial reciben el nombre de control adaptable. Estos sistemas se encuentran inmersos en entornos dinámicos, debido a lo anterior, una arquitectura multi-agente, específicamente con agentes reactivos, puede proporcionar dada su naturaleza un comportamiento que permita lograr nuevos objetivos dentro de la planta2 [23]. Para este trabajo la mejora que se produjo, es el hecho de transformar un planificador estático en un planificador dinámico que permite modificar la frecuencia de transmisión de las tareas dentro de un ancho de banda específico. También se hace una introducción teórica a los términos de relevancia de los sistemas de control, sistemas de tiempo real, inteligencia artificial distribuida, sistemas multi-agente y sistemas de pizarra para comprender mejor las aportaciones que éstas áreas tienen en el desarrollo de sistemas.

2 La planta se encuentra conformada por el sistema distribuido ( obtención de datos por medio de sensores, controlador y

la interfaz que permite mediante actuadores modificar la corriente de la bobina del levitador magnético ) y el sistema de levitación magnética.

CAPÍTULO III _____ ____ __Algoritmo

Pág.16

ALGORITMO 3.1 Análisis Conductual [5] 3.1.1 Definiciones Agente: Los agentes son entidades identificables con objetivos definidos, situados en un entorno particular que perciben de forma constante y sobre el que tienen un control parcial. Agente Autónomo: Es quién constantemente está percibiendo el entorno y que debido a la interacción constante con el entorno dinámico y a sus objetivos internos lo modifica. Este tipo de agente se ayuda de otro no autónomo para lograr sus objetivos. Agente No Autónomo: Una vez tomadas las decisiones por el agente autónomo, éste agente ejecuta las acciones que permiten lograr los objetivos del primero. 3.1.2 Características de un agente Tipo de Objetivo: Son de tipo activo (cuando el agente puede cambiar su entorno, realizando acciones que satisfagan sus objetivos) o pasivo (cuando los objetivos le son impuestos). Objetivo: Es lo que quiere lograr el agente. Acción: Son las intenciones del agente que se ejecutarán dada una función de selección-acción teniendo en cuenta los objetivos, el estado del entorno y las percepciones en un momento dado. Cuando se diseña un agente, varias preguntas surgen, y al contestarlas se obtienen: sus habilidades y la manera en qué las utiliza para percibir su entorno. ¿Acción que percibe? Indica que puede hacer de acuerdo a sus habilidades. ¿Qué puede percibir? Son los atributos que están potencialmente disponibles de acuerdo a sus capacidades preceptúales. ¿Qué percibirá? Son los atributos percibidos en un momento dado, de acuerdo a sus objetivos.


Pág.17

Agente Autónomo

Scheduler

Tipo de Objetivo: activo Objetivo: planifica las tareas en ancho de banda

• Percepciones

1. Acción que percibe: Selecciona una frecuencia

adecuada para la transmisión de una tarea, basado en el registro de frecuencias del ancho de banda disponibles (pizarra).

2. Actualiza su registro (pizarra) de acuerdo a los mensajes provenientes de otros agentes.

3. Modifica la frecuencia para la transmisión de la tarea.

¿Qué puede percibir?: La frecuencia ocupada o disponible, mensajes

para la comunicación Inter-agente, el valor del dato a ser transmitido, prioridades para cada tarea.

¿Qué percibirá?: La frecuencia ocupada o disponible y las

prioridades de cada tarea.

• Acción

Realiza la planificación de tareas para transmitirlas en un ancho de banda específico, seleccionado mediante la revisión de un registro (pizarra), las posibles frecuencias en las que se puede transmitir. Se actualiza revisando el buzón de mensajes, en donde se informa si otro agente está ocupando o liberando una región de ancho de banda. Justo antes de actualizar la pizarra y mandar el mensaje de la frecuencia seleccionada a los demás agentes, vuelve a revisar el buzón para confirmar que la frecuencia seleccionada está disponible.


Agente No Autónomo

Transmition

Tipo de Objetivo: pasivo Objetivo: realiza la transmisión de la tarea en una

frecuencia dentro del ancho de banda designado

• Percepciones

Acción que percibe: Transmite la tarea

¿Qué puede percibir?: La frecuencia en la que se transmitirá

¿Qué percibirá?: La frecuencia en la que se transmitirá • Acción

Transmite las tareas en la frecuencia que decidió el agente autónomo Scheduler .

3.2 Algoritmo El planificador dinámico se basa en una arquitectura multi-agente apoyado en una pizarra en el esquema Distribuido Homogéneo (full- fledged) (Ver. Capítulo II, sección 2.5) para manejar información [15], se eligió ésta configuración debido a que se requiere que los agentes sean independientes en su funcionamiento, esto es que continúen compartiendo la información a pesar de que uno de ellos deje de funcionar. En este caso cada uno cuenta con una pizarra en la escriben con el fin de actualizar los datos utilizados por cada tarea. Cada agente cuenta con una fuente de conocimiento (basadas en sus competencias y vistas locales), que le permite interpretar la información y de acuerdo a sus objetivos ejecutar una acción. Ver Fig. III.1.

Fig. III.1. Comunicación entre agentes

Agent A Agent C

BB

BB

BB

Agent B

Pág.18


Pág.19

Si se tiene un proceso que requiere ejecutar un conjunto de tareas las cuales se requieren planificar, se debe tomar en cuenta que la suma de los tiempos que consumen cada una de ellas debe ser menor al tiempo especificado para ejecutar el proceso. Si las tareas cumplen con esta condición se dice que son factibles de ser planificados. En este caso, como se trata de una planificación en ancho de banda, una tarea es factible de ser planificada si hay una frecuencia adecuada dentro de su ancho de banda1 para garantizar el tiempo en el que debe de ser transmitida (garantizar el tiempo real). El Agente Scheduler dependiendo de las variables que esté manejando en un instante de tiempo (t) puede realizar varias acciones;1) Si es una tarea verifica si tiene mensaje en su buzón, si tiene mensaje entonces 2) selecciona una frecuencia adecuada para transmitirla y 3) envía un mensaje a los demás agentes indicándoles la frecuencia seleccionada. Si es una frecuencia planificable (es decir, adecuado para la transmisión), se modifica la frecuencia (justo antes de modificarla se vuelve a verificar el buzón para garantizar que la frecuencia seleccionada está disponible) y es en este punto donde interactúa con el agente Transmition, el cual recibe la tarea y la frecuencia, la transmite y regresa el control al agente Scheduler en el siguiente instante de tiempo. Visto desde la perspectiva del álgebra de procesos se tiene: Scheduler(t) = tarea, ((Verifica mensaje en el buzón) || (Envía mensaje al buzón) ||

(Selecciona Frecuencia)) ; Scheduler (t) Scheduler(t) = Frecuencia Planificable, (Modifica la Frecuencia);

Transmit(t) Transmit(t) = Tarea, Frecuencia Planificable (Transmite la tarea);

Scheduler(t+1)

1 Ancho de banda es un rango de frecuencias en las cuales las tareas a planificar pueden ser ejecutadas periódicamente


Pág.20

El algoritmo del planificador dinámico2 es: Inicio Se inicializa la pizarra Se obtiene la tarea de la cola de tareas del agente Verifica el estado del sistema Si corresponde el estado del sistema con la falla asignada al agente Se selecciona la frecuencia de la pizarra (contempla el actualizar la pizarra) Si es un proceso factible de ser planificado

Se verifica el buzón para asegurarse de que la frecuencia esté disponible Se notifica a los agentes que la frecuencia seleccionada está siendo ocupada Se modifica la frecuencia de transmisión Fin

Si no es un proceso factible de ser planificado Se obtiene la siguiente tarea de la cola ( segundo paso del

algoritmo) Si no corresponde el estado del sistema con la falla asignada al agente Fin 3.2.1 Atributos del Agente Scheduler En la pizarra del algoritmo se tiene una lista de frecuencias disponibles que están relacionadas con la tarea que está siendo transmitida y por el agente correspondiente. Los atributos de la tabla Frequency son: Frquency, Task y Agent. Si Task es menor a cero indica que está disponible, si no, Task indica que la tarea es asignada a una frecuencia de su ancho de banda. Dentro de la misma pizarra se tiene una tabla de prioridades por tarea, la cual indica las frecuencias mínimas y máximas del ancho de banda. La pizarra se actualiza como resultado de la comunicación entre agentes, de esta manera cada uno de ellos se entera del status de los demás y les informa del suyo. Los atributos de la tabla Piorities son: Task, Port, MinFrc, MaxFrc y duration. Para fines prácticos asumimos que el identificador de la tarea es igual a la prioridad de la tarea, con lo que se evitan redundancias de información. El campo Port de la tabla Priorities indica si es una tarea propia (cuando tiene un número mayor que cero) o si es una tarea de otro agente (cuando es menor que cero). Las frecuencias mínimas y máximas permiten junto con el número de la prioridad ir

2 Ver el apéndice A en donde se encuentra el código fuente de la implementación del planificador dinámico.


seleccionando la frecuencia más adecuada para cada tarea, es decir restringen y acotan el rango de frecuencias en el que puede ser transmitida la tarea. Y para realizar la planificación dinámica el parámetro que indica cuando hay que cambiar la frecuencia de transmisión es la duración. Ver Tablas III.1 y III.2.

Tabla III.1. Frequency.

Frequency Task Agent 2 0 1 5 -1 2 6 1 1 8 -1 3

Tabla1 III.2. Priorities. Task Port Min Frq Max Frq Duration

0 1 7 10 10 1 -1 5 9 20 2 0 1 2 30 3 -1 2 4 40

En la arquitectura multi-agente se parte de la premisa de que deben existir por lo menos, dos agentes uno autónomo y otro no autónomo que le ayude a lograr sus objetivos[5]. En este algoritmo se cuenta con dos agentes, el primero scheduler es autónomo y realiza la planificación en ancho de banda para cada una de las tareas, es decir, asigna una frecuencia específica para su transmisión, esto mediante un análisis de la pizarra. Se comunica con los demás agentes mandando un mensaje al buzón, y actualiza su registro interno consultando si ha recibido algún mensaje en su buzón. Por último modifica la frecuencia en la que se transmite la tarea. El segundo Transmition es de tipo pasivo y ejecuta las decisiones de Scheduler, es decir es el que transmite la tarea en la frecuencia asignada, provocando un cambio en el entorno los cuales se reflejan en las pizarras de cada agente. 3.2.2 Métodos del Agente Scheduler Scheduler selecciona la frecuencia, modifica la frecuencia y se comunica con los demás agentes por medio del envío de mensajes. Todo esto lo realiza a través de cinco métodos:

Pág.21


Selecciona Frecuencia (SelectFrc) Analiza la pizarra para obtener una frecuencia adecuada para transmitir una tarea. Esto depende de la prioridad y del mínimo y máximo del ancho de banda permitido. Visto como álgebra de procesos tenemos: SelectFrc = tarea, (CheckMail, actualiza la pizarra); SelectFrc SelectFrc = Frecuencia planificable, (SendMail); ModifyFrc Si hay una tarea en espera de una frecuencia, se verifica el buzón, se actualiza la pizarra y vuelve al estado SelectFrc, si es una frecuencia planificable, se envía un mensaje a los demás agentes de la región que va a utilizar y se va a ModifyFrc. Entradas: Prioridad de la tarea Salidas: regresa la frecuencia seleccionada o -1 si la tarea no es planificable SelectFrc Frequency PriorityTask Verifica el buzón Actualiza la pizarra con los mensajes que recibió Para cada tarea Localiza la tarea en la tabla de prioridades de la pizarra Si es una tarea propia Para cada frecuencia de la lista Frquency

Si está disponible y es mayor que el min Frq y menor que max Frq Actualiza Task de Frq igual a la tarea

Regresa la frecuencia seleccionada Regresa –1 Modifica Frecuencia (ModifyFrc) Modifica la frecuencia en dónde la tarea debe ser transmitida. Entradas: Tarea Frecuencia Puerto

Pág.22


Y, El instante de tiempo en el que nos encontramos Salidas: Ninguna

ModifyFrc

Task Frquency

PortY None

Duración del pulso igual a 1 (equivale al período del reloj) Durante i veces (este dato depende del numero de veces que aparece en alto la señal, del muestreo y del tiempo que queramos que aparezca) Si Y es igual a la frecuencia por i Transmite la tarea en el puerto deseado Si Y es igual a la frecuencia por i, más la duración del pulso 3Transmite un cero (esto apaga el pulso) Visto como álgebra de procesos se tiene: ModifyFrc = tarea, recuancia (Transmit) ; GetTask Si hay una tarea por transmitir en una frecuencia preseleccionado, se transmite y se revisa si hay otra tarea en espera. Envía mensaje al buzón (SendMail) Envía un mensaje al buzón a través de un puerto específico. Entradas: Mensaje Puerto Salidas: Ninguna

SendMail Msg Port None

Manda el mensaje por el puerto Visto como álgebra de procesos se tiene:

3 En la implementación del caso dee estudio, no se apaga el pulso si que se retiene el dato hasta la siguiente transmisión,

ya que el apagarlo repercute en una inestabilidad del sistema dado que son muy bruscos los cambios desde cero hasta el valor del dato.

Pág.23


SendMail = Msg , (SendMail); ModifyFrc Se envía el mensaje y se va a ModifyFrc Verifica mensaje del buzón (CheckMail) Checa los mensajes del buzón a través de un puerto específico Entradas: Puerto Salidas: Mensaje, si no hay nada regresa cero

CheckMail Mensaje Port

Obtiene el mensaje del puerto Si hay mensaje

Regresa el mensaje Si no hay mensaje Regresa cero Visto como álgebra de procesos se tiene: CheckMail = (CheckMail, actualiza la pizarra); SelectFrc Se revisa el buzón, y se va a SelectFrc 3.2.3 Métodos del Agente Transmition Transmition transmite la tarea por medio del método: Transmite tarea (Transmit) Transmite la tarea a través de un puerto específico Entradas: Tarea Puerto Salidas: Ninguna

Pág.24


Transmit Task Port

None

Habilita el puerto de salida Transmite la señal Visto como álgebra de procesos se tiene: Transmit = Tarea , (Transmit); GetTask Se transmite la tarea y se verifica si hay otra en espera. 3.2.4 Procesos del Algoritmo Manda un mensaje, indicando que frecuencia fue seleccionada Obten la tarea (GetTask) Obtiene la tarea de un puerto específico Entradas: Puerto Salidas: Ninguna

GetTask Port Port

Obtiene la tarea del puerto especificado Visto como álgebra de procesos se tiene: GetTask = (GetTask) ; SelectFrc Si hay una tarea en espera se manda a SelectFrc para asignarle una frecuencia.

Pág.25


Incrementa el reloj (IncreseClock) Dado que el reloj está implementado utilizando un retardo de tiempo, se tiene que ir incrementando, es decir la entrada sería el instante previo y la salida el instante actual. Entradas: Tarea Puerto Salidas: Y, es el instante de tiempo actual

IncreseClock Y Task Port

Se habilita el puerto de salida Se obtiene el valor del reloj en el instante previo (la entrada) Se incrementa en uno Regresa Y (valor del reloj) Visto como álgebra de procesos se tiene: IncreseClock = Y (IncreseClock, Y+1) ; GetTask Se incrementa el valor del reloj y se obtiene una tarea en espera. Inicializa la Pizarra (InitBB) Inicializa la tabla de anchos de banda y de prioridades. Entradas: Ninguna Salidas: Ninguna

InitBB None None

En la tabla Frequency

En la posición cero inicializa las frecuencias disponibles En la posición uno inicializa a –1 (inidica que está disponible) En la posición dos inicializa a –1 (indica el agente que lo está utilizando)

En la tabla de prioridades En la posición cero inicializa la prioridad (es igual a la tarea)

Pág.26


En la posición uno inicializa el puerto donde está la tarea ( si es mayor que cero es propia, si es menor que uno es de otro agente) En la posición dos inicializa el mínimo ancho de banda permitido En la posición tres inicializa el máximo ancho de banda permitido

Visto como álgebra de procesos se tiene: InitBB = (InitBB) ; GetTask Se inicializa la pizarra y se obtiene una tarea en espera. Transmitir la Tarea (InitBB) Valida el instante de tiempo en el que se debe de realizar la planificación y en caso contrario se sigue transmitiendo en la frecuencia predeterminada. Entradas: Y, instante de tiempo Prioridad Puerto Salidas: Ninguna

Transmition Task Y

Prioridad Puerto

None Si se seleccionó una frecuencia de transmisión y todavía no se tiene que planificar Se obtiene la frecuencia preseleccionada del puerto Port Se actualiza la pizarra Si el período de tiempo de transmisión se acabó y hay que volver a planificar

Se planifica Se envía un mensaje a los demás agentes para notificarlos

Se modifica la frecuencia de transmisión Visto como álgebra de procesos se tiene: Transmitiontask = (SelectFrc || GetTask, ModifyFrc) ; Transmit Se selecciona la frecuencia de transmisión o se recupera la frecuencia pre-seleccionada, se modifica la frecuencia y se transmite al puerto.

Pág.27


3.3 Experimentos con el Planificador Dinámico 3.3.1 Fase I – Tareas factibles de ser planificadas Si se parte de un esquema de prueba en donde se tienen dos agentes con tres tareas por planificar cada uno, se pueden diferenciar dos escenarios, en el primero todas las tareas de los dos agentes son planificables, en el segundo puede haber tareas que no sean planificables4 por lo que el algoritmo las identifica y no permite que se transmita la información, ya que no hay una frecuencia disponible. En un primer escenario tenemos la pizarra inicial con seis frecuencias disponibles. Las tareas tienen especificado un rango de ancho de banda que las acota y permite que sea más flexible la asignación de frecuencia. Cuando se le asigna el valor de –1 a Task tarea (Tabla III.3), significa que la frecuencia está disponible para transmitir, en el caso de que Port tenga el valor de –1, significa que es una tarea correspodiente a otro agente, si el valor es entero positivo indica el puerto en la S-Function en el que se encuentran las tareas (Ver Capítulo IV sección 4.6.1.). Ver Tablas III.3 y III.4. Tabla III.3. Frequency. Escenario 1

Frequency Task Agent 2 1 1 3 0 2 5 2 1 6 4 2 8 3 1

10 5 2 Tabla III.4. Priorities. Escenario 1

Pág.28

Task Port Min Frq Max Frq Duration 0 0 3 5 10 1 -1 2 7 20 2 1 4 9 30 3 -1 7 10 40 4 2 4 8 50 5 -1 6 10 60

En la Fig. III.2, se puede observar como a cada tarea se le ha asignado una frecuencia diferente. Las tareas se muestran de arriba hacia abajo, de la prioridad más alta a la más baja. Las tareas 0,2 y 4 son del agente 1 y las tareas 1,3 y 5 son del agente 2. Cabe mencionar que el identificador de la tarea es igual a su prioridad.

4 Es factible de ser planificado si hay una frecuencia adecuada para transmitir la tarea


Dado que la asignación está basada en la prioridad y todas las tareas del sistema tienen una prioridad diferente, no existe la posibilidad de que haya una petición de ancho de banda de dos tareas a la vez. Para visualizar esto de mejor manera la Fig.III.3 muestra el instante en el que una tarea adquiere una frecuencia para su transmisión, es decir a la tarea cero se le asignó la frecuencia 3 en el instante cero, a los 0.1 segundos se asignó la frecuencia 2 a la tarea 1 y así sucesivamente. El tiempo de asignación puede variarse dependiendo el caso de estudio. En este caso es de 0.1 segundos ya que es igual a el tiempo de muestreo de las tareas.

Fig.III.2. Asignación de frecuencias. Fig. III.3. Tiempos en la asignación En el segundo escenario contamos con las mismas condiciones iniciales del primero cambiando unicamente el rango de ancho de banda permitido para las tareas 2 y 5 . Ver Tablas III.5 y III.6.

Tabla III.5. Frequency. Escenario 2

Frequency Task Agent 2 1 1 3 0 2 5 4 1 6 -1 2 8 3 1

10 -1 2

Pág.29


Tabla III.6. Priorities. Escenario 2

Pág.30

Task Port Min Frq Max Frq Duration 0 0 3 5 10 1 -1 2 7 20 2 1 3 4 30 3 -1 7 10 40 4 2 4 8 50 5 -1 7 9 60

Al realizar la planificación, para la tarea 2, dado el rango que restringe las frecuencias permisibles, no hay una opción viable que permita su transmisión, por ello se categoriza como una tarea no planificable, y se continua seleccionando la mejor opción para las demás tareas. Para la tarea 5 es el mismo caso. Ver Fig. III.4 y Fig.III.5.

Figura III.5. Tiempos en la asignación de frecuencias (Escenario 2).

Figura III.4. Asignación de frecuencias (Escenario 2).

3.3.2 Fase II - Planificación dinámica de tareas en ancho de banda La planificación dinámica en ancho de banda permite realizar la transmisión de una tarea a diferente velocidad cada determinado tiempo, es decir, se varía la frecuencia de transmisión utilizando un parámetro que indica el período de tiempo en que es utilizada. Para notificar a los demás agentes la frecuencia que ha sido seleccionada se manda un mensaje y se actualizan sus pizarras.


Para mostrar este dinamismo se plantea un escenario en que tenemos tres agentes con una tarea cada uno5, y el lapso de los períodos en los que cambian. Las frecuencias son: 1 segundo para la tarea 1, 2 segundos para la tarea 2 y 3 segundos para la tarea 3, tomando en cuenta que el tiempo de muestreo es de 0.1 segundo y la duración que se encuentra en la pizarra equivale al número de tiempos de muestreo que permanece transmitiendo en una frecuencia seleccionada. Ver Tablas III.7 y III.8.

Tabla III.7. Frequency. Escenario 3

Band Width Task Agent 1 -1 -1 2 0 1 3 1 2 5 2 3 6 -1 -1 8 -1 -1

10 -1 -1

Tabla III.8. Priorities. Escenario 3

Task Port Min BW Max BW Duration

0 0 2 10 10 1 -1 2 10 20 2 1 2 10 30

Al realizar la planificación de las tareas de la Fig.III.6. Se observa como la velocidad de transmisión se disminuye e incrementa en tiempo de ejecución, tomando en cuenta el parámetro de duración6. Esto es reflejo de la Fig. III.7 la cual muestra los cambios en el tiempo de frecuencias para cada tarea, es importante mencionar que en ningún momento se repiten las frecuencias, esto es posible gracias al envío de mensajes entre los agentes. Las Fig. III.6. y III.7 muestran en la primera gráfica a la tarea 1, en donde se observa el cambio de frecuencia cada segundo, en la segunda gráfica se muestra la tarea 2 cambiando su frecuencia cada dos segundos y la tercer gráfica muestra la tarea 3 haciendo el cambio de frecuencia cada tres segundos. Cada vez que seleccionan una nueva frecuencia contemplan las frecuencias que están siendo utilizadas por las demás tareas.

5 Cabe mencionar que el algoritmo puede planificar n tareas por agente. 6 Es importante notar que la frecuencia que se modifica es la de transmisión, no la frecuencia de la señal , ni la frecuencia

de muestreo.

Pág.31


En la Fig.III.6 se observa que mientras más pequeña es la frecuencia de transmisión (valor de la frecuencia en las gráficas de la Fig.III.7) aparecen más pulsos en la gráfica de la señal de la tarea (Fig.III.6), es decir es más rápida la transmisión de la tarea, mientras más grande es el valor de la frecuencia, menos pulsos presenta por lo que es más lenta la transmisión de la información.

Fig.III.6. Asignación de frecuencias (Escenario 3).

Fig. III.7. Tiempos en la asignación de frecuencias (Escenario 3).

3.3.3 Fase III - Planificación dinámica de tareas en ancho de banda con tolerancia a fallas. En esta fase, el algoritmo tiene integrada una característica muy importante, la tolerancia a fallas, con la que, mediante el uso de un parámetro, se define que agente debe realizar una planificación para cambiar su frecuencia de transmisión. Este parámetro indica si ha ocurrido una falla7 y cuál es, (Ver capítulo V, sección 5.3), así cada agente actúa dependiendo de la falla que halla ocurrido. Si ocurrió la falla 1 actúa el agente integrado en la etapa de obtención de datos (interfaz con los sensores); si el sistema no presentó fallas, éste parámetro toma el valor de 2 (es decir, el sistema está operando de forma normal) y el agente ubicado en la etapa de control re-planifica; si ocurrio la falla 3, el agente que se encuentra en la etapa de la Interfaz con la planta, realiza nuevamente la planificación de la tarea que está transmitiendo.

7 Las fallas que se generan en el sistema son dos : la falla 1 indica que el sensor 1 no está trabajando adecuadamente. la falla 3 indica que el sensor 2 no está trabajando adecuadamente.

Pág.32


Pág.33

Las fallas se asocian a fallas en los sensores 1 y 2, por lo que para el sensor 1 se genera la falla 1 y para el sensor 2 se produce la falla 3. De esta manera es imposible que pueda ocurrir una concurrencia entre dos agentes o más para realizar su planificación al mismo tiempo (deadlock), ya que sólo planifica uno a la vez. Para obtener los resultados con esta configuración, es necesario integrar el algoritmo al caso de estudio, generando fallas y mostrando el comportamiento de los agentes ante ellas. Ver Capítulo IV. 3.4 Resumen El Análisis Conductual es la etapa más importante en el diseño de sistemas multi-agente (y en general en cualquier sistema la etapa de diseño es primordial ) ya que en ella se define el alcance que éste puede tener, y surgen todas las posibles interrogantes que regulan su comportamiento: se define si es autónomo o no, que y cómo percibir de su entorno, que acciones puede realizar dependiendo de los cambios de su entorno, y de que manera se puede comunicar con otros agentes, etc. En este caso también de define la configuración de pizarra utilizada y la manera en la que es utilizada por los agentes. Teniendo el análisis anterior se prosigue a traducirlo a un pseudo-código, definiendo las funciones que se requieren señalando cuales son las entradas, cuales son las salidas y que debe hacer dicha función. Posteriormente se implemeta en lenguaje C utilizando S-funtions de Matlab/Simulink. Los experimentos realizados se dividen en tres fases:

1) La planificación se realiza asignando una frecuencia de transmisión para cada tarea.

2) La planificación se realiza cada período de tiempo, este periodo se define para cada tarea.

3) El sistema se hace tolerante a fallas, introduciendo un parámetro que identifica si ha ocurrido una falla y en dónde se dió, o si el sistema está operando normalmente.

CAPÍTULO IV _____ _ ____Caso de Estudio

Pág.34

CASO DE ESTUDIO 4.1 Introducción El planificador dinámico provee una solución a la etapa de comunicación para definir en tiempo de ejecución la velocidad de transmisión en la cual cada tarea debe comunicarse, seleccionando una frecuencia dentro de un ancho de banda definido, dependiendo del rango de frecuencias en las que puede transmitir. El levitador magnético es el caso de estudio seleccionado para acoplar el planificador a un sistema de reconfiguración distribuido en tiempo real, dado que es un sistema muy sensible y permite mostrar el desempeño del sistema multi-agente en el sistema de control. El sistema distribuido consta de tres etapas: 1) la obtención de datos, 2) el controlador y 3) la interfaz con la planta de levitación magnética. En cada etapa se encuentran los agentes planificando las tareas del sistema, apoyándose en una arquitectura de pizarra que constante esta siendo actualizada y la cual contiene toda la información del entorno en el que se encuentran. El controlador utilizado es un sistema lógico difuso llamado Takagi Sugeno y realiza de forma dinámica la selección de la ley de control que debe aplicarse analizando el error y la integral del error. 4.2 Levitador Magnético El caso de estudio es un sistema de levitación magnética integrada a una red de computadoras mediante herramientas de software y hardware, tales como Real Time Workshop1 y XPCtarget2, con las cuales se evita hacer una programación de bajo nivel para el controlador y otros componentes del sistema. El controlador es generado a través de un modelo de Simulink (herramienta de MATLAB) en una computadora denominada PC Host, para ejecutarlo en tiempo real es necesario bajarlo a una PC Target utilizando el Real Time Workshop mediante un puerto Ethernet. Y para realizar la interfaz entre la PC Target y el maglev (levitador magnético) se utiliza un Quanser DAQ en la PC Target.

1 Real Time Workshop es una extension de las capacidades de Simulink ya que es quien compila el código fuente de los

modelos de Simulink y crea aplicaciones con software de tiempo real , también provee una interface gráfica y es de arquitectura abierta para hacer procesos fuera del actual alcance.

2 Es un kernel que permite bajar la información producida por el Real Time Workshop de los modelos genrados en

Simulink, de una PC Host a una PC target para ejecutarlos en tiempo real.


El levitador magnético es un sistema dinámico no lineal y es un sistema de lazo abierto variante en el tiempo, el cual esta constituido por un electro-imán, un sensor infrarrojo para medir la posición y una esfera de acero. Ver Fig.IV.1.

Fig.IV.1. Levitador Magnético

Usando un diagrama de cuerpo libre para el levitador magnético se obtiene la función de transferencia, tal y como se muestra en [18], de corriente-posición del sistema electro-mecánico como sigue:

( )

bob

co

bobdc

b

bbdcbi

xgw

Ixk

wswksG

2

22

2

=

=

−−

=

(1)

g es la fuerza de gravedad Ico es la corriente de la bobina xbo es la distancia de la bobina a la posición de la esfera. A continuación se definen los retardos de tiempo para la implementación de la planta,

Ts2Ts2e

Ts

+−

≅−

(2)

Pág.35


dónde T es el retardo de transporte La integración del levitador magnético a la red de computadoras se muestra en la Fig. IV.2.

Actuador

Actuador

Sensor

Sensor

PC2

Sistema para elDiagnóstico de Fallas

Fig. IV.2. Integración del caso de estudio a la red de computadoras. 4.3 Sistema de Control El Sistema de control utilizado en la reconfiguración, está diseñado para soportar las fallas que sucedan en el mismo con el fin de mantenerlo estable. Este tipo de reconfiguración se obtiene como respuesta de un retardo de tiempo cuado la falla aparece. Para su implementación, en las Fig.IV.3 y IV.4 se muestran los diagramas de tiempo (para mayor detalle consultar [19]), en donde se muestran los tiempos máximos de retardo, s1 y s2 representan los sensores ópticos 1 y 2, C es el nodo de control y A1 es el actuador. Cuando una falla ocurre los agentes actúan para reorganizar la ejecución de las tareas.

Pág.36


S1

A1

C

S4

tss

tcc

taa

p1

p4

S1

C

A1

S4

p4

p1

ts

ta

tc tcm

tcmsc

time

Fig. IV.3. Escenario libre de fallas

S1

A1

C

S4

tss

tcc

taa

p1

p4

ts

ta

tc tcm

tcmsc

time

sf

tcmfsc

S1

C

A1

S4

p4

p1

Fig. IV.4. Escenario con fallas Ambos escenarios son locales con respecto al levitador magnético. Como los dos escenarios están acotados se pueden expresesar los tiempos de retardo que se presentan a lo largo del proceso de configuración. El escenario libre de fallas, se expresa en la ecuación 3.

acmcsccmft

sftcms tttttt4*ttt ++++++= (3)

Pág.37


donde:

st el tiempo consumido por los sensores sccmt es el tiempo consumido por la comunicación entre el sensor y el control sft

cmt es el tiempo de comunicación entre el sensor y el módulo tolerante a fallas

ftt es el tiempo consumido por el modulo tolerante a fallas ct es el tiempo consumido por el nodo de control cmt es el tiempo consumido por la comunicación entre el controlador y el actuador at es el tiempo consumido por el actuador

El escenario con fallas, se expresa en la ecuación 4.

acmcft

cmftft

cmsccms tttttttttt +++++++= 4* (4)

donde:

sccmt es el tiempo asumido por la comunicación entre el sensor y el control fsc

cmt es el tiempo consumido por el sensor de falas el cual por medio de mensajes notifica a su vecino y produce un acuerdo

ct es el timpo consumido por el nodo de control sft

cmt es el tiempo de comunicación entre el sensor y el módulo tolerante a fallas

ftt es el tiempo consumido por módulo tolerante a fallas cmt es el tiempo consumido por la comunicación entre el controlador y el actuador at es el tiempo consumido por el actuador

Un elemento común en los dos escenarios, es el módulo tolerante a fallas el cuál da información adicional al módulo de control para seleccionar la ley de control adecuada y tolera la falla local de los sensores. Del escenario con fallas, surgen dos escenarios más, con una falla local o varias fallas locales. En el primer caso se presenta una degradación menor para la estrategia de control global, en tanto que en la segunda tiene un impacto considerable. A pesar de esta degradación en el desempeño, el sistema puede mantenerse funcionando normalmente debido a la estrategia tolerante a fallas inherente y a los tiempos de retardo integradas a los controladores relacionados. Las fallas son locales y relacionadas a la luz por cada sensor óptico. Tomando en cuenta estas dos posibles configuraciones en la Tabla IV.1 se muestran los tiempos de retardo [19].

Pág.38


Tabla IV.1. Retardos de tiempo en comunicaciones locales

Escenario con fallas Retardos de tiempo local Retardos de tiempo global

Una falla local 1 ms 3 ms

Varias fallas locales 1 ms 5 ms

Como los retardos de tiempo están acotados, el modelo de la planta3 se define con base en las ecuaciones 1 y 2 y la Fig.IV.5.

Pág.39

Actuador Controlador Difuso, Takagi Sugeno

Sistema de Levitación Magnética k

Planificador Dinámico

Arreglo de Sensores

Número de referencia

Error

Salida

Retardo de Tiempo para la Corriente Nominal

Fig.IV.5. Integración de la Ley de Control a la Planta El Control PID evaluado para diferentes retardos de tiempo se muestran en la Tabla IV.2. Valores KP y KI para el controlador. Donde las constantes KP y KI pertenecen a la siguiente ecuación:

∫+= edtKIKPeu * (5)

Tabla IV.2. Valores de KP y KI para el controlador

Escenario libre de fallas

KP KI

23.1 66.8

KP 136.1 Escenario con una falla local

KI 44.1

KP 217 Escenario con varias fallas locales

KI 68.5

3 La planta se encuentra conformada por el sistema distribuido ( obtención de datos por medio de sensores, controlador y

la interfaz que permite mediante actuadores modificar la corriente de la bobina del levitador magnético ) y el sistema de levitación magnética.


La ley de control es definida como un conjunto de leyes de control difusas, Takagi Sugeno [21] relacionadas a cada sistema local lineal. La estructura general de cada regla difusa es como se muestra a continuación

ir si es y es y … es 1x ciA1 2x c

iA 2 lx cliA

entonces ( ) ( ) ∫+= dtkekIkekPkf ii )( (6)

dónde: , N es el número de reglas difusas, { Ni ,....,1= } { }lxx ,....,1 son los estados actuales de la planta, son las funciones de membresía gausianas: c

ijA

( )⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

σ

−−= 2c

ij

2cijic

ij

cxexpA (7)

dónde:

cijc y son constantes. Para mayor información revisar[23]. c

ijσKI y kP son las ganancias de control. Similarmente a la planta del sistema difuso, la representación del control difuso fuzzy es integrada como sigue:

(∏=

=l

jj

ciji xAw

1

) (8)

y

( )( )( )

∑

∑ ∫

=

=

+= N

ii

N

i

iii

w

dtkekIkekPwku

1

1)( (9)

La configuración del sistema de control lógico difuso (FLC) esta integrada a la planta explorada dónde la representación final es dada como un sistema de lazo cerrado de una planta de retroalimentación lineal como se muestra en la Fig.IV.6. Para mayor referencia ver [22]. Control

Lógico Difuso

Actuador Fallas

Planta

y u

-

+ Ref

Fig.IV.6. Sistema de lazo cerrado Usando la planta dinámica propuesta basada en la estructura, ver [23],

Pág.40


Dónde:

Pág.41

)( ) ( ) (

( )kxcy

kuBkxa1kxp

pp

=

+=+

y para el escenario con fallas: ( )

∑ ∫==

−−−M

1j

ta

i

p

i

i1j

ij

p

deBBτ

τ

ττ

el cuál considera fallas locales los retardos de tiempo asociados, ver ecuaciones 4 y 6, dada la condición:

∑=

≤N

j

ij Tt

1

y siguiendo la representación de la planta en [23]:

( )∏=

=l

jjiji xAh

1

y reemplazando por la defusificación:

( )( )( ) ( )( )

∑

∑ ∫

==

==

++−=+ N

jiji

N

ji

pi

pi

iiiiji

wh

refBkxBdtkekIkekPcawhkx

1,1

1,1

))((1

(9)

dónde: ref es la referencia a seguir por el controlador y las variables i y j son usadas debido a las interconexiones de las reglas difusas se plantean como la representación de diferentes plantas lineales y sus respectivos controladores. El algoritmo de control está diseñado e implementado mediante el software Simulink de Matlab, con el Real-Time Workshop y XPC Target. Estas herramientas son capaces de generar automáticamente aplicaciones de tiempo real de tipo independiente (stand-alone). 4.4 Red tipo CAN- Ethernet La implementación de la red es de manera distribuida y comunicándose a través de mensajes basados en dos protocolos de comunicación CANBus y Ethernet. La red consta de cuatro computadoras, una en la que se diseñan los diagramas en Matlab/Simulink (host) y desde la cuál son transmitidos a las tres máquinas restantes en las que se ejecutarán en tiempo real (targets), y una tarjeta de adquisición de datos, la cuál provee la interfaz entre el software y el hardware a


ser controlado. Cabe mencionar que las mediciones en las señales pueden ser desplegadas en tiempo real o pueden ser grabadas para análisis posteriores. En la comunicación por CANBus, debe establecerse la velocidad de recepción y transmisión a la cual está operando el canal por el cual se lleva a cabo la comunicación y el tiempo de muestreo. La manera en la que opera este protocolo consiste en asignar una prioridad a cada tarea y ponerla en el bus de datos con un identificador, así cualquier otra computadora que quiera obtener información solo tiene que leer el identificador y si es el que busca toma el mensaje, de otra manera prosigue en su lectura. Ver Fig.IV.7.

Fig.IV.7. Diagrama simple de una transmisión mediante CANBus en Simulik En el caso de la comunicación vía Ethernet se especifica el tamaño del dato, es decir si es entero, doble, etc., el número de bytes recibidos/transmitidos, la dirección IP de la cual espera o se manda información y el tiempo de muestreo. De esta manera, sabiendo el tamaño de las tramas, el orden en el cual se encuentra la información dentro de ellas y el direccionamiento del protocolo de comunicación permite a cada computadora identificar dentro del flujo de datos qué información le corresponde. La información debe ser desempaquetada para distinguir cada dato. Ver Fig.IV.8.

Fig.IV.8. Diagrama simple de comunicación vía Ethernet en Simulink.

Pág.42


La planta de reconfiguración distribuida consta del levitador magnético, dos sensores que reportan la posición de la esfera del levitador, la interfaz con los sensores, es decir, en esta etapa se obtienen los datos; el controlador, implementado utilizando la técnica Takagi Sugeno, la cual permite seleccionar la ley de control que debe ser aplicada al sistema, y la interfaz con la planta en donde mediante actuadores se realiza la reconfiguración. La implementación final del sistema se muestra en la Fig. IV.9.

UC1

UC2

CAN BUS

Ethernet

Instrument Interface

Plant Interface

ControlInterface

SensorInterface

CAN BUS

Fig. IV.9. Implementación de la planta Los protocolos de recepción y transmisión utilizados en el sistema se muestran en la tabla IV.3., donde cada procesador corresponde a una etapa del sistema distribuido.

Tabla IV.3. Protocolos de recepción y transmisión

UDP/Ethernet UDP/Ethernet Procesador 3

UDP/Ethernet CANBus Procesador 2

CanBus CANBus Procesador 1

Transmisión Recepción 4.5 Incorporación del Planificador Dinámico al Caso de Estudio Como se comentó en las secciones anteriores, el diseño de la planta y del sistema de control está diseñado en Simulink de Matlab, para el diseño de los agentes se utiliza un bloque de Simulink que permite realizar programas en lenguaje C, C++, Fortran y ADA, y posteriormente ejecutarlo en la PC Target (máquina en la que se ejecuta en tiempo real el diagrama, bajado previamente desde la PC Host(máquina en la que se diseñan los diagramas)). Este bloque se denomina S-function y en este caso permite manipular las señales de entrada a modo. Cabe mencionar que cada vez que se ejecuta la S-function se inicializa por lo que carece de memoria. Es importante tomar esto en cuenta ya que en un programa

Pág.43


por lo general se guardan datos del estado anterior, para solucionar esto se mando el dato del estado anterior a un puerto de salida de la S-function y se conecto a un puerto de entrada de la misma con un retardo de tiempo. Con esto en el siguiente estado se puede recuperar la información. Los diagramas diseñados en Simulink pueden ser Simulados en la PC Host en tiempo no real, sin embargo hay que tener cuidado y probar constantemente que se ejecute en tiempo real mediante XPC Target, bajándolo a la PC Target, ya que en la implentación de cada uno de los agentes, se encontró que Simulink simula programas en C++, aún cuando XPC Target no los ejecuta. La Fig. IV.10. muestra la variación en la frecuencia de transmisión para tres tareas en tres instantes de tiempo distintos. En el tiempo 1 se realiza la asignación de frecuencias y se observa que todas fueron planificables, en el instante de tiempo 2, la tarea 1 baja a una frecuencia menor, la tarea 2 también baja de frecuencia, en este caso de forma drástica, y la tarea 3 sube de manera considerable, es importante resaltar que el planificador toma en cuenta el rango de frecuencias en que puede oscilar cada tarea y las frecuencias que están siendo utilizadas por otras tareas, en el instante 2 al igual que en el instante 3 todas las tareas también fueron planificables. Cabe mencionar que la región superior del ancho de banda es utilizada para realizar la comunicación Inter-agente ya que permite que los mensajes se envíen lo más rápido posible y la inforación de la pizarra sea lo más parecida al entorno actual.

Fig.IV.10. Asignación de frecuencias

Pág.44


4.5.1 S-Function La S-Function nos proporciona una gran funcionalidad dentro del diseño del sistema distribuido y específicamente para el diseño del sistema multi-agente, ya que un agente es un programa que se comporta de acuerdo a los cambios que presenta su entorno, y cada comportamiento es implementado mediante una función, la cual a su vez, es un conjunto de instrucciones que pueden ser declaradas dentro de la S-Function. Cada S-Funtion consta de dos agentes, uno autónomo (el que percibe el entrono y toma decisiones) y otro no autónomo (el que ejecuta las decisiones que tomó el agente autónomo), también consta de una pizarra, la cual contiene información que refleja el estado en el que se encuentra el entorno, es decir, que está sucediendo y quién está interviniendo en el mismo. Para programar una S-Funtion es necesario, integrar al diagrama elaborado en Simulink un bloque llamado S-Funtion ubicado dentro de la Biblioteca de Simulink en Simulink/ User-Defined Functions. Ver Fig.IV.11.

Fig.IV.11. Bloque S-Funtion

una vez dentro del modelo se le asigna un nombre y se definen los parámetros con los que va a operar, ver Fig. IV.12.

Pág.45


Fig. IV.12. Parámetros de la S-funtion Para comenzar a programarla se deben definir dos líneas #define S_FUNCTION_LEVEL 2 #define S_FUNCTION_NAME schedule El nivel 2 es para indicar que la versión de Simulink es igual o posterior a la 2.2, para versiones anteriores el nivel es 1. Y la segunda es el nombre del programa sin extensión, en este caso schedule. Es importante tener en cuenta la estructura de una S-Funtion, ya que cada vez que se ejecuta se pasa por cada una de las etapas. Ver Fig.IV.13. En la función mdlInitializeSizes se definen, inicializan y activan los puertos de entrada y de salida; mdlInitializeSampleTimes define el tiempo de muestreo; MdlOutputs es la sección más importante ya que en ella es en dónde se realizan las acciones que se van a ejecutar de acuerdo al comportamiento deseado y mdlTerminate, permite hacer las acciones finales dentro de un programa, como son el liberar memoria, por ejemplo.

Fig.IV.13 Estructura de una S-Funtion

Pág.46


Pág.47

La Programación del Planificador Dinámico se enfoca en la programación de mdlOutputs, por lo que de aquí en adelante solo se hará referencia a las funciones creadas y utilizadas para este fin. Para obtener los datos acerca del entorno, la S-Funtion utiliza puertos de entrada y para proporcionarlos a otros bloques del sistema utiliza los puertos de salida. Para esto se tienen las funciones GetTask, CheckMail y SendMail. Aquí hay que tomar el cuenta el tipo de información que se está recibiendo/transmitiendo y como se va a procesar, ya que por, ejemplo en el caso de tener una señal continua, se pede tomar dato por dato o ir guardando dato por dato en un arreglo. La pizarra se define como una estructura de datos con dos matrices, una que contiene la información acerca de las frecuencias disponibles/ocupadas por una tarea y por un agente, y la segunda especifica y acota los anchos de banda en los que operan cada uno de los agentes y el puerto por el que se informa la frecuencia utilizada. Los agentes se definen como un conjunto de funciones que realizan un comportamiento específico de acuerdo a los cambios que represente su entorno. El flujo de información comienza al percibir el entorno mediante funciones que obtienen esta información de algunos puertos de entrada, como son las frecuencias seleccionadas por otros agentes para realizar la transmisión de sus tareas, ver Fig. 14, con ésta información se actualiza la pizarra y se realiza una planificación por el Agente Scheduler y se obtiene una frecuencia de transmisión factible para la tarea, justo antes de transmitirla mediante el Agente Transmition, se verifica nuevamente (consultando los puertos de entrada referentes a las frecuencias utilizadas por otros agentes) que no haya una notificación de último momento por parte de otro agente de un cambio en su frecuencia de transmisión, posteriormente se realiza la transmisión y se notifica a los demás agentes de la elección, poniendo en los puertos de salida esta información. El sistema multi-agente está implementado en lenguaje C, a continuación se presenta su diagrama indicando a que corresponde cada puerto de la misma, Fig.IV.14, dónde SD, significa Sin Dato en el puerto.


Fig. IV.14. Diagrama de la S-Function

Para compilar el programa se ejecuta en la línea de comandos la sentencia mex <nombre del archivo> posteriormente se procede a simularlo ó en el caso de ejecutarlo en tiempo real, mediante el Real –Time Workshop se transmite a una PC Target y se ejecuta. 4.5.2 El Sistema Distribuido El sistema distribuido consta de tres etapas, la primera obtiene los datos mediante los sensores para saber la posición de la esfera de acero en el levitador magnético y envía una diferencia de los datos leídos para indicar si el sistema se encuentra en un estado estable o de falla, en el caso de captar una falla indica en dónde sucedió, es decir, que sensor óptico está produciendo dicha falla. El agente ubicado en esta etapa planifica la información a transmitir siendo capaz de detectar si se presentó alguna falla que pueda soportar y actuar ante esto para permitir que el sistema se mantenga operando con un buen desempeño. Los agentes integrados en esta etapa responden ante las fallas del sensor 1, tomando como medida la re-planificación de la tarea. Los protocolos de comunicación son

Pág.48


Pág.49

CANBus tanto para la recepción como para la transmisión de información. Ver Diagrama de la Etapa I -Obtención de datos mediante sensores en el Apéndice B. La siguiente etapa realiza el control de la planta mediante un sistema lógico difuso denominado Takagi Sugeno, este módulo utiliza el error y la integral del error para calcular la ley de control que debe ser ejecutada para mantener estable la planta, para mayor detalle ver la sección 4.2. Posteriormente la información emitida por el controlador, la utilizan los agentes correspondientes a esta etapa para en caso de que el sistema esté estable, planificar la información, en caso contrario, es decir, si ha ocurrido alguna falla permitir que cualquiera de los otros agentes a lo cuales les corresponde actuar en los escenarios de fallas tomen las decisiones para mantener estable la planta. Los protocolos de comunicación son CANBus para la recepción y Ethernet para la transmisión de información. Ver Diagrama de la Etapa II – Controlador en el Apéndice B. La última etapa aplica la reconfiguración del sistema con la información del controlador al levitador magnético. En este caso los agentes asociados actúan si se presenta alguna falla en el sesor 2, tomando como medida la re-planificación de la tarea que está transmitiendo. Para realizar la comunicación entre esta última etapa y el levitador magnético se utiliza la interfaz Q8 Quanser. El protocolo de comunicación es Ethernet tanto para la recepción como para la transmisión de información dentro del sistema distribuido. Ver Diagrama de la Etapa III – Interfaz de la Planta en el Apéndice B. 4.6 Resumen En este capítulo se explica el funcionamento de un levitador magnético que lo representa, su integración al sistema distribuido, en el cual se encuentra dividido el proceso de reconfiguración: 1) obtención de datos, 2) Controlador, 3) Interfaz con la planta. Se detalla el sistema de control en diferentes escenarios: 1) libre de fallas y 2) con fallas locales. Se calculan los retardos de tiempo para que el controlador los absorba ya que el hecho de que el sistema se encuentre distribuido, genera dichos retardos [22]. El Algoritmo de control usado en este trabajo es el denominado Takagi Sugeno, el cual mediante un conjunto de reglas difusas elige la ley de control más adecuada para realizar la reconfiguración dado el estado de la planta [18] [20]. La planta cuenta con una Red tipo CANBus/Ethernet, por lo que se especifica qué protocolos son usados en la recepción/transmisión en las diferentes etapas del sistema. [18]


Pág.50

Para la incorporación del algoritmo al caso de estudio es necesario realizar la implementación en una S-Funtion, la cual se revisa a detalle en la sección 4.6.1.

CAPÍTULO V Resultados

Pág. 51

RESULTADOS 5.1 Introducción En este capítulo se presentan diversos escenarios de prueba en los que se puede observar el comportamiento del error mediante la variación de factores como la presencia y frecuencia de fallas en el sistema. También se realizan comparaciones entre los escenarios para determinar el impacto que tienen estos factores en la respuesta del sistema. 5.2 Escenario Libre de Fallas En este escenario se planifican tres tareas1 utilizando el planificador dinámico, el cual se encarga de transmitir las tareas a diferentes frecuencias en intervalos de tiempo específicos asignados a cada una de ellas:

Tarea 1: La corriente de la bobina Tarea 2: El estado del sistema, para toma de decisiones con respecto a

las fallas (siempre es igual a ‘2’, ya que se presume que no hay fallas)

Tarea 3: La diferencia entre el valor de la corriente medida y los límites en los que se encuentra acotada (0-3 A).

Dado que el sistema siempre está en un estado de funcionamiento normal, los agentes que realizan la planificación están percibiendo su entorno constantemente y actúan cada inicio del intervalo de tiempo especificado para cada una de ellas, en este caso 2.5 seg. para cada tarea. En la Fig. V.1 se observa la planificación para cada una de las tareas cada cinco segundos, esto es, la asignación de la frecuencia de transmisión se realiza de forma periódica tomando en cuenta los rangos de frecuencia en los que se puede mover cada una de ellas y el ancho de banda disponible. De esta manera es fácil identificar el dinamismo de la planificación. Las tres primeras gráficas muestran la respuesta de activación en términos de las frecuencias de las tareas 1,2 y 3 respectivamente. La cuarta gráfica muestra el error del sistema de control, en donde se observa la influencia del cambio de

1 Ver el apéndice B, para identificar cada una de las tareas en los diagramas de Simulink en dónde se especifica en que

parte del proceso de reconfiguración de la planta de levitación magnética se encuentran localizadas las tareas.


Pág. 52

frecuencia de cada tarea. Cada vez que una tarea cambia de frecuencia se produce un pico en la señal del error con un retardo de tiempo, marcadas en la Fig.V.1 con una línea punteada ( ). Las regiones marcadas con un óvalo muestran una perturbación en el sistema producida por la tarea 1 la cuál es compensada por el sistema de control para el buen funcionamiento de la planta.

Fig. V.1. Respuesta del error modificando la frecuencia

de transmisión de tres tareas. Libre de fallas.

La Fig. V.2 muestra tres tareas, la corriente la bobina, el estado del sistema (en este caso es constante ya que no hay presencia de fallas), el error en la respuesta de la corriente de la bobina y el error del sistema de control, el cual se mantiene acotado dentro de un rango de – 0.2 y 0.2.


Pág. 53

Fig. V.2. Respuesta de las tareas. Libre de Fallas

5.3 Escenarios con manejo de fallas En este escenario se planifican tres tareas utilizando el planificador dinámico, el cual se encarga de transmitir las tareas a diferentes frecuencias cada vez que el sistema cambia de estado.

Tarea 1: La corriente de la bobina Tarea 2: El estado del sistema para toma de decisiones con respecto a

las fallas, el cual puede tomar los siguientes valores: • 1, indica que se produjo una falla en el sensor 1. • 2, indica que no se produjo ninguna falla, es decir, el

sistema se encuentra operando de forma normal. • 3, indica que se produjo una falla en el sensor 2.

Tarea 3: La diferencia entre el valor de la corriente medida y los límites

en los que se encuentra acotada (0-3 A).


Pág. 54

Dado que el sistema es perceptible a cambiar constantemente de estado, el sistema multi-agente actúa de la siguiente manera: • Si el sensor 1 presenta una falla actúa el agente 1, cambiando la frecuencia de transmisión de la Tarea 1. El agente se ubica en la interfaz con los sensores dentro del sistema distribuido. • Si el sistema se encuentra operando de manera normal, es decir, no hay fallas, actúa el agente 2, cambiando la frecuencia de transmisión de la Tarea 2, esto se realiza solamente cuando cambia de un estado de falla a un estado de operación normal, de otra manera mantiene la frecuencia de transmisión asignada hasta que ocurra un cambio de estado. El agente se ubica en la interfaz de control dentro del sistema distribuido. • Si el sensor 2 presenta una falla actúa el agente 3, cambiando la frecuencia de transmisión de la Tarea 3. Este agente se ubica en la interfaz con la planta dentro del sistema distribuido. 5.3.1 Manejo de fallas con asignación de frecuencias constante

En esta sección se contemplan escenarios en los que se produce una falla en el sistema, o de un escenario con fallas se pasa a un estado de operación normal. El agente encargado de realizar la planificación, cambia constantemente la frecuencia de transmisión. Esto es con el fin de observar el impacto que se produce en la señal del error. La Fig. 3 muestra áreas negras que representan un cambio muy rápido en la asignación de estas frecuencias, por esa razón no se pueden identificar los valores que va asignando, sin embargo si podemos visualizar que el mínimo valor que toma es 1 y el máximo es 5. Cuando se realiza la planificación, en la pizarra tenemos una serie de frecuencias que son las que se asignan a cada tarea por cada agente para su transmisión, estas frecuencias indican el número de tiempos de muestreo que será retenida la señal con el valor de la señal en el instante en el que se le asignó la frecuencia indicada en la pizarra, por esta razón para calcular la frecuencia en Hz a la que se está transmitiendo la tarea se utiliza la ecuación (1).

HzT

Fsp

T α1

= ecuación (1)


Pág. 55

donde,

TF , es la frecuencia de transmisión en Hz

pα , es la frecuencia de transmisión indicada en la pizarra (factor que retiene el valor de la señal cada pα tiempos de muestreo)

sT , es el tiempo de muestreo Cabe mencionar que a lo largo del capítulo cada vez que se hace referencia a la frecuencia, se trata de la frecuencia para cada tarea indicada en la pizarra. En la Fig.V.3 las tres primeras gráficas corresponden a las frecuencias asignadas por los agentes para las Tareas 1,2, y 3 respectivamente. La cuarta gráfica muestra que se producen pocos cambios en el estado del sistema, es decir el periodo de tiempo en el que actúa cada agente es grande y se encuentra reasignando frecuencias todo el tiempo. Los valores que obtiene son 1 cuando está actuando el agente 1, 2 cuando está actuando el agente 2 y 3 cuando está actuando el agente 3. En la Fig.V.3. Las líneas punteadas muestran la relación entre el cambio de estado de falla (cuarta grafica) y el período de actividad del agente (gráficas 1,2 y 3 para los agentes 1,2 y 3 respectivamente ), es decir, en el lapso de tiempo entre las dos primeras líneas ( ) se observa que mientras el estado del sistema tiene un valor de 1 (falla en el sensor 1), el agente 1 se mantiene activo,(representada por el área negra de la primera gráfica), las tercera y cuarta líneas ( ) acotan el lapso de tiempo en que el sistema se encuentra en un estado de operación normal (es decir, no hay presencia de fallas, el estado tiene un valor igual a dos, Ver gráfica 4), mientras que en la gráfica 2 se observa que el agente 2 está cambiando constantemente de frecuencia. Entre las cuarta y quinta línea ( ), se observa que en la gráfica 4 el estado del sistema tiene un valor de 3, lo que equivale a tener la presencia de una falla en el sensor 2, y la gráfica 3 muestra que es el agente tres el que se encuentra activo. La quinta gráfica muestra una perturbación (controlada) en el error, en la región marcada con un óvalo, esta perturbación es producida por la tarea 2 (gráfica 2) en el momento en que el valor de la frecuencia que obtiene es alto, en este caso es de 5, a partir de los 4 segundos quien produce la perturbación es la tarea 3, ya que de igual manera toma un valor de 5, posteriormente es la tarea 2 quién vuelve a tomar un valor alto y produce la perturbación.


Pág. 56

Fig. V.3. Respuesta del error ante cambios constantes de

frecuencia en el período de planificación y poca presencia de fallas.

La Fig. V.3 muestra el cambio de frecuencias de las tareas, en este caso, la Fig.V.4 muestra la respuesta de las tareas de acuerdo a la frecuencia, bajo las mismas condiciones que la figura anterior hay cambios poco frecuentes en el estado del sistema y una asignación rápida en la asignación de frecuencias. Las tres primeras gráficas muestran la respuesta de las tareas 1,2 y 3, en donde la tarea 2 representa los valores del comportamiento del sistema (estado en el que se encuentra), y la cuarta muestra el mismo comportamiento en el error que la figura anterior. Cabe mencionar que la gráfica 2 muestra la ocurrencia de fallas en el sistema.


Pág. 57

Fig. V.4. Respuesta de las Tareas ante cambios constantes de

frecuencia en el período de planificación y poca presencia de fallas.

En el siguiente escenario las condiciones en las que opera el sistema son bajo cambios aleatorios y constantes en la falla por lo que hay cambios rápidos en la asignación de frecuencias. En las Figs. V.5 y V.6 podemos observar la relación entre tareas y el tiempo en el que los agentes realizan la planificación de acuerdo al estado del sistema y la respuesta de las tareas, son muy similares a las dos figuras anteriores, las cuales nos muestran el cambio de frecuencias y la respuesta de las tareas, la diferencia radica en que las Figs. V.3 y V.4 tienen poca presencia de fallas y en las Figs. V.5 y V.6 se presentan más fallas (como se puede observar en la gráfica de asignación de fallas, gráfica 2). Sin embargo al observar el error se puede visualizar que al incrementar el número de fallas el sistema sigue teniendo el mismo comportamiento. Por lo que el hecho de que se presenten fallas no altera el funcionamiento del sistema. Ver la regiones marcadas con un óvalo Figs. V.3 y V.4 y las Figs. V.5 y V.6. Las perturbaciones en el error marcadas con un óvalo son producidas por el agente 2.


Pág. 58

Fig. V.5. Respuesta del error ante cambios constantes de frecuencia en el período de planificación y presencia constante de fallas.

Fig. V.6. Respuesta de las tareas ante cambios constantes de frecuencia en el período de planificación y presencia constante de fallas.


Pág. 59

En la Fig.V.7 se tiene un escenario híbrido en donde los agentes 1 y 3 (gráficas 1 y 3) realizan una asignación de frecuencias rápida y constante, es decir, cambia constantemente de frecuencias (áreas negras en las gráficas 1 y 3 ) y el agente 2 (gráfica 2) mantiene la frecuencia que seleccionó al comenzar la planificación durante todo el tiempo que se mantiene activo. Los cambios en el comportamiento acotados por las líneas punteadas muestran la relación entre los cambios de estado del sistema y la actividad de los agentes, es decir, cada vez que el sistema cambia de estado se puede observar que al tomar el valor de 1 (gráfica 1) realiza el cambio de frecuencias, mientras que en las gráficas 2 y 3 se mantiene el último valor constante; del mismo modo cuando toma el valor de 2 y 3. El error sigue mostrando perturbaciones moderadas dados los rápidos y continuos cambios en las frecuencias de transmisión (el controlador mantiene el sistema estable compensando el error).

Fig. V.7. Respuesta del error. Escenario híbrido.


Pág. 60

5.3.2 Manejo de fallas manteniendo la frecuencia asignada Esta sección contempla los escenarios con manejo de fallas y cada vez que se realiza una nueva asignación en la frecuencia de transmisión de una tarea, ésta frecuencia se mantiene hasta que se regrese al estado en el que se realizó la planificación de la tarea.

La Fig. V.8 muestra la respuesta del error ante el cambio de frecuencia de las tres tareas y las fallas que se producen en el sistema, en este caso los cambios en el estado del sistema son poco frecuentes. Las tres primeras gráficas muestran el cambio en la frecuencia de transmisión para cada una de las tareas, la corriente de la bobina (gráfica 1), el estado del sistema (gráfica 2), y la diferencia entre la corriente de la bobina medida y los límites mínimos y máximos especificados (0-3 A), ver gráfica 3. En la cuarta gráfica se encuentran los cambios de estado generados de manera aleatoria, es decir, nos indica que fallas ocurrieron (cuando toma los valores 1 y 3, fallas del sensor 1 y 2 respectivamente) y en que momento estuvo en operación normal (cuando toma el valor de 2). En la quinta gráfica se muestra la respuesta del error del sistema de control, en la que se puede observar una ligera perturbación causada por la tarea 3 cuando toma un valor alto (en este caso de 5) en las regiones marcadas con un óvalo, mientras que si se produce un cambio de estado se produce sólo un pico en la señal del error, en la Fig. V.8 se señala con una línea punteada.

Fig. V.8. Respuesta del error manteniendo la frecuencia en el

período de planificación y poca presencia de fallas.


Pág. 61

La Fig. V.9 muestra la respuesta de las tareas realizando el cambio de frecuencias de transmisión en un escenario donde los cambios en el estado del sistema son poco frecuentes. La primer gráfica muestra la corriente de la bobina planificada, la segunda gráfica indica las fallas que se están presentando en el sistema y los períodos en los cuales está en operación normal. La cuarta gráfica muestra la diferencia entre el valor de la corriente medida y los valores mínimo y máximo permitidos para la corriente (0-3 A) presenta una ligera inestabilidad y la quinta gráfica es la referencia que maneja el sistema de control. Comparando las tareas, la señal del error y la referencia se visualiza que las tareas siguen el comportamiento de la referencia de control (el escalón, región marcada en el rectángulo).

Fig. V.9. Respuesta de las tareas manteniendo la frecuencia en el

período de planificación y poca presencia de fallas.

De manera análoga la Fig.V.10 muestra la respuesta del error ante el cambio de frecuencia de las tres tareas 1,2 y 3 (gráficas 1,2 y 3 respectivamente) y las fallas


Pág. 62

que se producen en el sistema (gráfica 4), en este caso los cambios en el estado del sistema son constantes y son generados de forma aleatoria. En la quinta gráfica, se muestra la respuesta del error del sistema de control, en la cual si se compara con la Fig.V.8 hay pocas fallas y en la Fig.V.10 hay más presencia de fallas y aún así se puede observar que el comportamiento de la respuesta del error es muy similar, ambas muestran una ligera perturbación, la cual es bien manejada y compensada por el sistema de control.

Fig.V. 10. Respuesta del error manteniendo la frecuencia en

el período de planificación y presencia constante de fallas.

La Fig.V.11 muestra la respuesta de las tareas realizando el cambio de frecuencias de transmisión en un escenario donde los cambios en el estado del sistema son constantes, la segunda gráfica representa la Tarea 2 , la cual indica las fallas que se presentan en el sistema y los períodos en los cuales el sistema está en operación normal (cuando toma el valor de 2). El error presenta una


Pág. 63

pequeña perturbación y la quinta gráfica es la referencia que maneja el sistema de control. Comparando las tareas, la señal del error y la referencia se visualiza que éstas siguen el comportamiento de la referencia de control (el escalón, región marcada en el rectángulo punteado). Si se compara la señal del error con la de la Fig.V.9 se observa que ambas presentan una pequeña perturbación cada vez que se produce la falla del sensor 1, es decir, el estado del sistema toma el valor de 1, que no afecta de manera drástica al sistema ya que la compensa el sistema de control.

Fig. V.11. Respuesta de las tareas manteniendo la frecuencia en

el período de planificación con presencia constante de fallas.


Pág. 64

5.4 Resumen En este capítulo se analizaron las tareas, sus cambios de frecuencias en ambientes libres de fallas, en donde se produjeron fallas poco frecuentes y otro en los que las fallas fueron constantes, también se analizaron los escenarios con fallas introduciendo un cambio continuo y rápido en la asignación de frecuencias y los que una vez que fue asignada la frecuencia se mantuvo, con el fin de visualizar el impacto que pudiese producir un escenario caótico en dónde se planifica de forma dinámica con cambios muy rápidos en la frecuencia de transmisión. Si se compara la señal del error de las gráficas de la sección 5.3.2 “Manejo de fallas manteniendo la frecuencia asignada, con las de la sección” 5.3.1 “Manejo de fallas con asignación de frecuencias constante”, se puede visualizar como el error se suaviza de manera considerable si se mantiene la asignación de la frecuencia asignada. Este resultado es muy importante ya que el error se proyecta directamente en la estabilidad del sistema lo cual es el principal objetivo de la planta de control. Es importante resaltar que en la sección 5.3.1 al incrementar el número de fallas el sistema sigue teniendo el mismo comportamiento. Por lo que el hecho de que se presenten fallas constantes no altera el funcionamiento del sistema.

CAPÍTULO VI__ _________ ____Conclusiones

Pág. 65

CONCLUSIONES El origen del problema que se resolvió proviene de los sistemas con tolerancia a fallas, ya que si alguna de estas ocurre, el sistema debe ser capaz manejar la situación de manera que siga operando. En este caso, un sistema de control distribuido, se pone especial énfasis a la fase de comunicación y se crea un planificador dinámico que permite organizar sus tareas en ancho de banda en tiempo de ejecución, es decir, que decida a que velocidad debe ser transmitida cada tarea. Dadas las condiciones en las que se encuentre el sistema, ésta asignación varía, acoplándose a su cambiante entorno. Con esto se hace flexible la manera en que se transmite la información ya que no se restringe a un valor estático, además existe un rango que acota las frecuencias en las que se puede transmitir, de esta manera podemos contar con varias opciones para la transmisión de la tarea, así se puede garantizar que ya sea más rápido o más lento se seguirá transmitiendo la información. Cabe mencionar que dentro del sistema de control distribuido hay varios planificadores locales (agentes), los cuales en conjunto realizan la planificación total del sistema, característica fundamental de los sistemas multi-agente reactivos. Se propone una arquitectura multi-agente, donde los agentes son reactivos, combinada con una arquitectura de pizarra. Lo anterior dada la naturaleza distribuida del problema y considerando el entrono dinámico. En este caso se considera un contenedor de datos que cambia continuamente debido a la interacción de los agentes y el entorno, producto de la percepción local de los agentes, y el cual refleja el estado en el cual se encuentra el sistema. La arquitectura de pizarra permite visualizar las soluciones parciales en el camino a la solución global del sistema, estas soluciones son las que van aportando cada uno de los agentes al realizar una selección para cada tarea en cada participación. Dentro de los esquemas de pizarras se eligió la configuración full-fledged (Ver capítulo 2, sección 2.5), ya que requerimos que los agentes sean independientes en su funcionamiento, es decir, si alguno de ellos deja de funcionar no implica que los demás hagan lo mismo. Dada la integración de un parámetro que permite diferenciar los distintos estados de fallas en los que se puede encontrar el Sistema (con o libre de fallas), la planificación de las tareas realizada por cada agente es en instantes de tiempo diferentes por lo que se garantiza que no existe conflicto entre agentes al seleccionar una frecuencia. El sistema tolerante a fallas propuesto en este trabajo maneja dos tipos de fallas conocidas, la que produce el sensor 1 y la que produce el sensor 2, sin embargo para manejar cualquier tipo de falla se propone integrar un clasificador de fallas el cual al comunicarse con los agentes les indique si la falla ocurrida es conocida y/o crítica, y dependiendo de las características de la falla sea la manera de actuar de


Pág. 66

los agentes. Para esto solo hay que incrementar el nivel de competencia de los agentes, es decir, hacerlos cada vez más expertos (agrandar su fuente de conocimiento). Es importante hacer notar que la integración del clasificador arriba mencionado no altera el algoritmo de planificación dinámica, simplemente es un módulo adicional compatible, ya que su salida es un parámetro que indica el estado del sistema y actualmente es la entrada al planificador dinámico. La naturaleza de un agente lleva a pensar en una programación orientada a objetos, sin embargo la herramienta XPC Target utilizada para ejecutar el sistema en tiempo real, no soporta programas en C++, por lo que se optó por realizar la programación del sistema multi-agente en C, manteniendo el comportamiento de un agente basado en un análisis conceptual previo. Por otro lado el sistema multi-agente garantiza enviar la información, tareas y mensajes para la comunicación entre agentes, sin embargo quien garantiza el hecho de que la información llegue a su destino es el protocolo de comunicación que se está utilizando, en este caso Ethernet (UDP) y CANBus. En el caso de Ethernet el protocolo debe ser completado para transmitir correctamente el dato, en el caso de CANBus el dato se pone en el bus de datos y mediante un identificador los demás procesadores identifican y obtienen el dato que les interesa, por lo que para garantizar que la información enviada por el planificador llegue a su destino en el caso de que algún procesador deje de funcionar, se recomienda dejar de utilizar Ethernet (UDP) y generalizar el protocolo CANBus en toda la red. Al realizar pruebas con el planificador integrado a la planta se plantearon diversos escenarios analizando las tareas considerando: 1) cambios de frecuencias en ambientes libres de fallas, con fallas poco frecuentes, 2) con fallas constantes, también se analizaron los escenarios , 3) con fallas introduciendo un cambio continuo y rápido en la asignación de frecuencias y 4) los que una vez que fue asignada la frecuencia se mantuvo, con el fin de visualizar el impacto que pudiese producir un escenario caótico en dónde se planifica de forma dinámica con cambios muy rápidos en la frecuencia de transmisión. Comparando la señal del error del escenario con manejo de fallas manteniendo la frecuencia asignada, con el que maneja fallas con asignación de frecuencias constante, se puede visualizar como el error se suaviza de manera considerable si se mantiene la asignación de la frecuencia asignada. Este resultado es muy importante ya que el error se proyecta directamente en la estabilidad del sistema lo cual es el principal objetivo de la planta de control. También se observó que al incrementar el número de fallas el sistema sigue teniendo el mismo comportamiento. Por lo que el hecho de que se presenten fallas constantes no altera el funcionamiento del sistema. Esto tendría un impacto en el caso de que el cambio de frecuencia se hiciera cada tiempo de muestreo y aún en


Pág. 67

ese caso, aunque el error se incrementa el controlador lo compensa y mantiene la estabilidad. Esto se puede observar con el escenario que maneja fallas con asignación de frecuencias constante.

APÉNDICE A ________ Programas

Pág. 68

/* File : schedule.c * Abstract: This program schedule frequencies of a Band Width for several tasks * * * This program was developed by Tzitziki Ramírez González. * Directors: Hector Benitez Pérez - Ana Lilia Laureano cruces * ( IIMAS-UNAM ) - (UAM-AZCAPOTZALCO). * november of 2006. */ #define S_FUNCTION_LEVEL 2 #define S_FUNCTION_NAME schedule #define nPortsIn 9 #define nPortsOut 9 #define nMaxTask 3 //for full system #define nMaxBW 7 /* * Need to include simstruc.h for the definition of the SimStruct and * its associated macro definitions. */ #include "simstruc.h" #include "math.h" /************** Atributes from the Scheduler Agent **********************/ struct scheduler { double BW[10][10]; double prior[10][10]; }sch; /********** End of the Atributes from the Scheduler Agent ***************/ /************************ Support Functions *****************************/ /* Function: GetTask ===================================================== *Abstract: * Get data from the especified port of the S-Function */ InputRealPtrsType GetTask(SimStruct *S,int_T Port) { InputRealPtrsType Task; return Task = ssGetInputPortRealSignalPtrs(S,Port); } /* Function: IncreseClock ===================================================== *Abstract: * Increse the value of the Clock */ double * IncreseClock(SimStruct *S, InputRealPtrsType Task, int_T Port) { int_T i; double *y; int_T width; width = ssGetOutputPortWidth(S,Port); y = (double *)ssGetOutputPortSignal(S,Port); for (i=0; i<width; i++)


Pág. 69

{ y[i]=1+(*Task[i]); } return y; } /* Function: InitBB ===================================================== *Abstract: * Initialize the Band Width register * column 0-Band Width, 1-Task, 2- Used by n Agent * Task go from 0 to n, -1 indicate that tne BW is * available * Initialize the priorities register where: * column 0-Task, 1-Port, 2- min band width for transmition * 3-max band width for transmition, 4 duration */ void InitBB(void) { sch.BW[0][0]=1; sch.BW[0][1]=2; sch.BW[0][2]=3; sch.BW[0][3]=5; sch.BW[0][4]=6; sch.BW[0][5]=8; sch.BW[0][6]=10; sch.BW[1][0]=-1; sch.BW[1][1]=-1; sch.BW[1][2]=-1; sch.BW[1][3]=-1; sch.BW[1][4]=-1; sch.BW[1][5]=-1; sch.BW[1][6]=-1; sch.BW[2][0]=-1; sch.BW[2][1]=-1; sch.BW[2][2]=-1; sch.BW[2][3]=-1; sch.BW[2][4]=-1; sch.BW[2][5]=-1; sch.BW[1][6]=-1; sch.prior[0][0]=0; sch.prior[0][1]=1; sch.prior[0][2]=2; sch.prior[0][3]=3; sch.prior[0][4]=4; sch.prior[0][5]=5; sch.prior[1][0]=0; sch.prior[1][1]=-1; sch.prior[1][2]=-1; sch.prior[1][3]=-1; sch.prior[1][4]=-1; sch.prior[1][5]=-1;


Pág. 70

sch.prior[2][0]=1; sch.prior[2][1]=1; sch.prior[2][2]=1; sch.prior[2][3]=1; sch.prior[2][4]=1; sch.prior[2][5]=1; sch.prior[3][0]=10; sch.prior[3][1]=10; sch.prior[3][2]=10; sch.prior[3][3]=10; sch.prior[3][4]=10; sch.prior[3][5]=10; sch.prior[4][0]=5000;// sch.prior[4][1]=20; sch.prior[4][2]=30; sch.prior[4][3]=40; sch.prior[4][4]=50; sch.prior[4][5]=60; } /****************** End of the Support Functions *************************/ /************ Capabilities tha have the Transmition Agent ****************/ /* Function: Transmit ===================================================== *Abstract: * Transmit data through the desired Port of the S-Function */ void Transmit(SimStruct *S, InputRealPtrsType Task, int_T Port) { int_T i; double *y; int_T width; width = ssGetOutputPortWidth(S,Port); y = (double *)ssGetOutputPortSignal(S,Port); for (i=0; i<width; i++) { y[i]=(*Task[i]); } } /********** End of the Transmition Agent Capabilities **************/ /************ Capabilities tha have the Scheduler Agent *****************/ /* Function: SendMail ===================================================== *Abstract: * Send a message to the mail(through a specific port). */ void SendMail(SimStruct *S,int_T Msg,int_T Port) { double *y; y = (double *)ssGetOutputPortSignal(S,Port); y[0]=Msg; } /* Function: CheckMail =====================================================


Pág. 71

*Abstract: * Check a message from the mail (through a specific port). */ double CheckMail(SimStruct *S,int_T Port) { InputRealPtrsType Task; Task=GetTask(S,Port); return (double)(*Task[0]); } /* Function: SelectBW ===================================================== *Abstract: * Analyze the Blackboard to get a suitable Band Width to transmit the task. * It depends from the priority and the minimum and maximum Band With in * which the task must be transmited. * Returns the bandwith or -1 if there's no a suitable Band Width */ int_T SelectFrc(SimStruct *S,int_T PriorityTask) { int_T i,j,k; int_T Mail_Port; double Mail_Msg; for(j=4;j<6;j++) { Mail_Port=j; Mail_Msg=CheckMail(S,Mail_Port); if(Mail_Msg>0) for(i=0;i<nMaxBW;i++) if(sch.BW[0][i]==Mail_Msg) sch.BW[1][i]=111; // The bandwidth is busy } for(i=0;i<nMaxTask;i++) if(PriorityTask==sch.prior[0][i]) if(sch.prior[1][i]>-1) for(k=0;k<nMaxBW;k++) if(sch.BW[1][k]==-1 && sch.BW[0][k]>=sch.prior[2][i] && sch.BW[0][k]<=sch.prior[3][i]) { sch.BW[1][k]=PriorityTask; return (sch.BW[0][k]); } return -1; } /* Function: ModifyBW ===================================================== *Abstract: * Modify the Band Width where the task must be transmited */ void ModifyFrc(SimStruct *S,InputRealPtrsType Task, int_T Frc,int_T Port,double *y) { double pulseTime; // it's the width of the pulse pulseTime=1; Transmit(S,Task,Port); } /********** End of the Scheduler Agent Capabilities **************/


Pág. 72

/**********************Tasks**************************************/ /* Function: TransmitionTask ===================================================== *Abstract: This is the algorithm of the dynamic scheduler * */ void TransmitionTask(SimStruct *S,double *y,int_T PriorityTask,int_T Port) { InputRealPtrsType Task; int_T k; double Frc, FrcT2, FrcT3,tmp,aux; double fault, bf_fault; tmp=0; aux=0; Frc=0; FrcT2=0; FrcT3=0; fault=2; // there´s no fault bf_fault=2; Task=GetTask(S,Port); if(y[0]>1) { tmp=(int_T)(CheckMail(S,6)); if(tmp>0) { for(k=0;k<nMaxBW;k++) if(sch.BW[0][k]==tmp) { sch.BW[1][k]=111; aux=1; } } } bf_fault=(int_T)(*GetTask(S,7)[0]); if((bf_fault==1)||(int_T)(*GetTask(S,6)[0])==0) // this is for the agent 1, it means that occurs the fault 1 { // fault=1, occurs the fault 1 and acts the agent 1; // fault=2, there´s no fault and acts the agent 2 // fault=3, occurs the fault 3 and acts the agent 3 if((int_T)(CheckMail(S,8))==0) { Frc=SelectFrc(S,PriorityTask); FrcT2=(int_T)(CheckMail(S,4)); FrcT3=(int_T)(CheckMail(S,5)); if(Frc==FrcT2 || Frc==FrcT3) Frc=SelectFrc(S,PriorityTask); SendMail(S,0,6); SendMail(S,Frc,6); SendMail(S,1,7); } } else { if(aux==1)


Pág. 73

Frc=tmp; SendMail(S,0,7); } ModifyFrc(S,Task,Frc,Port,y); } /**********************End of Tasks***************************************/ /************************ S-Function Functions ***************************/ /* Function: mdlInitializeSizes =========================================== * Abstract: * The sizes information is used by Simulink to determine the S-function * block's characteristics (number of inputs, outputs, states, etc.). */ static void mdlInitializeSizes(SimStruct *S) { int_T i; if (!ssSetNumInputPorts(S, nPortsIn)) return; for (i=0; i<nPortsIn; i++) { ssSetInputPortWidth(S, i, DYNAMICALLY_SIZED); ssSetInputPortDirectFeedThrough(S, i, 1); } if (!ssSetNumOutputPorts(S, nPortsOut)) return; for (i=0;i<nPortsOut;i++) ssSetOutputPortWidth(S, i, DYNAMICALLY_SIZED); ssSetNumSampleTimes(S, 1); /* Take care when specifying exception free code - see sfuntmpl_doc.c */ ssSetOptions(S, SS_OPTION_WORKS_WITH_CODE_REUSE | SS_OPTION_EXCEPTION_FREE_CODE | SS_OPTION_USE_TLC_WITH_ACCELERATOR); } /* Function: mdlInitializeSampleTimes ========================================= * Abstract: * This function is used to specify the sample time(s) for your * S-function. You must register the same number of sample times as * specified in ssSetNumSampleTimes. */ static void mdlInitializeSampleTimes(SimStruct *S) { ssSetSampleTime(S, 0, INHERITED_SAMPLE_TIME); ssSetOffsetTime(S, 0, 0.0); ssSetModelReferenceSampleTimeDefaultInheritance(S); } /* Function: mdlOutputs ======================================================= * Abstract: * This function describe the algorit used to made the dinamic schedule */ static void mdlOutputs(SimStruct *S, int_T tid) { double *y;


Pág. 74

InputRealPtrsType counter; InitBB(); counter=GetTask(S,2); y=IncreseClock(S,counter,2); TransmitionTask(S,y,0,0); } /* Function: mdlTerminate ===================================================== * Abstract: * In this function, you should perform any actions that are necessary * at the termination of a simulation. For example, if memory was * allocated in mdlStart, this is the place to free it. */ static void mdlTerminate(SimStruct *S) { } /****************** End of the S-Funtion Functions *************************/ #ifdef MATLAB_MEX_FILE /* Is this file being compiled as a MEX-file? */ #include "simulink.c" /* MEX-file interface mechanism */ #else #include "cg_sfun.h" /* Code generation registration function */ #endif

APÉNDICE B _ _______ Diagramas de la planta

Corriente de la Bobina Tarea 1

Diagrama de la etapa I. Obtención de datos

Pág. 75


Estado del Sistema Tarea 2

Diagrama de la etapa II. Controlador

Pág. 76


Diagrama de la Etapa II. Controlador. Takagi Sugeno

Pág. 77


Diagrama de la Etapa III. Interfaz con la Planta.

Pág. 78


Diferencia entre el valor de la corriente medida y los límites en los que se encuentra acotada (0-3A) Tarea 3

Diagrama de la Etapa III. Interfaz con la Planta. Maglev Systm Actual Plant

Pág. 79


Diagrama de la Etapa III. Interfaz con la Planta. Maglev Actual Plant

Pág. 80

________ Referencias

Pág. 81

REFERENCIAS [1] Abdelzaher T., Stankovic J., Lu C., Zhang R., Lu Y., Feedback performance

control in software services, Control Systems Magazine IEEE, Vol. 23 No. 3, pp.74-90, (2003).

[2] Cervin A., Henriksson D., Lincoln B., Eker J., Arzén K., How does Control

Timing Affect Performance (Analysis and Simulation of Timing Using Jitterbug and True Time), Control Systems Magazine IEEE, Vol. 23 No. 3, pp. 16-30, (2003).

[3] Laureano-Cruces A., Barceló-Aspeitia A., Formal Verification of multi-agent

systems behaviour emerging from cognitive task analasys, Journal of Experimental & Theorical Artifitial Inteligence, Vol. 15 No. 4, pp. 407-431, (UK,2003).

[4] Segarra-Martínez M., De Antonio-Bermejo A., Clavijo-Blazquez J., Sanz-Bravo

R., Influencia de la Arquitectura en los Sistemas de Control Inteligente. Revista Iberoamericana de Inteligencia Artificial, No.10, pp. 76-81, (2000).

[5] Laureano-Cruces A., Espinosa-Paredes G., Behavioral design to model a

reactive decision of an expert in geothermal wells, International Journal of Aproximate Reasoning Vol.39, pp. 1-28, (2005).

[6] Frey D., Nimis J., Wörn H., Lockermann P., Benchmarking and Robust multi-

agent –based production planning and control, Engineering Applications of artifitial Inteligence Vol.16 , pp. 307-320, (2003).

[7] Benítez-Perez H., García-Nocetti F., Reconfigurable distributed control

using smart peripheral elements, Control Engineering Practice II pp. 975-988, (2003).

[8] García-Zavala A., Propuesta de un método de planificación para la

reconfiguración en línea de un sistema de tiempo real, Tesis, Maestría, Posgrado en Ciencia e Ingenieria de la Computación ( UNAM, 2003).

[9] Liu Jane W.S., Real Time Systems, Prentice Hall (2000). [10] Jennings N., Bussmann S., Agent.Based, Control Systems (Why are they

suited to Engineering Complex Sytems), Control Systems Magazine IEEE Vol.23 No.3, pp.61-73, (2003).

[11] Ong L., An Investigation of an agent-based scheduling in decentralised

manufacturing control . Tesis, Universidad de Cambridge (2003).


Pág. 82

[12] Saavedra-Hernandez H., Propuesta de un algoritmo genético para la reconfiguración en lìnea de un sistema de tiempo real basado en RT-CORBA. Tesis, Maestría, Posgrado en Ciencia e Ingenieria de la Computación, UNAM (2005).

[13] Low S., Paganini F., Doyle J. Internet Congestion Control, Control Systems

Magazine IEEE, Vol. 22 No. 1, pp. 28-43 (2002). [14] Almeida L., Pedreiras P., Fonseca J., The FTT-CAN Protocol: Why and How.

IEEE Transactions on Industrial Electronics, Vol. 49 No. 6, pp. 1189-1201,(2002).

[15] Corkill D., Collaborating Software: Blackboard and Multi-Agent Systems & the Future, In Proceedings of the International Lisp Conference, New York, New York (2003). [16] Mauro-Santos M., Almeida L., Fuertes J., Design Space of a Dual-Rate

Switching Controller, Submitted to the 7th Portuguese Conference on Automatic Control- CONTROLO (Lisboa Portugal, 2006)

[17] Antunes A., Pedeiras P., Mota A., Adapting the sampling Period of a Real-

Time Adaptive Distributes Controller to the Bus Load. CONTROLO 2006, CDROM

[18] Quiñones-Reyes P., Benitez-Pérez H., Mendez-Monroy E., Cardenas-Flores

F., García-Nocetti F., Reconfigurable Network Control using Fuzzy Logic for Magnetic Levitation Case Study. IFAC SAFEPROCESS (2006).

[19] Quiñones-Reyes P., Benitez-Pérez H., Mendez-Monroy E., Cardenas-Flores

F., García-Nocetti F., Reconfigurable Fault Tolerant PID Networked Control for Magnetic Levitation Case Study. ISSADS 2006, Lecture Notes on Computer Cience (2006).

[20] Benitez-Pérez H., Quiñones-Reyes P., Cardenas-Flores F., García-Nocetti F.,

Reconfigurable Networked Fuzzy Takaji Sugeno Control for Magnetic Levitation Case Study. MICAI, Lecture Notes on Computer Cience (2006).

[21] Abonyi J.; Fuzzy Model Identification for Control; Birkhäuser, (2003). [22] Benítez-Pérez, H., Cardenas-Flores, F. y García-Nocetti, F.; Reconfigurable

Takagi-Sugeno Fuzzy Logic Control for a Class of Nonlinear System considering Communication Time Delays; Accepted paper for the International Conference on Control. (UK, 2006).


Pág. 83

[23] Laureano-Cruces A., Arriaga-Gómez F. y García-Alegre M., Cognitive Task Analysis: a proposal to model reactive behaviours, In Journal of Experimental & Theoretical Artificial Intelligence. Vol.13, p.p.227-239. (UK, 2001).

[24] Benítez-Pérez, H., Cardenas-Flores, F. y García-Nocetti, F.; Reconfigurable

Takagi-Sugeno Fuzzy Logic Control for a Class of Nonlinear System considering Communication Time Delays; Accepted paper for the International Conference on Control. (UK, 2006).

UNIVERSIDAD AUTÓNOMA METROPOLITANAnewton.azc.uam.mx/mcc/02_ingles/11_tesis/tesis/... ·...

Documents

Transcript of UNIVERSIDAD AUTÓNOMA METROPOLITANAnewton.azc.uam.mx/mcc/02_ingles/11_tesis/tesis/... ·...