metodología de codiseño hw/sw para la implementación de

METODOLOGÍA DE CODISEÑO HW/SW PARA LA IMPLEMENTACIÓN DE
CONTROLADORES DIFUSOS
A. CABRERA1, S. SÁNCHEZ-SOLANO2, R. SENHADJI2, A. BARRIGA2 y C.J. JIMÉNEZ2
1
Dpto. Automática y Computación. Facultad de Ingeniería Eléctrica. Instituto Superior
Politécnico “José Antonio Echeverría”, Ciudad de la Habana, Cuba.
2
Instituto de Microelectrónica de Sevilla. Centro Nacional de Microelectrónica, Avda.
Reina Mercedes s/n, 41012-Sevilla, España.
RESUMEN
En esta comunicación se describe una metodología de
codiseño HW/SW para la implementación de controladores difusos utilizando microcontroladores de propósito
general y elementos específicos de procesado construidos
mediante FPGAs o ASICs. Se exponen las diferentes
fases de la metodología, así como las herramientas de
CAD utilizadas para el desarrollo de las mismas, con
énfasis en el entorno de desarrollo de sistemas difusos
Xfuzzy. Por último, se incluye una aplicación práctica de
la metodología descrita al diseño de un controlador difuso
para un sistema de dosificación.
1. INTRODUCCIÓN
Al explorar el espacio de diseño de un sistema electrónico
de cierta complejidad siempre surgen dos alternativas
contrapuestas. Por un lado, el empleo de componentes
estándares cuya funcionalidad puede ser definida
mediante programación. Por otro, la implementación de
dicha
funcionalidad
mediante
un
circuito
microelectrónico específicamente construido para la
aplicación. Es bien conocido que la primera alternativa
(alternativa software) proporciona soluciones que
presentan una gran flexibilidad a pesar de requerir
consumos de área y tiempos de ejecución elevados,
mientras que la segunda (alternativa hardware) optimiza
los aspectos de tamaño y velocidad de operación a costa
de limitar la flexibilidad de la solución. A medio camino
entre ambas, las técnicas de codiseño hardware/software
(HW/SW) pretenden obtener un compromiso adecuado
entre las ventajas e inconve-nientes de estas dos
aproximaciones.
En esta comunicación se describe una metodología de
codiseño HW/SW para la implementación de sistemas de
control basados en lógica difusa, ilustrando la aplicación
de la misma a un caso práctico al abordar el desarrollo de
un controlador difuso para un sistema de dosificación.
En la Sección 2 se exponen algunas alternativas de
codiseño para la implementación de controladores
difusos. En la Sección 3 se detallan las diferentes fases
de la metodología propuesta. En la Sección 4 se describe
un caso práctico de aplicación de la metodología.
Finalmente, en la Sección 5 se resaltan los conclusiones
fundamentales de esta comunicación.
2. ALTERNATIVAS DE CODISEÑO
En todo proceso de codiseño de un sistema deben
analizarse las tareas a realizar, evaluando la repercusión
de las posibles opciones de implementación de cada tarea
sobre los parámetros que definen la funcionalidad y el
coste del sistema global. Los principales parámetros a
considerar en esta evaluación son la velocidad de
ejecución de la tarea y el área que conllevaría su
implementación hardware. A partir de los resultados de
este análisis se realiza el proceso de particionado el cual
consiste en decidir qué tareas deben ser realizadas
mediante software y cuáles deben ser implementadas
sobre hardware.
Existen diferentes estrategias para abordar el
codiseño de sistemas de control basados en lógica difusa,
que se distinguen entre sí por la forma en que realizan el
particionado HW/SW. Una de ellas consiste en analizar la
influencia del repertorio de instrucciones de un
procesador sobre la implementación de un sistema de
inferencia difuso, rediseñándolo de forma tal que soporte
aquellas operaciones que contribuyan en mayor medida al
incremento de la velocidad de inferencia [1-3]. De esta
forma el particionado se realiza al nivel de las
instrucciones del procesador.
Otra alternativa consiste en implementar el sistema
de inferencia, total o parcialmente, mediante hardware
dedicado con una arquitectura específica. Esta partición
a priori se basa en el hecho de que, de todas las tareas
que debe realizar un sistema de control basado en lógica
difusa, son los procesos relacionados con el cálculo de la
inferencia difusa los que mayor tiempo consumen [2]. Por
lo tanto la implementación de los mismos mediante un
hardware específico contribuirá significativamente al
incremento de la velocidad del controlador.
Es precisamente esta variante de codiseño la
abordada en el presente trabajo, donde la implementación
hardware del sistema de inferencia se lleva a cabo
mediante una arquitectura específica para sistemas
difusos que permite obtener realizaciones eficientes (en
términos de área y velocidad) basadas en el procesado de
reglas activas, la limitación a dos del grado de
solapamiento de las funciones de pertenencia de las
entradas y la utilización de métodos de defuzzificación
simplificados [4-6].
DESCRIPCIÓN
SIMULACIÓN
VERIFICACIÓN ON-LINE
PARTICIONADO HW/SW
IMPLEMENTACIÓN
HARDWARE
DESARROLLO
SOFTWARE
3. METODOLOGÍA DE CODISEÑO
Las diferentes fases de la metodología de codiseño para la
implementación de controladores difusos se muestran en
la Figura 1. Para la ejecución de cada una de las fases se
utilizan las herramientas de CAD incluidas en el entorno
de desarrollo de sistemas difusos Xfuzzy [6,7]. Dicho
entorno, que puede ser ejecutado sobre plataformas con
sistema operativo Unix o Windows, agrupa un conjunto
de herramientas que facilitan las diferentes etapas de
descripción, verificación y síntesis (tanto software como
hardware) de sistemas difusos.
En los siguientes apartados se describen las
caracterís-ticas más sobresalientes de cada fase de diseño
y se comentan las herramientas de CAD utilizadas así
como los detalles de implementación.
3.1. Fase de Descripción
Durante esta fase se realiza la descripción del sistema
de inferencia difuso que define la operación (estrategia de
control) del controlador. Para ello se emplea el lenguaje
de especificación de sistemas difusos XFL [6,8]. Este
lenguaje, utilizado por todas las herramientas de Xfuzzy,
permite definir los universos de discurso y las funciones
de pertenencia de las entradas y salidas del controlador,
la especificación de la base de reglas y la selección de los
diferentes operadores difusos utilizados como conectivos
de antecedentes, función de implicación y mecanismo de
agregación de reglas, así como el método de defuzzificación a utilizar.
Esta descripción es almacenada en un fichero de
texto (.xfl) siguiendo las reglas sintácticas del lenguaje
XFL. Dicho fichero puede generarse mediante un editor
VALIDACIÓN
Figura 1. Metodología de codiseño.
convencional o utilizando las diferentes opciones de
edición proporcionadas por el entorno gráfico de Xfuzzy.
3.2. Fase de Simulación
En esta fase se realiza una simulación off-line del
comportamiento del sistema de inferencia difuso sobre el
proceso a controlar con el objetivo de realizar un ajuste
preliminar de los parámetros del controlador. Para ello se
requiere de un modelo del proceso, descrito mediante
lenguaje C, y de una herramienta de simulación. La
herramienta xfsim [6] es la encargada de realizar esta
tarea dentro del entorno de desarrollo Xfuzzy.
Aunque esta fase de simulación permite un primer
ajuste de los parámetros del sistema de inferencia, debe
tenerse muy presente que sus resultados son solo
aproximados dadas las limitaciones del modelo utilizado
para representar al proceso. Por tal motivo, para un ajuste
más preciso de los parámetros del sistema de inferencia se
requiere de una interacción del mismo con el proceso
real. Este es el objetivo de la siguiente fase.
3.3. Fase de Verificación on-line
La característica fundamental de esta fase es la inclusión
del proceso real en el lazo de control, de forma que se
pueda obtener el ajuste óptimo de la base de conocimiento
del controlador difuso. Por supuesto, como el sistema de
inferencia será implementado finalmente mediante
hardware, los parámetros del mismo deben satisfacer las
restricciones impuestas por la arquitectura utilizada. Por
la misma razón, en esta fase, no solo debe evaluarse el
comportamiento del controlador con diferentes bases de
conocimiento, sino que también debe analizarse la
influencia de utilizar diferentes resoluciones en cuanto al
número de bits con que se representan los parámetros del
sistema.
Por otra parte, la interacción con el proceso real
requiere de elementos adicionales a los empleados en la
fase de simulación. Entre ellos estarán los elementos de
interfaz con los sensores y actuadores del proceso
(amplificadores de señal, convertidores A/D y D/A, etc.)
así como las rutinas de pre- y post-procesado necesarias
para obtener las entradas y generar las salidas del
controlador.
Para desarrollar esta fase se requiere de una
herramienta de CAD que implemente, mediante software,
el sistema de inferencia difuso, así como las rutinas de
pre- y post-procesado, y permita interactuar con el
proceso real a través de una tarjeta de adquisición de
datos. El entorno de desarrollo Xfuzzy dispone para esta
fase de la herramienta xflab [6,9].
Xflab permite el desarrollo integral de un controlador
difuso implementado en software. Con ella el modelo del
proceso utilizado en la fase de simulación se reemplaza
por una función que monitoriza el proceso real (a través
de la tarjeta de adquisición de datos), realiza la inferencia
y actúa sobre el proceso. Simultáneamente va registrando
las variables del sistema que se hayan seleccionado para
su posterior procesado con el objetivo de determinar el
mejor ajuste de los parámetros del controlador.
Xflab facilita la configuración de la tarjeta de
adquisición de datos (establecimiento de direcciones de
entrada/salida, asignación de canales análogicos y digitales, etc.), la codificación de las rutinas de procesado de
la información (filtrado, linealización, etc.) y la
definición de los parámetros de control que se deseen
(intervalo de muestreo, señales que serán registradas para
evaluar el comportamiento del controlador, etc.).
Una vez definida la configuración del sistema, xflab
invoca a otra herramienta de Xfuzzy (xfc) encargada de
obtener el código C del sistema de inferencia, combina
dicho código con el correspondiente a las rutinas de prey post-procesado y las de monitorización y control y los
compila y enlaza para obtener un fichero ejecutable que
corresponde a la implementación software del controlador
difuso.
Siguiendo este procedimiento resulta muy sencillo
modificar los parámetros del controlador (modificando la
especificación
XFL),
así
como
registrar
el
comportamiento del sistema, lo que permite evaluar
diferentes condiciones de operación con el objetivo de
obtener la mejor aproximación para la implementación
del sistema.
A diferencia de la fase de simulación que solo
permite el ajuste preliminar del sistema de inferencia, la
fase de verificación on-line permite comprobar y ajustar
la operación global del controlador difuso. No obstante,
debe tenerse presente que, como consecuencia de las
diferentes precisiones con que se realiza la inferencia por
software y por hardware, es posible que se requiera un
último ajuste de los parámetros del controlador difuso
durante la fase final de validación del sistema de control.
Al concluir esta etapa se dispone de una implementación software del controlador difuso completamente
operativa, la cual constituye el punto de partida de la
siguiente fase de identificación de tareas del sistema y
particionado de las mismas.
3.4. Fase de Particionado
Aunque las tareas específicas que debe realizar un
controlador difuso dependen finalmente de la aplicación
para la cual está siendo diseñado, dichas tareas suelen
coincidir con las tareas generales que se relacionan a
continuación:
a) Inicialización del sistema
b) Determinación del objetivo
c) Lectura de los sensores del sistema a controlar
d) Preprocesado de la información
e) Determinación de las entradas al sistema de
inferencia
f) Cálculo de la inferencia difusa
g) Procesado de la salida del sistema de inferencia
h) Generación de las señales de control para los
actuadores del sistema.
Concurrentemente con estas tareas debe incluirse la
de temporización del sistema, encargada de establecer el
periodo de muestreo de las señales provenientes de los
sensores. Por último, también deben incluirse en la lista
de tareas los mecanismos de monitorización de las
variables del controlador que faciliten la fase de
validación final del sistema. La forma usual de acometer
esta tarea es ir registrando en ficheros la información
seleccionada.
Una vez establecidas las tareas a realizar se procede a
efectuar el proceso de particionado HW/SW. De acuerdo
con las consideraciones de la Sección 2 el sistema de
inferencia será implementado mediante hardware. Las
restantes tareas deben ser evaluadas para obtener el mejor
compromiso entre velocidad y flexibilidad, aunque, en la
gran mayoría de los casos, la implementación software de
las mismas proporciona un resultado muy satisfactorio.
Por último, es necesario considerar la implementación de
los diferentes elementos que faciliten la interconexión de
los componentes hardware y software, la temporización
global del sistema y los mecanismos de monitorización.
Un aspecto clave en esta etapa de diseño es la
selección de las plataformas en donde serán ejecutadas las
tareas, es decir, el tipo de procesador en donde se
ejecutarán las tareas de software y el dispositivo hardware
sobre el que será implementado el sistema de inferencia.
La disponibilidad de placas de desarrollo que incluyen un
microcontrolador de propósito general y una FPGA
permite compartir entre ambos componentes la funcionalidad requerida por los controladores difusos a desarrollar
mediante la presente metodología. Así, el cálculo de la
inferencia difusa se asignará a un controlador de
propósito específico construido sobre la FPGA, mientras
que las rutinas de procesado de las entradas y salidas del
sistema de inferencia, así como el resto de las tareas, se
programarán en el microcontrolador. El proceso de
temporización será implementado utilizando uno de los
temporizadores disponibles en el microcontrolador. Por
supuesto, para completar el controlador será necesario
añadir los circuitos necesarios para adaptar las señales
utilizadas por los sensores y actuadores a las empleadas
en la placa de desarrollo (amplificadores de señal,
converti-dores A/D y D/A, etc.).
3.5. Fase de Implementación Hardware
Para el desarrollo de esta fase es necesario contar con
herramientas de CAD que trasladen la especificación del
sistema de inferencia en un código sintetizable, basado en
un lenguaje de descripción de hardware y acorde con la
arquitectura descrita en [4-6]. La característica más
sobresaliente del entorno de desarrollo Xfuzzy sobre otros
similares es la inclusión de herramientas que facilitan la
síntesis hardware del sistema de inferencia. Una de ellas
es xfvhdl [6,10], que permite obtener la descripción
VHDL de un sistema de inferencia a partir de su
especificación XFL. Dicha descripción es compatible con
diferentes herramientas de síntesis hardware para FPGAs
o ASICs. Como comentamos en la Sección anterior, el
uso de FPGAs resulta especialmente adecuado para
realizar un primer prototipo del sistema bajo desarrollo.
Nótese que la FPGA no solo debe contener el sistema
de inferencia sino también los elementos de interfaz de
entrada /salida entre éste y el microcontrolador, así como
otros elementos que pudiesen ser necesarios por las
características de la placa de desarrollo o del propio
sistema de control.
3.6. Fase de Desarrollo Software
Durante esta fase se desarrollan las diferentes rutinas que
dan soporte a las tareas que serán implementadas
mediante software. Para la puesta a punto de las mismas
se utilizan herramientas de desarrollo y depuración de
programas (ensambladores o compiladores, simuladores,
etc.).
Aunque no es imprescindible, es aconsejable que
también se desarrollen un grupo de programas que
permitan el diagnóstico y comprueben la operación de las
diferentes partes del controlador, aspecto que facilitará su
puesta a punto general.
3.7. Fase de Validación
Durante esta fase se procede a la integración de ambas
implementaciones sobre la placa de desarrollo y al ajuste
definitivo de los parámetros del controlador.
Una vez depuradas las diferentes partes del controlador, se procede a la validación integral del mismo.
Para ello se pone en operación el controlador difuso
implementado y se transmite hacia un ordenador personal
el grupo de variables seleccionadas que servirán para
evaluar el comportamiento del sistema. Después, con
ayuda de un paquete de rutinas matemáticas, se pueden
obtener los valores de algunos parámetros (tiempo de
establecimiento, sobreoscilación, tiempo de subida, error
cuadrático medio, etc.) que caractericen la operación del
controlador difuso implementado.
Dada la facilidad con que se pueden realizar las
modificaciones de las tareas que se ejecutan en el
microcontrolador, así como de los parámetros del sistema
de inferencia implementado en la FPGA, pueden
validarse diferentes versiones del controlador con objeto
de seleccionar la que proporcione mejores prestaciones.
4. APLICACIÓN DE LA METODOLOGÍA
Con el objetivo de ilustrar la metodología descrita, en la
presente Sección se expone la aplicación de cada una de
las fases de la misma para la implementación de un
controlador difuso para el sistema real que se describe
brevemente a continuación.
4.1. Descripción del Sistema
El sistema a controlar consiste en la maqueta de un
sistema de dosificación diseñada para experimentar con
distintas estrategias de control basadas en lógica difusa.
La maqueta está formada por dos cubetas independientes
de 120 cm de altura y 20 cm de diámetro. Cada una de
ellas posee una electroválvula en su parte superior para
controlar la entrada de líquido, un sensor de presión en la
parte inferior para proporcionar una medida del nivel de
líquido contenido y una válvula de control manual que
permite verter el líquido de cada cubeta en un recipiente
común. Desde este recipiente el líquido se bombea de
nuevo hacia las cubetas a través de una motobomba
gobernada por un variador de velocidad (Figura 2).
Los sensores de presión proporcionan una salida en
intensidad (4 a 20 mA) para una presión máxima
aproximadamente 10 veces superior a la manejada en el
problema. Las electroválvulas y el variador de velocidad
de la motobomba son controlados por señales de tensión
(0 a 10 V).
(error y variación de error) y proporciona una señal de
salida que representa la variación de la apertura de la
electroválvula o de la velocidad de la motobomba. El
sistema de dos cubetas se puede implementar con dos
controladores independientes que actúan sobre cada
electroválvula mientras que la motobomba es gobernada
por la suma acotada de la salida de ambos controladores.
No obstante, dadas las características de simetría de las
dos cubetas, los controladores difusos de ambas serán
idénticos, por lo que puede utilizarse solo uno si se
ejecutan secuencialmente los procesos de inferencia.
4.2. Detalles de la Implementación
Figura 2. Sistema de dosificación proporcionado
por SUR Automatización y Control.
Esta maqueta permite analizar diversas estrategias de
control. Utilizando tanto una sola cubeta como ambas, se
puede actuar sobre el motor manteniendo la(s) electroválvula(s) abierta(s), sobre la(s) electroválvula(s) con el
motor a velocidad constante, o sobre el motor y la(s)
electroválvula(s) simultáneamente. En todos los casos, el
objetivo del sistema de control será mantener el nivel de
líquido lo más cercano posible al objetivo prefijado. La
estrategia de control aplicada corresponde al equivalente
difuso de un controlador PD incremental. Por lo tanto, el
controlador difuso para una cubeta requiere dos entradas
De acuerdo con la metodología propuesta, se desarrolló
en primer lugar la fase de descripción XFL para el
sistema de inferencia correspondiente a un controlador
difuso PD con salida incremental para una sola cubeta.
Las funciones de pertenencia de las entradas (error y
variación del error) y de la salida (variación del voltaje
aplicado a la electro-válvula) fueron estimadas a partir
del comportamiento del sistema, considerando además las
limitaciones impuestas por la futura implementación
hardware. Por tal motivo se utilizaron 3 funciones de
pertenencia para las entradas, con grado de solapamiento
dos, 5 singletons para la salida y defuzzificación
mediante el método de la media difusa. La Figura 3
muestra estas funciones de pertenencia así como la base
de reglas utilizada.
Posteriormente fue simulado el comportamiento del
sistema mediante xfsim utilizando un modelo
simplificado del proceso. Esta simulación sirvió para un
primer ajuste de la base de conocimiento del sistema de
inferencia.
Un ajuste mucho mejor se obtuvo durante la fase de
verificación on-line al insertar el controlador en el propio
lazo de control. Utilizando xflab se realizaron un total de
27 implementaciones diferentes en donde se modificaron
las funciones de pertenencia de las entradas y la salida.
En cada caso se dejó evolucionar el sistema durante 2000
iteraciones modificándose la posición objetivo automáticamente cada 500 iteraciones. En cada una de las
pruebas se registraron un grupo de variables (error,
variación del error, nivel del líquido, variación de la
salida, etc.) cuyos valores fueron posteriormente
procesados para obtener los parámetros (tiempo de
subida, sobreoscilación, error cuadrático medio, etc.) que
permitieron seleccionar la especificación XFL que presentó mejor comportamiento [11].
Basándose en estos resultados se procedió a
desarrollar, también con xflab, el controlador difuso para
el sistema completo de las dos cubetas, obteniéndose
similares resultados de comportamiento. Además de
obtener la especificación XFL que sería posteriormente
error
N
-50
Z
-15
0
+35
? error
Z
N
-2
P
-0,25
0
+50 cm
P
+0,6
+2 cm
? out
NL
-2
N
Z
P
PL
-0.35
0
+0.35
+2 V
N
error
Z
N
Z
P
PL
Z
N
Z
P
P
NL
N
Z
P
Figura 3. Funciones de pertenencia y base de reglas.
Para minimizar los recursos empleados en la FPGA
disponible se aprovechó la característica de simetría
presente en los controladores de ambas cubetas. Así, se
realizan dos ciclos de inferencia secuencialmente.
En la fase de implementación hardware, la etapa de
síntesis de la FPGA se llevo a cabo con ayuda del entorno
“Xilinx Foundation 3.1i” [13]. La descripción VHDL del
? error
implementada mediante hardware, durante el desarrollo
de esta fase de diseño se identificaron las tareas que debía
acometer el controlador difuso para el control de los
niveles del líquido en ambas cubetas, punto de partida
para el particionado HW/SW.
La plataforma utilizada para la implementación del
controlador fue una placa XS-Board (XS40-005XL, de
XESS Corporation [12]), la cual dispone de un
microcontrolador Intel 8031 y una FPGA Xilinx XC4005, así como de 32 Kbytes de memoria RAM estática,
un circuito de reloj programable y otros dispositivos.
Dispone igualmente de un software de apoyo que permite
realizar las tareas de programación del reloj, descarga de
la configuración de la FPGA y del programa para el
microcontrolador, así como de un test de la placa.
sistema de inferencia fue obtenida a partir de su
especificación XFL utilizando la herramienta xfvhdl.
La resolución de las entradas y la salidas del
controlador se limitó a 6 bits. El controlador empleado
utiliza antecedentes almacenados en memoria y
defuzzificación mediante el método de la media difusa.
Por otra parte, dado que el sistema de inferencia actúa
como un coprocesador del 8031, fue necesario incorporar
también en la FPGA circuitos de interfaz con este
dispositivo, así como aquellos necesarios para acceder a
la memoria. El resultado de la implementación arrojó un
98% de utilización de los CLBs de la FPGA (193 de 196)
y una frecuencia máxima de operación de 20 MHz. A una
frecuencia de 10 MHz (tanto para la FPGA como para el
microcontrolador) el ciclo de inferencia es de 700
nanosegundos, tiempo inferior al de ejecución de una sola
instrucción en el 8031.
El montaje experimental desarrollado consistió en la
placa XS-Board insertada en una placa de montaje que
incluye los elementos de conversión A/D (AD7824) y
D/A (AD7226), así como la circuitería de
acondicionamiento de señal.
La implementación software sobre el 8031 se llevó a
cabo con la ayuda de distintas herramientas de desarrollo
disponibles para la familia MCS-51. El código
programado en el microcontrolador incluye el algoritmo
general del ciclo de adquisición, pre-procesado, obtención
de entradas, comunicación con el motor de inferencia,
post-procesado y generación de la salida del sistema,
junto con numerosas rutinas auxiliares que controlan los
mecanismos de interrupción, de entrada/salida hacia y
desde el motor de inferencia, y de comunicación con un
PC para registrar las variables que permitan validar el
comportamiento del controlador.
Se realizó una primera implementación mediante
codiseño del controlador difuso basándose en la misma
especificación XFL con la cual se obtuvieron las mejores
prestaciones en la fase de verificación. Los resultados
obtenidos, aunque aceptables en general, distaron
bastante de los esperados como consecuencia de la
diferencia de precisión ya señalada entre las inferencias
por software y por hardware. Por lo tanto, después de
analizar el comportamiento del sistema, fue necesario
realizar ajustes adicionales a las funciones de pertenencia
mostradas en la Figura 3. Se realizó nuevamente la
implementación hardware y se validaron los nuevos
resultados, mejores que los anteriores pero aún no tan
buenos como los obtenidos durante la fase de verificación.
Por ello se redujo el tiempo de muestreo a 100
milisegundos (mediante un simple cambio en el programa
del microcontrolador), obteniéndose resultados similares
a los obtenidos mediante el control con xflab. La Figura
4, donde se representa la evolución del nivel de líquido en
una de las cubetas del sistema para distintas posiciones
objetivo, muestra algunos de los resultados
experimentales obtenidos.
1
0
0
.0
8
0
.0
6
0
.0
4
0
.0
5. CONCLUSIONES
Se ha presentado una metodología de codiseño para la
implementación de controladores difusos utilizando
intensivamente las diferentes herramientas incorporadas
en el entorno de desarrollo de sistemas difusos Xfuzzy,
así como los aspectos más relevantes de la aplicación de
la misma a un proceso real. Además de la metodología en
sí, los siguientes aspectos son también relevantes:
1.) Es posible la realización de un controlador difuso
mediante codiseño HW/SW particionando 'a priori' los
procesos que serán ejecutados en ambas plataformas.
2.) El entorno Xfuzzy integra todas las herramientas
necesarias para llevar a cabo el desarrollo total del
sistema de inferencia difusa.
2.) El proceso de ajuste de parámetros de un sistema de
inferencia difuso con xflab para su posterior implementación mediante hardware es adecuado, aunque no está
exento de ajustes posteriores debido a la diferencia de
precisión con que se realiza la inferencia en ambas
aproximaciones.
4.) La implementación de un controlador difuso mediante
codiseño HW/SW utilizando placas de desarrollo
comerciales que incluyen microcontroladores y FPGAs,
en donde el sistema de inferencia actúa como un
coprocesador, constituye una opción muy atractiva por su
combinación de velocidad y flexibilidad.
6. REFERENCIAS
[1] Von Altrock, C. Adapting existing Hardware for Fuzzy
Computation, Institute of Physics Publishing, 1998.
2
0
.0
[2] Salapura, V.: “A Fuzzy RISC Processor”, IEEE
Transactions on Fuzzy Systems, vol. 8, No. 6, Dec. 2000.
0
.0
0
5
0
0
1
0
0
0
1
5
0
0
2
0
0
0
Figura 4. Nivel de líquido en la cubeta 2 vs muestras
(cada muestra equivale a 500 milisegundos).
[3] Ungering, A.P., Bauer, H., Goer, K.: “Architecture of a
Fuzzy Processor Based on an 8-bit Microprocessor”, Proc. IEEE
ICFS´94, Orlando, pag.297-301, 1994.
[4] Jiménez, C.J., Sánchez-Solano S., Barriga, A.: “Hardware
Implementations of a General Purpose Fuzzy Controller”, Proc.
Sixth International Fuzzy Systems Association World Congress
(IFSA´95), Sao Paulo, vol. 2, pag.185-188, Jul.1995.
[5] Sánchez-Solano, S., Barriga, A., Jiménez, C.J., Huertas,
J.L.: “Design and Applications of Digital Fuzzy Controllers”,
Proc. Sixth IEEE International Conference on Fuzzy Systems
(FUZZ_IEEE´97), Barcelona, vol. 2, pag. 869-874, Jul. 1997.
[6] Baturone, I., Barriga, A., Sánchez-Solano, S., Jiménez, C.J.,
López, D.: Microelectronic Design of Fuzzy Logic-Based
Systems, CRC Press, 2000.
[7] López, D.R., Jiménez, C.J., Baturone, I., Barriga, A.
Sánchez-Solano, S.: "Xfuzzy: A Design Environment for Fuzzy
Systems", Proc seventh IEEE International Conference on
Fuzzy Systems, pag. 1060-1065, Anchorage, May 1998.
[10] Lago, E., Jiménez C.J., López D.R., Sánchez-Solano S.,
Barriga A.: “xfVHDL: A Tool for the Synthesis of Fuzzy Logic
Controllers”, Proc. Design, Automation and Test in Europe
(DATE´98), Paris, pag 102-107, Feb. 1998.
[8] López, D.R., Moreno, F.J., Barriga, A. Sánchez-Solano, S.:
"XFL: A Language for the Definition of Fuzzy Systems", Proc.
sixth IEEE International Conference on Fuzzy Systems, Vol. 3,
pag. 1581-1591, Barcelona, Jul 1997.
[11] Cabrera, A., Senhadji, R., Sánchez-Solano, S., Barriga, A.,
Jiménez, C.J., Llanes, O.: "Development of Level Controllers
Based on Fuzzy Logic", Proc. First International ICSC-NAISO
Congress on Neuro Fuzzy Technologies (NF2002), Ciudad de la
Habana, Jan. 2002.
[9] Senhadji, R., Sánchez-Solano, S., López, D.R. Barriga, A.:
"Xflab: An On-line Verification Tool for Fuzzy Controllers",
Proc. International Conference on Information Processing and
Management of Uncertainty in Knowledge Based Systems, Vol.
1, pag. 44-49, Madrid, Jul 2000.
[12] XS40, XSP Board V1.4 User Manual, XESS Corporation,
USA, 1999.
[13] The Programmable Logic Data Book, Xilinx Inc., USA,
1999.