título: función para la obtención de datos de

Título: Función para la obtención de datos de identificación desde el MATLAB

Autor: Javier Alejandro Pérez Pineda

Tutores: Msc. Iván Iglesias Navarro

Dr. Francisco Herrera Fernández

Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

Santa Clara 2013

“Año 55 de la Revolución”

Universidad Central “Marta Abreu” de Las Villas

Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA

Función para la obtención de datos de identificación desde el MATLAB

Autor: Javier Alejandro Pérez Pineda

e-mail: [email protected]

Tutores: Msc. Iván Iglesias Navarro


Dr. Francisco Herrera Fernández


Santa Clara

2013

“Año 55 de la Revolución”

Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta

Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería

en Automática, autorizando a que el mismo sea utilizado por la Institución, para los fines que

estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en

eventos, ni publicados sin autorización de la Universidad.

Firma del Autor

Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la

dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de

esta envergadura referido a la temática señalada.

Firma del Autor Firma del Jefe de Departamento

donde se defiende el trabajo

Firma del Responsable de

Información Científico-Técnica

Dedicatoria

Dedicatoria

A mi madre, por su amor incondicional y su fuerza eterna.

Resumen

Resumen

Actualmente el proceso de Identificación de Sistemas constituye un elemento

fundamental en la obtención de modelos matemáticos, empleados en el campo de la

ingeniería. Una de las vías para optimizar este proceso sería la utilización de un

Sistema Multi-Agente que sustituya la función del ingeniero al seleccionar el mejor

modelo entre los identificados. Con la implementación de este sistema surge la

necesidad de crear una base de datos en la que se apoyaría en el proceso de toma de

decisiones a la hora de seleccionar el modelo válido.

Según tales demandas, la presente investigación propone una función para almacenar

los datos provenientes del proceso de identificación paramétrica en MATLAB en una

base de datos. Para ello, se explota la capacidad del Toolbox de Identificación de

Sistemas de MATLAB de proporcionar los datos que más información brindan acerca

del comportamiento de las diferentes estructuras. Asimismo se utilizó el Toolbox de

Base de Datos de MATLAB, el cual permite establecer una comunicación con el

sistema gestor MySQL, en el cual se crea la base de datos relacional donde se va a

almacenar dicha información.

Se obtiene como resultado la función saveintodb que permite crear la base de datos

relacional MATLAB_DATA en MySQL, así como obtener la información que brinda

MATLAB de los modelos estimados seleccionados por el usuario y exportarla a dicha

base de datos. La cual posee una estructura simple que posibilita el eficiente

almacenamiento y la fácil recuperación de los datos para que sean utilizados en

análisis posteriores.

Palabras claves: IDENTIFICACIÓN DE SISTEMAS, MODELOS, BASE DE DATOS,

FUNCIÓN SAVEINTODB.

Índice

Índice

INTRODUCCIÓN ..................................................................................................................................................... 1

CAPÍTULO 1. COMUNICACIÓN MATLAB-BASE DE DATOS. SU EMPLEO EN LA IDENTIFICACIÓN DE SISTEMAS. . 7

1.1. IDENTIFICACIÓN DE SISTEMAS. ASPECTOS GENERALES ............................................................................................. 7

1.1.1. El procedimiento de identificación ......................................................................................................... 8

1.1.2. El Lazo de Identificación de Sistemas ................................................................................................... 10

1.1.3. Métodos de identificación: paramétrica y no paramétrica. Estructuras de modelos .......................... 11

1.1.4. Validación del modelo .......................................................................................................................... 12

1.2. TOOLBOX DE IDENTIFICACIÓN DE SISTEMAS DE MATLAB ...................................................................................... 13

1.2.1- Aspectos prácticos de interés en el toolbox de Identificación de Sistemas .......................................... 14

1.3. COMUNICACIÓN ENTRE APLICACIONES ............................................................................................................... 17

1.3.1- Comunicación Aplicación-Base de Datos ............................................................................................. 18

1.3.2- El Database Toolbox de MATLAB ......................................................................................................... 20

1.4. SISTEMA DE GESTIÓN DE BASE DE DATOS APROPIADO ............................................................................................ 21

1.4.1- Términos básicos .................................................................................................................................. 22

1.4.2- Nivel de acceso a la base de datos en MySQL ...................................................................................... 24

1.4.3- MySQL Workbench ............................................................................................................................... 26

1.5. CONSIDERACIONES FINALES DEL CAPÍTULO .......................................................................................................... 26

CAPÍTULO 2. SAVEINTODB. FUNCIÓN PARA OBTENER INFORMACIÓN DE MODELOS ESTIMADOS Y

ALMACENARLOS EN LA BASE DE DATOS MATLAB_DATA DE MYSQL. ................................................................... 28

2.1. FUNCIÓN SAVEINTODB. ASPECTOS GENERALES. .................................................................................................... 28

2.1.1. Características de la función saveintodb: ............................................................................................ 29

2.2. INICIALIZACIÓN Y PUESTA A PUNTO .................................................................................................................... 30

2.2.1. Requerimientos para el uso de la función saveintodb ......................................................................... 30

2.2.2. Configurando el entorno ...................................................................................................................... 31

2.3. DISEÑO DE DIAGRAMA EER ............................................................................................................................. 33

2.3.1. Relaciones ............................................................................................................................................ 34

Índice

2.3.2. Índices .................................................................................................................................................. 35

2.4. DIAGRAMA DE ACTIVIDADES. EXPLICACIÓN DE LA PROGRAMACIÓN DE LA FUNCIÓN SAVEINTODB POR FASES ..................... 37

2.4.1. Fase 1: Validación de los argumentos de entrada pasados a la función saveintodb ........................... 38

2.4.2. Fase 2. Definición y obtención de la información a almacenar de cada modelo ................................. 39

2.4.3. Fase 3. Creación de base de datos y tablas desde MATLAB ................................................................. 44

2.4.4. Fase 4. Procedimiento para el almacenamiento de datos a las tablas ................................................ 44

2.5. CONSIDERACIONES FINALES DEL CAPÍTULO .......................................................................................................... 50

CAPÍTULO 3. EJEMPLIFICACIÓN DE LA FUNCIÓN. ASPECTOS ECONÓMICOS. ................................................. 51

3.1. EJEMPLIFICACIÓN DE LA FUNCIÓN ..................................................................................................................... 51

3.1.1. Procedimiento para el uso de la función .............................................................................................. 51

3.1.2. Ejemplo del uso de la función y comprobación de los datos insertados .............................................. 52

3.2. ANÁLISIS ECONÓMICO .................................................................................................................................... 58

CONCLUSIONES .................................................................................................................................................... 60

RECOMENDACIONES ............................................................................................................................................ 61

REFERENCIAS BIBLIOGRÁFICAS ............................................................................................................................ 62

ANEXOS……….... ...................................................................................................................................................... I

1

Introducción

Introducción

La formulación y solución de problemas en la identificación de procesos constituye un

área de investigación multidisciplinaria, que tiene muchas aplicaciones importantes en

ingeniería, biología, biofísica, ciencias agropecuarias, informática, por solo nombrar

algunos de entre muchos ámbitos. Todas estas áreas están formadas por entidades,

estructuras o procesos, por llamarlos de algún modo, de los cuales se hace necesario

un correcto conocimiento de las variables que lo conforman y de las dinámicas que se

llevan a cabo dentro de ellos.

Según lo anteriormente dicho se puede afirmar que es una necesidad la predicción del

comportamiento de las variables y los parámetros de las plantas o procesos en una

industria; debido a que en la mayoría son procesos complejos. Es de gran importancia

el tener modelos matemáticos, lo más cercano a la realidad posible, con el objetivo de

describir más eficientemente su comportamiento.

En la actualidad, es habitual el uso de herramientas de modelado computacional en la

descripción de estos procesos y de los modelos asociados a ellos. Especialmente un

paso concreto en el desarrollo de sistemas de estimación es el empleo del Toolbox de

Identificación de Sistemas (Systems Identification Toolbox) de MATLAB, que contiene

funciones para la estimación de modelos de sistemas dinámicos (Ljung, 2007).

La importancia de la identificación de sistemas radica, en que es un método de

obtención experimental de determinado modelo. El mismo, para los fines deseados,

debe reproducir con suficiente exactitud las características dinámicas del proceso

objeto de estudio. Es importante lograr una buena identificación que proporcione

modelos de orden reducido más fáciles de utilizar (López, 2000).

La identificación es un proceso iterativo donde el hombre tiene la tarea de planificar el

experimento, seleccionar la estructura y el método de ajuste adecuado, para validar el

modelo que cumpla las expectativas. Con el proceso de validación se calcula el best

FIT y se recurre a un análisis gráfico, a través de los resultados que brindan las gráficas

de respuesta al paso, respuesta de frecuencia, salida del modelo, ceros y polos,

espectro de ruido y residuos, por ser las que más información nos pueden brindar del

comportamiento de las diferentes estructuras. Este análisis hasta la actualidad se

2

Introducción

realiza basado en la experiencia del ingeniero o diseñador. Es imperativo que este

proceso sea lo más confiable, óptimo y exacto posible, por lo que la mejor opción es

que sea realizado por un ente programado ya sea: una función, programa o de forma

más general, un agente inteligente.

Para ello se encuentra en desarrollo una propuesta de proyecto mucho más general

que se encargará de diseñar un Sistema Multi-Agente capaz de llevar a cabo la

Identificación de Sistemas sin necesidad de que medie el hombre en el proceso de

selección, y en el marco de este proyecto se encuentra insertado el presente trabajo

que se dedicará solamente a garantizar los datos para su uso futuro; pues con la

implementación de este Sistema Multi-Agente se hace indispensable crear una base de

datos en la que dicho sistema se apoyaría en la toma de decisiones a la hora de

seleccionar el mejor modelo.

A partir de este supuesto, se establece como premisa en la investigación, almacenar

los datos que brinda el Toolbox de Identificación de Sistemas de MATLAB para que

sean usados por dicho programa en posteriores análisis o para llevar a cabo toma de

decisiones y también poder incorporar un poco de aprendizaje al proceso de

identificación.

Con este propósito deben exportarse los datos provenientes de MATLAB, a una base

de datos y que así sea más fácil el acceso a ellos para llevar a cabo el referido análisis

y poder arribar a conclusiones sobre el uso de un modelo u otro. Surge entonces la

necesidad de desarrollar una aplicación encargada de obtener los datos resultantes del

proceso de identificación; estableciendo una comunicación entre MATLAB y la base

datos donde serán almacenados. Lo cual representa el principal aporte de la

investigación.

Existen varias vías para el almacenamiento en una base datos, aprovechando la

capacidad del Toolbox de Base de Datos de MATLAB de conectar con una base de

datos, en la actualidad se ha utilizado en numerosas investigaciones a nivel

internacional como las siguientes:

A propósito, un estudio realizado en 2009, Edimburgo, Escocia propone el desarrollo

del sistema de registro de datos basado en MATLAB en el Siam Photon Source.

3

Introducción

Los sistemas están escritos enteramente con el lenguaje MATLAB y utilizan dos

toolboxes de MATLAB para manejar las comunicaciones de datos. Open Process

Control Toolbox, que se utiliza para llevar a cabo comunicaciones con Controladores

Lógicos Programables (PLC) y Data Acquisition Toolbox, que gestiona las

comunicaciones con otros sistemas a través de RS-232 y las interconexiones IEEE-

488. La interfaz con la base de datos es manejada por el Database Toolbox de

MATLAB. La base de datos fue desarrollada en MySQL 5.0. (Klysubun and Netsai,

2009).

Así mismo en 2009 en el Instituto de Tecnología Química de Praga, República Checa

desarrolló “COMPUTING USING SYBASE DATABASE FOR BIOMEDICAL SIGNAL

ANALYSIS”. Para ello, decidieron utilizar Sybase Adaptive Server Enterprise como

base de datos principal y MathWorks MATLAB para manipular datos matemáticos

(Krupa et al., 2009).

Por otra parte, durante la “International Scientific Conference on Information,

Communication and Energy Systems and Technology” (ICEST), en 2006, la

Universidad Técnica de Sofía, Bulgaria presentó el proyecto: “Pixel-Based Searching of

Images Stored in a Database”. Utilizan la base de datos Oracle para su investigación.

Usan además, Database Toolbox para conectar MATLAB con la base de datos a través

del controlador de base de datos ODBC (Open Database Connectivity) o JDBC (Java

Database Connectivity) (Stojanovic and Bogdanov, 2006).

En el ámbito nacional aparecen pocas investigaciones relacionadas con el tema. Al

respecto en la “Conferencia Internacional de Energía Renovable, Ahorro de Energía y

Educación Energética” (CIER), 2007 se presentó la investigación: “Determinación de

diapasones de potencia necesarios para el control de frecuencia en el sistema eléctrico

cubano”.

El mismo está basado en un análisis estadístico de una base de datos en tiempo real.

Para el procesamiento de la información se elaboró un software (Prodat) con soporte

en MATLAB 7.0, que permitió importar los datos del SCADA en ambiente Excel a un

ambiente en MATLAB. (García et al., 2007).

4

Introducción

Luego de realizar un análisis bibliográfico del panorama nacional e internacional en

torno al tema en cuestión, no se encontró antecedente alguno que hablara de la

existencia de una función, que permita el almacenamiento en base de datos de la

información resultante del proceso de identificación, por lo que se define como

situación problémica: La no existencia en la actualidad de una aplicación encargada

de almacenar los datos resultantes del proceso de identificación, usando la herramienta

de Identificación de Sistemas de MATLAB, con el objetivo de que puedan ser utilizados

en futuros análisis.

Partiendo de estas conclusiones se diseñó y se llevó a cabo la presente investigación

en la Universidad Central “Marta Abreu” de Las Villas, a partir del siguiente problema

científico:

¿Cómo almacenar, a través de una función, los datos provenientes de la identificación

paramétrica del Toolbox de Identificación de Sistemas de MATLAB en un formato de

base de datos?

Asimismo la investigación responde a determinadas interrogantes científicas para su

desarrollo:

Interrogantes Científicas:

¿Cómo acceder a los datos obtenidos durante el proceso de identificación paramétrica

con el Toolbox de Identificación de Sistemas de MATLAB de MATLAB?

¿Cómo almacenar estos datos en la base de datos?

¿Qué sistema gestor de base de datos será el más adecuado?

¿Cómo lograr una estructura de base de datos que permita un fácil acceso a sus

datos?

Con el propósito de dar solución a la situación problémica, se plantea como objetivo

general, proponer una función para el almacenamiento en una base de datos, de los

datos provenientes del proceso de identificación paramétrica en MATLAB. En tanto, los

objetivos específicos son:

5

Introducción

Definir cuáles son las variables a tener en cuenta para el análisis de los modelos

paramétricos identificados.

Determinar cuál sistema gestor utilizar para la confección de la base de datos.

Diseñar una base de datos cuya estructura sea capaz de asimilar los datos

provenientes del proceso de identificación paramétrica.

Programar la función saveintodb.

Con la realización de este proyecto se pretende tener como resultado una función

encargada de obtener los datos resultantes del proceso de identificación. Se contará

con la base de datos pertinente para establecer una comunicación con MATLAB, en la

cual serán almacenados los datos, que serán usados en análisis posteriores.

Como impacto posible la investigación contribuirá a responder problemáticas actuales

relacionadas con la implementación de software en la obtención experimental de

modelos. Por lo que constituirá un aporte para la comunidad científica.

Con el diseño de la función que supone la investigación se contribuirá al desarrollo de

posteriores investigaciones que posibilitan la optimización de la identificación de

sistemas.

Según su aplicabilidad, los resultados de la investigación poseen una aplicación

práctica, en tanto constituye un paso más en la optimización del proceso de

identificación de sistemas.

Se cuenta con los recursos humanos y materiales necesarios. Asimismo el proyecto se

ajusta a demandas actuales y se ubica racionalmente en el tiempo y en el contexto

social, por lo que puede afirmarse su viabilidad.

El informe de la investigación está estructurado de la siguiente manera: La presente

introducción a la que siguen, en el mismo orden, capitulario, conclusiones,

recomendaciones, referencias bibliográficas y anexos.

Los temas abordados en cada uno de los capítulos son:

Capítulo 1. Comunicación MATLAB-Base de Datos. Su empleo en la Identificación

de Sistemas

6

Introducción

En este capítulo se aborda el tema de la Identificación de Sistemas usando como

referencia la literatura clásica para dicho tema. Se investiga sobre las potencialidades

que MATLAB ofrece relacionadas con la Identificación de Sistemas y la comunicación

con bases de datos. Por último, se selecciona el gestor de base de datos apropiado

para establecer una comunicación con MATLAB.

Capítulo 2. Saveintodb. Función para obtener información de modelos estimados

y almacenarlos en la base de datos MATLAB_DATA de MySQL

En dicho capítulo se explican las características de la función saveintodb, se determina

la información relevante a almacenar sobre cada modelo, además se describe la

estructura de la base de datos, así como el funcionamiento de la función mediante su

diagrama de actividades.

Capítulo 3. Ejemplificación de la función. Aspectos económicos

En este capítulo se muestran los resultados obtenidos. Mediante el uso de un juego de

datos de entrada-salida, se prueban las bondades de la función, demostrando que

almacena los datos requeridos correctamente. Para calcular los costos de la

investigación se realiza un análisis económico, dando cierre al capítulo.

7

Capítulo 1 Comunicación MATLAB-Base de Datos. Su empleo en la Identificación de Sistemas

Capítulo 1. Comunicación MATLAB-Base de Datos. Su empleo en la

Identificación de Sistemas

Cuando interactuamos con el entorno, intuitivamente aprendemos a controlar nuestras

acciones prediciendo su efecto. Esas predicciones están basadas en un modelo innato

adaptado a la realidad, usando nuestras experiencias pasadas.

Durante un largo período los modelos creados por el hombre para explicar sus

observaciones del universo eran cualitativos; pero en los últimos siglos se han

complementado con modelos cuantitativos basados en matemática avanzada.

Con la insaciable demanda y el desarrollo de la ciencia y la tecnología, los instrumentos

para la obtención de modelos se han perfeccionado y son extensivamente usados en

todos los campos, incluyendo las áreas no técnicas como la economía, ecología y la

biología.

1.1. Identificación de Sistemas. Aspectos generales

Como resultado de estos avances científico-técnicos, uno de los instrumentos más

empleados en la obtención de modelos matemáticos es la Identificación de Sistemas,

como ejemplo clave de la implementación de matemática avanzada. Estos modelos

empleados en el campo de la ingeniería se definen como: “Un modelo de un sistema es

una herramienta computacional que se usa para responder preguntas sobre el sistema

sin tener que realizar experimentos sobre el sistema” (Ljung, 2007). En las últimas

décadas, el término "Identificación de Sistemas" o "Identificación de Procesos" ha sido

muy manejado en el ámbito del control automático. El mismo ha sido definido por varios

autores, que desde sus conceptualizaciones lo abordan con algunos puntos de

contacto:

Según Aguado (2000) la "Identificación de Procesos" puede ser definida como: La

obtención de la estructura y los parámetros de un modelo matemático generalmente

dinámico, que reproduce con suficiente exactitud, para los fines deseados de control

automático, las características dinámicas del proceso objeto de estudio. (Aguado

Behar, 2000).

Por otra parte, autores como López (2000) explican que: Se entiende por "Identificación

de Sistemas", a la obtención de forma experimental de un modelo que reproduzca con

8


suficiente exactitud, para los fines deseados, las características dinámicas del proceso

objeto de estudio. (López, 2000)

Otras definiciones registradas plantean: Con la técnica de "Identificación de Sistemas",

basada en los datos experimentales registrados, el modelo de un proceso es obtenido,

el cual puede reproducir los datos del proceso y por lo tanto proporciona una

descripción precisa del comportamiento local del sistema” (Donkelaar, 2000).

Posteriormente, Pintelon, R. y Shoukens, J. (2001) definen que: “El propósito de la

teoría de la identificación es proveer una aproximación sistemática para ajustar el

modelo matemático, tanto como se pueda, a la parte determinística, eliminando el ruido

de distorsión tanto como sea posible”. (Pintelon and Schoukens, 2001)

Asimismo Mikles, J.y Fikar, M. (2007) proponen: “La Identificación de Sistemas

intenta describir el proceso de acuerdo con la información obtenida de la relación entre

las salidas y entradas del proceso”. (Mikles and Fikar, 2007)

Hasta el momento una de las definiciones más acertadas es la que ofrece Lennart

Ljung en su libro System Identification. Theory for the User, considerado un clásico en

esta esfera. De esta forma la investigación asume tal definición para su desarrollo, pues

la misma engloba el contenido de las definiciones antes descritas de manera

sintetizada:

“La Identificación de Sistemas trata con el problema de construir modelos

matemáticos de sistemas dinámicos basándose en datos observados del sistema”

(Ljung, 1999).

Sin embargo para comprender los procesos de Identificación de Sistemas no basta con

el planteamiento de su definición, sino que es necesario abordar otros aspectos que

serán presentados a continuación.

1.1.1. El procedimiento de identificación

En términos generales, el proceso de construcción de un modelo a partir de los datos

implica tres entidades básicas (Ljung, 1999):

1. Un set de datos.

2. Un set de candidatos a modelos.

9


3. Una regla para determinar qué candidato a modelo puede ser calculado usando

los datos recopilados.

Comentado sobre cada una de ellas:

1. La recolección de datos:

En ocasiones los datos de entrada y salida son grabados durante un específico y

diseñado experimento de identificación, donde el usuario puede determinar qué señales

medir y cuándo medirlas. También puede elegir las señales de entrada (las que sean

relevantes). El objetivo con el diseño del experimento es hacer las decisiones

pertinentes, donde los datos aporten la mayor información posible.

2. El set de modelos o la estructura de modelo:

Un set de candidatos a modelo es obtenido, especificando dentro de qué colección de

modelos vamos a buscar para determinar el apropiado. Sin duda este es el punto más

importante y a la vez, la decisión más difícil en el procedimiento de Identificación de

Sistemas. Este punto se facilita en gran medida con un conocimiento previo,

comprensión e intuición ingenieril, combinado además con las propiedades formales del

modelo.

3. Determinando el “mejor” modelo en el set, guiándonos por los datos:

La determinación del mejor modelo en el set se realiza mediante la evaluación de la

calidad del modelo. Esta se basa típicamente en cómo el modelo desempeña su intento

en reproducir los datos medidos. Lo cual está directamente relacionado con qué

estructura de modelo es usada. Esta tercera entidad básica se refiere a los métodos de

identificación, los cuales serán abordados más adelante.

Después de haber fijado las tres decisiones precedentes, correspondientes a las tres

entidades básicas, se arriba a un modelo en particular: el que mejor describa los datos

conforme a los criterios escogidos. Luego se comprueba si el modelo es

“suficientemente bueno”, es decir, si es válido para su propósito.

Como puede observarse este proceder lleva implícito determinadas pruebas conocidas

como validación del modelo, término que será abordado con mayor profundidad en

próximos epígrafes.

10


Las pruebas, suponen varios procedimientos para evaluar cómo el modelo describe los

datos observados, para conocimiento previo y su uso posterior. Si el modelo obtenido

tiene un buen desempeño describiendo los datos, podría satisfacer el grado de

exactitud requerido para la aplicación en cuestión. Un comportamiento deficiente del

modelo en la descripción de los datos, conlleva a rechazarlo, y se arriba a la conclusión

de que el modelo no es válido (Ljung, 1999).

1.1.2. El Lazo de Identificación de Sistemas

El procedimiento de Identificación de Sistemas tiene un flujo natural: primero recolectar

los datos, luego escoger el set de modelo, después elegir el “mejor” modelo en este set.

Es muy probable que el primer modelo obtenido no va a pasar las pruebas de

validación. Por lo que se debe ir atrás y revisar cada paso del proceso (Ljung, 1999).

Es necesario entonces revisar los siguientes aspectos como posibles causas (López,

2000):

a) El conjunto de datos de entrada-salida no proporciona suficiente información

sobre la dinámica del sistema.

b) La estructura escogida no es capaz de proporcionar una buena descripción del

modelo.

c) El criterio de ajuste de parámetros seleccionados no es el más adecuado.

Dependiendo de la causa estimada, deberá repetirse el proceso de identificación desde

el punto correspondiente. Por tanto, el proceso de identificación es un proceso iterativo,

cuyos pasos pueden observarse en el organigrama de la Figura 1.1.

11


Figura 1.1 Lazo del procedimiento de Identificación de Sistemas

1.1.3. Métodos de identificación: paramétrica y no paramétrica. Estructuras

de modelos

En el proceso de identificación existen determinadas técnicas o métodos que juegan un

papel fundamental para el éxito en la obtención de un modelo matemático que se ajuste

con suficiente exactitud al sistema real.

1. Métodos de identificación no paramétricas: Permiten obtener modelos no

paramétricos del sistema objeto de estudio. Algunos de estos métodos son: análisis de

la respuesta transitoria, análisis de la respuesta en frecuencia, análisis de la

correlación, análisis espectral, análisis de Fourier, etc. (López, 2000).

2. Métodos de identificación paramétricas: Los modelos paramétricos quedan

descritos mediante una estructura y un número finito de parámetros que relacionan las

señales de interés del sistema (entradas, salida y perturbaciones). En la mayoría de los

casos estos modelos permiten representar el comportamiento de cualquier sistema

lineal. El conflicto reside en la elección del tipo de modelo (orden del mismo, número de

parámetros, etc.) que se ajuste favorablemente a los datos de entrada - salida

obtenidos de forma experimental (Carballo, 2011).

Los métodos implementados con los cuales se puede alcanzar una adecuada

identificación del sistema son:

12


ARX (Auto Regressive and Exogenous Variable). Se resuelve directamente por el

algoritmo de mínimos cuadrados (Valdivia, 2012).

ARMAX (Auto Regressive Moving Average and Exogenous Variable). Se resuelve

minimizando el error de predicción de forma iterativa, aplicando el algoritmo de mínimos

cuadrados extendido (Valdivia, 2012).

OE (Output Error). Se resuelve con un algoritmo similar al ARMAX modificando el

cálculo del error de predicción y el gradiente (Valdivia, 2012).

BJ (Box-Jenkins). Se resuelve con un algoritmo similar al ARMAX modificando el

cálculo del error de predicción y el gradiente (Valdivia, 2012).

La obtención de un modelo mediante el uso de estos métodos demanda un

conocimiento previo del sistema a identificar. Solo así se logrará elegir una posible

estructura del modelo, un criterio de ajuste de parámetros, y por último, la estimación

de los parámetros que se ajusten apropiadamente a los datos de entrada y salida,

obtenidos de forma experimental (López, 2000).

Es importante señalar además, que cada una de las estructuras (ARX, ARMAX, OE o

BJ) tiene sus rasgos peculiares y debe ser seleccionada, fundamentalmente, en función

del punto en el que se prevé que se añade el ruido en el sistema. Dado que la

identificación de sistemas es un método iterativo de prueba y error, se hace necesario

tantear con varias estructuras, y con varios órdenes dentro de una misma estructura,

hasta encontrar un modelo apropiado.

1.1.4. Validación del modelo

A partir de lo que plantea Lennart Ljung en su libro "System Identification. Theory for

the User" en 1999, puede afirmarse que las técnicas de identificación paramétrica

proyectan el “mejor” modelo después de seleccionada su estructura. Mas, la cuestión

principal radica en si el modelo es “suficientemente bueno”, si concuerda

suficientemente bien con los datos observados, y si puede ser usado para resolver el

problema planteado. Esto demuestra, que en la práctica, la aplicabilidad del modelo

identificado, depende en gran medida de la aplicación en la que está destinado a

usarse, y no de si responde exactamente al comportamiento de un sistema real.

13


En general, la mayoría de los métodos para la validación tratan de comprobar si la

respuesta del modelo se ajusta con suficiente exactitud a los datos de entrada-salida

obtenidos mediante experimentación (López, 2000).

A continuación se exponen algunos criterios típicos a la hora de descartar o elegir unos

modelos respecto a otros:

Validación con respecto a la aplicación del modelo.

Comprobación de parámetros físicos.

Coherencia con el comportamiento de entrada-salida.

Reducción del modelo.

Intervalos de fiabilidad de parámetros.

Simulación.

Análisis de residuos.

1.2. Toolbox de Identificación de Sistemas de MATLAB

MATLAB es un software matemático que ofrece un entorno de desarrollo integrado

(IDE) con un lenguaje propio (lenguaje M) de alto funcionamiento para computación

técnica. Este integra computación, visualización y programación, en un ambiente

factible donde los problemas y las soluciones son expresados en la más familiar

notación matemática. El MATLAB habitualmente se emplea en: matemática y

computación, desarrollo de algoritmos, modelado y simulación, análisis de datos,

gráficas científicas e ingenieriles, exploración y visualización, incluyendo el desarrollo

de aplicaciones, entre otras (Carballo, 2011).

Además se pueden ampliar las capacidades de MATLAB con las cajas de herramientas

(toolboxes), las cuales constituyen una familia de soluciones a aplicaciones específicas

de acoplamiento rápido. Los toolboxes son colecciones muy comprensibles de

funciones o archivos (M-files) que extienden el ambiente de MATLAB para solucionar

casos específicos de problemas. En la actualidad estos toolboxes abarcan

prácticamente casi todas las esferas de la ingeniería y la simulación en sentido general,

destacando entre ellos el toolbox de proceso de imágenes, el de señal, control robusto,

14


estadística, análisis financiero, matemáticas simbólicas, redes neurales, lógica difusa,

Identificación de Sistemas, el de base de datos, etc. (Carballo, 2011).

El Toolbox de Identificación de Sistemas (Systems Identification) extiende el ambiente

computacional de MATLAB y nos permite estimar modelos lineares y no lineares que

relacionan las entradas y salidas de sistemas dinámicos (Ljung, 2007). Tiene

implementado métodos de estimación de modelos paramétricos y no paramétricos,

provee un ambiente interactivo para análisis de datos, estimación y validación de

modelos, facilita la estimación de modelos continuos y discretos, usando datos en el

dominio del tiempo.

Para lograr lo descrito anteriormente se pueden usar los comandos del Toolbox de

Identificación de Sistemas en la ventana de comandos de MATLAB, o podemos trabajar

en la herramienta de Identificación de Sistemas (System Identification Tool GUI)

mostrado en la Figura 2.1 Exportar a workspace desde el GUI del Toolbox de

Identificación de Sistemas

1.2.1- Aspectos prácticos de interés en el Toolbox de Identificación de Sistemas

Estimar el modelo representa un primer paso en el proceso de identificación. Una vez

estimado, debe examinarse, compararse con otros modelos, y probar con nuevos

conjuntos de datos. Esto se realiza principalmente utilizando las gráficas: respuesta de

frecuencia, respuesta al paso, ceros y polos, espectro de ruido, la salida del modelo y

los residuos del modelo1. Las cuales representan la información que se desea analizar

de los modelos con el objetivo de poder escoger el mejor entre ellos.

1.2.1-1. Gráfica de salida del modelo

De la gráfica de salida del modelo solo se toma el Best FIT (mejor ajuste): El porcentaje

de la salida que el modelo reproduce. Es calculado usando el set de datos estimados y

no el set de datos para la validación. Sin embargo la gráfica antes mencionada muestra

el ajuste (fit) para el set de datos usados en la validación.

Calculado mediante la siguiente ecuación:

( | ̂|

| |) Ecuación 1-1

1 La información presentada sobre dichas gráficas fue extraída de Ljung (2007).

15


En esta ecuación, es la salida medida, ̂ es la salida del modelo simulado o predicho

y es la media de . (Ljung, 2007).

1.2.1-2. Gráfica de ceros y polos

Se obtienen los ceros (raíces del numerador) y los polos (raíces del denominador) del

modelo.

La ecuación general de un sistema dinámico está dada por:

( ) ( ) ( ) ( ) Ecuación 1-2

En esta ecuación, es un operador que toma la entrada a la salida y captura la

dinámica del sistema, y es el término de ruido aditivo. Los polos de un sistema lineal

son las raíces del denominador de la función de transferencia . Los polos tienen una

influencia directa sobre las propiedades dinámicas del sistema. Los ceros son las

raíces del numerador de .

1.2.1-3. Gráfica de respuesta al paso

La respuesta al paso es la señal de salida que resulta de una entrada paso, donde

( ) y ( ) .

La gráfica de respuesta al paso proporciona información sobre las propiedades

dinámicas básicas del modelo, como los tiempos de respuesta, las ganancias estáticas

y retrasos. La misma también ayuda a validar la eficacia de un modelo paramétrico

lineal, tal como un modelo ARX lineal o un modelo de espacio-estados, capta la

dinámica.

Además, esta muestra el valor de la respuesta al paso en el eje vertical. El eje

horizontal es en unidades de tiempo que se especifica para los datos utilizados para la

estimación del modelo.

1.2.1-4. Gráfica de respuesta de frecuencia

Puede representar la respuesta de frecuencia de un modelo que permite conocer mejor

las características de la dinámica del modelo lineal, como la frecuencia de la respuesta

del pico y los márgenes de estabilidad. La gráfica de respuesta de frecuencia está

16


disponible para todos los modelos paramétricos lineales y modelos de análisis espectral

(no paramétrico).

La respuesta de frecuencia de un modelo dinámico lineal describe cómo el modelo

reacciona a entradas sinusoidales. Si la entrada ( ) es una sinusoide de una cierta

frecuencia, a continuación, la salida ( ) es también una sinusoide de la misma

frecuencia. Sin embargo, la magnitud de la respuesta es diferente de la magnitud de la

señal de entrada, y la fase de la respuesta se desplaza con relación a la señal de

entrada.

La gráfica de respuesta de frecuencia proporciona información sobre la dinámica de los

sistemas lineales, tales como ganancias dependientes de la frecuencia, resonancias, y

desplazamientos de fase. También contienen información sobre los requisitos del

controlador y anchos de banda alcanzables. Por último, la gráfica de respuesta de

frecuencia también puede ayudar a validar la eficacia de un modelo paramétrico lineal,

como un modelo ARX lineal o un modelo de espacio de estados, captura la dinámica.

1.2.1-5. Gráfica de espectro de ruido

Al estimar el modelo de ruido del sistema lineal, el Toolbox de Identificación de

Sistemas permite trazar el espectro del modelo de ruido estimado.

La gráfica de espectro ruido se encuentra disponible para todos los modelos

paramétricos lineales y análisis espectral (no paramétricos) modelos.

Partiendo de la ecuación general de un sistema dinámico (Ecuación 1-2) y que en el

Toolbox de Identificación de Sistemas, el término de ruido se considera como ruido

blanco filtrado, de la siguiente manera:

( ) ( ) ( ) Ecuación 1-3

Se calculan ambos y durante la estimación del modelo de ruido y almacena estas

cantidades como del modelo. El operador ( ) representa el modelo de ruido. ( ) es

una fuente de ruido blanco con varianza .

Considerando que la gráfica de respuesta en frecuencia muestra la respuesta de , la

gráfica de espectro de ruido muestra la respuesta de frecuencia del modelo de ruido .

17


Para los modelos de entrada-salida, el espectro de ruido viene dado por la Ecuación

1-4.

( ) | ( )|

Ecuación 1-4

1.2.1-6. Gráfica de análisis residual

Se puede validar los modelos lineales y no lineales paramétricos marcando el

comportamiento de los residuos del modelo. Los residuos son las diferencias entre la

salida de un solo paso-predicho a partir del modelo y la salida medida a partir del

conjunto de datos de validación. Por lo tanto, representan la porción residual de los

datos de validación no explicados por el modelo.

Las gráficas de análisis residual muestran información diferente dependiendo de si se

utiliza el dominio del tiempo o de dominio de frecuencia en los datos de validación de

entrada-salida.

Para los datos de validación de dominio de tiempo, la trama muestra los dos ejes

siguientes:

Función de autocorrelación de los residuales para cada salida.

La correlación cruzada entre la entrada y los residuales para cada par de

entrada y salida.

1.3. Comunicación entre aplicaciones

Existen mecanismos para facilitar la comunicación e intercambio de datos entre

aplicaciones. Las funciones activadas por algunos de estos mecanismos facilitan la

división del trabajo, entre varios procesos especializados. Asimismo otros de estos

mecanismos propician la división del trabajo entre los equipos de una red. Por otra

parte, es probable que una aplicación utilice varios de estos mecanismos

Por lo general, las aplicaciones pueden utilizar los mecanismos categorizados como

clientes o servidores. Según Sadoski, D. (1997), un “cliente” es una aplicación o

proceso que solicita un servicio desde otra aplicación o proceso. Así como, un

“servidor” es una aplicación o un proceso que responde a una petición de cliente.

Muchas aplicaciones pueden actuar tanto como cliente o servidor, dependiendo de la

situación. (Sadoski, 1997)

18


A continuación se exponen los mecanismos principales para facilitar la comunicación e

intercambio de datos entre aplicaciones.

1- RPC (Llamada a procedimiento remoto del inglés Remote Procedure Call):

Permite a las aplicaciones llamar a funciones de forma remota. Por lo tanto, RPC hace

que este proceso de comunicación entre aplicaciones sea tan fácil como llamar a una

función (Microsoft, 2012).

2- COM (Component Object Model): Los objetos COM proveen acceso a los datos

de un objeto a través de uno o más sets de funciones relacionadas, conocidas como

interfaces (Microsoft, 2012).

3- DDE (Intercambio dinámico de datos del inglés Dynamic Data Exchange): es un

protocolo que permite que las aplicaciones intercambien datos en una variedad de

formatos (Microsoft, 2012).

4- TCP/IP (Protocolo de control de transmisión/Protocolo de internet del inglés

Transmission Control Protocol/Internet Protocol): Es un conjunto de protocolos de red

en los que se basa internet y que permiten la transmisión de datos entre redes de

computadoras (Microsoft, 2012).

5- Sockets: Windows Sockets es una interfaz independiente del protocolo. Se

aprovecha de las capacidades de comunicación de los protocolos subyacentes

(Microsoft, 2012).

6- API de Windows (Application Programming Interface): Interfaz de programación

de aplicaciones o API es el conjunto de funciones, en la programación orientada a

objetos, que ofrece cierta biblioteca para ser utilizado por otro software como una capa

de abstracción. Son usadas generalmente en las librerías. Uno de los principales

propósitos de una API consiste en proporcionar un conjunto de funciones de uso

general (Microsoft, 2012).

1.3.1- Comunicación Aplicación-Base de Datos

Existe toda una familia tecnológica para tener acceso a almacenes de datos, que van

desde simples archivos de texto y hojas de cálculo, hasta bases de datos complejas.

19


Según Oracle (2012) una “base de datos” es una colección estructurada de datos.

(Oracle, 2012)

Para otros autores una “base de datos” es una compartida, integrada estructura de

computadora que almacena una colección de: Datos de interés para un usuario y

megadatos (datos de datos) (Coronel et al., 2012).

Se necesita un sistema de gestión de base de datos (DBMS del inglés Data Base

Management System) para añadir, acceder, y procesar los datos almacenados en una

base de datos. Asimismo es importante añadir: Una base de datos relacional, almacena

datos en tablas separadas, en lugar de poner todos los datos en un gran almacén, lo

cual añade velocidad y flexibilidad en el proceso. La investigación asume tales

definiciones para su desarrollo.

Familia tecnológica:

Microsoft Data Access Components (MDAC): Es un grupo de tecnologías de Microsoft

que interactúan en conjunto como una infraestructura, y brinda a los programadores

una forma para desarrollar aplicaciones con acceso a casi cualquier almacén de datos.

Sus componentes incluyen: (ADO.NET), (OLE DB), (ODBC), (JDBC), entre otros como

Data Access Object (DAO) y Remote Data Object (RDO) ya obsoletos que no serán

tratados en la investigación (Coronel et al., 2012).

• OLE DB (Object Linking and Embedding for Databases) Enlace e incrustación de

objetos para bases de datos: Es una tecnología desarrollada por Microsoft usada para

tener acceso a diferentes fuentes de información, o bases de datos, de manera

uniforme (Coronel et al., 2012).

• ADO.NET (ActiveX Data Objects de la plataforma .NET) es un conjunto de

componentes del software que es comúnmente usado por los programadores, para

acceder y para modificar los datos almacenados en un DBMS (Coronel et al., 2012).

• ODBC (Open DataBase Connectivity) es un estándar de acceso a las bases de datos.

Su objetivo es hacer posible el acceder a cualquier dato desde cualquier aplicación,

sin importar qué DBMS almacene los datos. La API ODBC logra esto al insertar una

capa intermedia denominada nivel de Interfaz de Cliente SQL (CLI), entre la

aplicación y el DBMS. El propósito de esta capa es traducir las consultas de datos de

20


la aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la

aplicación como el DBMS deben ser compatibles con ODBC, esto es que la

aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz

de responder a ellos (Coronel et al., 2012) (Geiger, 1995).

• JDBC: Java Database Connectivity (JDBC) es un derivado de ODBC, una interfaz de

programación de aplicaciones (API) que permite la ejecución de operaciones sobre

bases de datos, desde el lenguaje de programación Java independientemente del

sistema operativo donde se ejecute o de la base de datos a la cual se accede

utilizando el dialecto SQL del modelo de base de datos que se utilice (Coronel et al.,

2012) (White, 1999).

Como se observa, existen diferentes vías para que una aplicación interactúe con una

base de datos. Estas dos últimas son soportadas por el Toolbox de base de datos de

MATLAB (el cual será abordado con profundidad en el próximo subepígrafe), a la vez

se constituyen como una de las tecnologías más empleadas en proyectos que usan

MATLAB para calcular y manipular datos.

1.3.2- El Database Toolbox de MATLAB

Al igual que el Toolbox de Identificación de Sistemas, según el libro “Database Toolbox.

For Use with MATLAB” de 1998: La caja de herramientas de base de datos Database

Toolbox, pertenece a la extensa colección de cajas de herramientas que extienden el

ambiente de MATLAB. Esta permite mover los datos (tanto de importación y

exportación) entre MATLAB y populares bases de datos relacionales.

O sea, puede usarse para importar a MATLAB datos de una base de datos existente,

luego utilizar cualquiera de las herramientas computacionales y analíticas de MATLAB,

y almacenar los resultados de vuelta, en la misma base de datos u otra.

El Toolbox de base de datos conecta a MATLAB con una base de datos mediante el

uso de los comandos de MATLAB. Los datos se recuperan de la base de datos como

una cadena. Analizado el tipo de datos correcto, se almacenan en un arreglo de celdas

de MATLAB y es entonces cuando se utiliza el amplio conjunto de herramientas de

MATLAB, para trabajar con los datos. Se pueden incluir los comandos del Toolbox de

21


base de datos en los M-Files de MATLAB y para exportar los datos desde MATLAB a

una base de datos, se utilizan comandos de MATLAB.

El Toolbox antes mencionado soporta datos para importar/exportar, de los siguientes

sistemas de gestión de datos: IBM DB2, IBM Informix, Ingres, Microsoft Access,

Microsoft Excel, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase SQL

Anywhere y Sybase SQL Server. (MathWorks, 1998)

Para establecer la conectividad con las base de datos soportadas, se usan

controladores (drivers). Dicho Toolbox soporta todos los controladores ODBC. Los

controladores JDBC no son oficialmente soportados pero algunos han sido probados y

funcionan.

El controlador tiene que ser instalado, para lograr la conectividad del Toolbox con la

base de datos en cuestión. Además, para conectar el Toolbox de base de datos con un

controlador ODBC, el Toolbox usa un puente JDBC/ODBC, el cual es provisionado

automáticamente como parte de la instalación del Toolbox.

Figura 1.2 Uso de los controladores con el Toolbox de base de datos.

1.4. Sistema de gestión de base de datos apropiado

En la industria moderna uno de los activos más valiosos son los datos y la disposición

de ellos. Hacer un mejor uso de los datos garantiza que la industria cumpla sus metas.

No obstante, los datos son solo bits y bytes en un sistema de archivos y solo con un

DBMS, puedes convertirlos en información seria. Esto significa que es imperativo

escoger el sistema gestor de base de datos correcto.

Para lograr una elección formidable se deben tener en cuenta algunos factores como:

que sea de fácil uso, su desempeño, seguridad, entre otros. Apoyarse en las

tendencias actuales disminuye este trabajo en gran medida.

22


En este sentido, DBMS como Microsoft Office Excel y Access, Sybase, Oracle y MySQL

5.5 se emplean frecuentemente en proyectos similares a la presente investigación.

Cada uno de ellos tiene sus ventajas y desventajas; por ejemplo: Microsoft Office Excel

está diseñado para manejar hojas de cálculo y es utilizado normalmente, para tareas

financieras y contables. Microsoft Office Access permite crear ficheros de bases de

datos relacionales, que pueden ser fácilmente gestionadas por una interfaz gráfica

sencilla. Sin embargo, no son suficientemente profesionales y se necesita el paquete

de Office.

Por otra parte Sybase y Oracle son DBMS de alto rendimiento, con soporte a grandes

volúmenes de datos, pero pertenecen a empresas comerciales, lo cual resulta, en

términos de costo, una dificultad.

Finalmente, MySQL es el DBMS más popular a nivel mundial, pues es adoptado

mayoritariamente en cuantiosas industrias. Es conocido por su confiabilidad, su fácil

uso, flexibilidad, desempeño, y que es un software libre. Conjuntamente, la comunidad

que usa MySQL es muy activa, por lo que contar con ayuda y guía es muy efectivo. Es

importante destacar que dicho DBMS es soportado por MATLAB y puede establecerse

una conexión con él, a través del Toolbox de base de datos de MATLAB. De esta

forma, el gestor de base de datos MySQL es considerado el más apropiado para

cumplir los objetivos de la investigación.

1.4.1- Términos básicos

Para comentar sobre estos términos se utiliza como referencia el libro La Biblia de

MySQL de 2003. (Gilfillan, 2003)

Los datos son los valores que se almacenan en la base de datos. Por sí solos no

tienen mucho significado.

Una base de datos es un conjunto de tablas.

Cada tabla se compone de registros (las filas horizontales de la tabla, que también se

conocen como tuplas). Cada registro debe ser exclusivo y puede almacenarse en

cualquier orden dentro de la tabla. Cada registro se compone de campos (las columnas

verticales, que también se conocen como atributos).

23


Los campos pueden ser de varios tipos. MySQL consta de una gran cantidad de tipos,

pero por regla general se pueden clasificar en tres categorías: caracter, numérico y de

fecha. El rango de valores permitidos para un campo se conoce como dominio (o

especificación del campo). De un campo se dice que contiene un valor nulo cuando no

incluye ningún valor. Los campos nulos pueden complicar los cálculos y generar

problemas de exactitud en los datos. Por esta razón, muchos campos se configuran de

forma que no puedan contener valores nulos. Además, un campo puede ser de

incremento automático, estos se asocian con la llave primaria y permiten que MySQL

se encargue de la secuenciación del campo. Si se inserta un registro, MySQL agregará

una unidad al valor anterior incrementado automáticamente y lo utilizará como valor

para el campo de incremento automático utilizado.

Una clave accede a registros especiales de una tabla. Un índice es un mecanismo que

mejora el rendimiento de una base de datos. Los índices se suelen confundir con las

claves. Estrictamente hablando, se integran en la estructura física mientras que las

claves son parte de la estructura lógica. Sin embargo, estos términos se suelen utilizar

indistintamente.

Una relación uno a uno (1: 1) es una relación en la que para cada instancia de la

primera tabla de una relación solo existe una instancia en la segunda.

Una relación uno a varios (1:V) es una relación en la que para cada instancia de la

primera tabla existen varias instancias en la segunda tabla. Este tipo de relación es muy

habitual.

Una relación varios a varios (V:V) es una relación que tiene lugar cuando para cada

instancia de la primera tabla existen varias instancias en la segunda, y para cada

instancia de la segunda existen varias instancias en la primera.

Una relación obligatoria es una relación en la que para cada instancia de la primera

tabla de la relación debe existir una o varias instancias en la segunda.

Una relación opcional es una relación en la que para cada instancia de la primera

tabla de una relación pueden existir instancias en la segunda.

Una clave de tabla, como indica el término, desbloquea el acceso a las tablas. Si

conocemos la clave, sabremos cómo identificar sus registros así como las relaciones

24


entre las tablas. Una clave candidata es un campo o una combinación de campos que

identifiquen un registro de manera exclusiva. No puede contener un valor nulo y su

valor debe ser exclusivo. (La existencia de duplicados impide la identificación de un

registro exclusivo).

Una clave primaria es una clave candidata que ha sido designada para identificar de

forma única los registros de una tabla en la estructura completa de una tabla.

Clave externa: Una relación entre dos tablas se establece asignando un campo común

en ellas. Este campo común debe ser la clave primaria de una de estas dos tablas. El

cual es denominado como clave externa en la segunda. Las claves externas permiten

garantizar lo que se conoce como integridad referencial2. También permiten realizar

eliminaciones y actualizaciones en cascada.

El proceso de eliminación recorre las tablas pertinentes, suprimiendo todos los registros

procedentes, utilizando una única instrucción, por ejemplo:

Existen dos tablas con una relación entre ellas (1:V), esta relación es posible mediante

un campo común que es clave primaria en una y clave externa en la otra. Si se elimina

una instancia de la tabla en la cual el campo común es clave primaria, por defecto se

eliminan todas las instancias correspondientes en la segunda tabla.

1.4.2- Nivel de acceso a la base de datos en MySQL

Para abordar estos aspectos se utiliza como referencia el libro “MySQL 5.5 Reference

Manual” de 2012. (Oracle, 2012)

MySQL cuenta con un sistema de privilegios y contraseñas que proporciona gran

seguridad a los datos. Este sistema es muy flexible y seguro, y permite verificación

basada en el anfitrión (host). Las contraseñas son seguras porque todo el tráfico de

contraseñas está cifrado cuando se conecta con un servidor. Para argumentar estas

ideas se abordan los siguientes elementos.

2 Integridad referencial: Permite borrar un registro que esté “enlazado” por medio de una “relación” entre tablas

sin que se cumplan ciertas dependencias, de esta forma no se tienen datos huérfanos que puedan ser inconsistentes con el sistema (Schwartz et al., 2012).

25


1.4.2-1. El sistema de privilegios de acceso de MySQL

La función primaria del sistema de privilegios de MySQL es autenticar un usuario que

se conecta a partir de un anfitrión (host) dado y asociar dicho usuario con privilegios en

una base de datos, como SELECT, INSERT, UPDATE y DELETE. Funcionalidad

adicional incluye la habilidad de tener usuarios anónimos y concederles privilegios para

funciones específicas de MySQL, tales como, operaciones administrativas LOAD DATA

INFILE.

Internamente, el servidor guarda información de privilegios en las tablas de permisos de

la base de datos mysql (es decir, en la base de datos llamada mysql). El servidor

MySQL lee el contenido de estas tablas en la memoria cuando se inicia y las bases de

las decisiones de control de acceso a las copias en memoria de las tablas de permisos.

El sistema de privilegios de MySQL asegura que todos los usuarios pueden realizar

solo las operaciones permitidas a los mismos.

Como usuario, cuando se conecta a un servidor MySQL, su identidad se determina

mediante el equipo desde el que se conecta y el nombre de usuario que se especifique.

Cuando efectúe peticiones tras conectar, las subvenciones del sistema privilegios de

acuerdo a su identidad y lo que quieres hacer.

MySQL considera tanto su nombre de host y el nombre de usuario al identificarle. Ya no

hay razón por la cual asumir que un nombre de usuario dado pertenece a la misma

persona en todos los anfitriones (hosts).

1.4.2-2. Control de acceso de MySQL

Implica dos etapas cuando se ejecuta un programa cliente que se conecta con el

servidor:

Etapa 1: El servidor acepta o rechaza la conexión a la base de su identidad y si se

puede verificar su identidad proporcionando la clave correcta.

Etapa 2: Asumiendo que se puede conectar, el servidor comprueba cada comando que

ejecuta para determinar si tiene privilegios suficientes para llevarla a cabo.

26


Si se cambian (por el usuario o alguien más) sus privilegios mientras está conectado,

los cambios no tienen por qué tener efecto inmediatamente para la próxima sentencia

que se emite.

1.4.3- MySQL Workbench

Según Oracle (2012) MySQL Workbench es una herramienta gráfica para trabajar con

servidores MySQL (versión 5.1 en adelante) y base de datos. Sus tres principales áreas

de funcionalidad son:

Desarrollo de SQL: Permite crear y administrar conexiones a servidores de

base de datos. Así como configurar los parámetros de una conexión. Además,

provee la capacidad de ejecutar consultas de SQL en las conexiones de base de

datos usando el editor SQL built-in.

Modelado de datos: Permite crear modelos de esquemas de base de datos

gráficamente, así como ingeniería inversa y directa entre un esquema y una

base de datos en vivo y editar todos los aspectos de la base de datos usando el

Editor de Tablas. Este editor provee facilidades fáciles de usar para editar:

tablas, columnas, índices, inserciones, privilegios, entre otras.

Administración de servidores: Permite crear y administrar instancias de

servidores.

1.5. Consideraciones finales del capítulo

Partiendo de un análisis del capítulo se arriban a las siguientes consideraciones:

• La identificación de sistemas trata con el problema de construir modelos

matemáticos de sistemas dinámicos basándose en datos observados del sistema. Es

importante lograr una buena identificación que proporcione modelos de orden

reducido más fáciles de utilizar.

• Es de gran importancia almacenar en bases de datos, los datos provenientes de la

identificación para su posterior análisis o para ser usado en futuras investigaciones.

• El MATLAB es un software matemático de gran potencialidad y posee el Toolbox de

Base de Datos (Database Toolbox) como poderosa herramienta que permite mover

los datos (tanto de importación y exportación) a bases de datos relacionales.

27


• Se empleará MySQL como sistema gestor de base de datos, pues es de fácil

configuración, permite la comunicación con MATLAB y se encuentra muy

referenciado su uso en aplicaciones ingenieriles, así como la herramienta gráfica

MySQL Workbench.

• Dada la importancia del análisis de los datos provenientes del proceso de

identificación se decide desarrollar la función saveintodb que se encargue de

almacenar estos datos provenientes del MATLAB en una base de datos

implementada en MySQL.

28

Capítulo 2 Saveintodb. Función para obtener información de modelos estimados y almacenarlos en la base de datos

MATLAB_DATA de MySQL

Capítulo 2. Saveintodb. Función para obtener información de modelos

estimados y almacenarlos en la base de datos MATLAB_DATA de MySQL

El desarrollo de la investigación parte de las consideraciones teóricas presentadas con

anterioridad, las cuales demuestran aspectos básicos dentro del ámbito de la

identificación de procesos. Atendiendo a las necesidades que demanda actualmente la

ingeniería en cuanto a la validación de modelos matemáticos, el proyecto responde a

su objetivo general de crear una función para obtener información de modelos

estimados y almacenarlos en la base de datos MATLAB_DATA de MySQL, con la

siguiente propuesta:

2.1. Función saveintodb. Aspectos generales

Saveintodb es una función que se pretende añadir a la extensa colección de funciones

de MATLAB. Esta permite al usuario crear la base de datos relacional MATLAB_DATA

en MySQL, si no existe, así como obtener la información que brinda MATLAB de

modelos estimados seleccionados por el usuario y exportarla a dicha base de datos.

Esta selección se realiza después de haber estimado dichos modelos con el uso del

Toolbox de Identificación de Sistemas, mediante el la herramienta de Identificación de

Sistemas GUI o a través de los comandos de MATLAB.

Con saveintodb se crean tablas, y en cada uno de sus campos es almacenada

información de interés sobre cada modelo seleccionado por el usuario.

Por ejemplo: Un usuario estima diez modelos paramétricos con el Toolbox de

Identificación de Sistemas y puede exportarlos a la base de datos MATLAB_DATA,

después de conectado. Posteriormente, en el siguiente orden, se introducen como

argumentos de la función: la variable de conexión, las que contienen los identificadores

del proceso y el lazo, la que contiene los datos de validación y las variables que se

corresponden con los modelos estimados. Es importante señalar, que los argumentos

deben introducirse en el orden especificado y todas las entradas deben estar

separadas por comas. Si el procedimiento es correcto, se almacenan los datos en la

base de datos en cuestión para un uso futuro.

Sintaxis de la función: saveintodb(conn,'proc','loop',val_data,model1,model2,…,modeln)

29



2.1.1. Características de la función saveintodb

Es una función primaria3.

En su diseño se utilizó el paradigma de programación estructurada.

Escrita en lenguaje m de MATLAB y SQL.

No es un paquete de funciones, es una función única que emplea funciones de

la biblioteca de MATLAB.

Es diseñada para exportar información a una base de datos de MySQL que

puede ser creada por la función misma automáticamente (por defecto la base de

datos se llama MATLAB_DATA). De otro modo puede ser creada por el usuario

en el servidor MySQL.

Permite la exportación de datos, al unísono, desde un puesto de trabajo local y/o

puestos de trabajos remotos a través de la red.

Las tablas necesarias son creadas por la función de forma predeterminada

dentro de la base de datos MATLAB_DATA.

Como se muestra en la primera línea de código ejecutable, en la cual la función

es declarada: saveintodb(conn,'proc','loop',val_data, varargin4), la función admite

como mínimo cinco entradas y no tiene ninguna salida. O sea, está concebida

para al menos cinco entradas, donde no varía la variable de conexión, la variable

que contiene el identificador del proceso al que pertenecen los modelos, la

variable que contiene el identificador del lazo dentro del proceso y la variable

que contiene el set de datos usados para la validación5, sin embargo el número

de modelos puede aumentar y con ello el número de entradas. Es necesario

especificar, que en una inserción los modelos deben pertenecer a un mismo lazo

y por ende a un mismo proceso.

Estas variables deben ser introducidas en un orden específico:

3 Función primaria: Es una función visible a otras funciones que están fuera del archivo en el cual ella está definida

(Mathworks, 2013). 4 La sentencia “varargin” es usada solo dentro de una función para contener argumentos de entrada opcionales

pasados a la función. El argumento varagin tiene que ser declarado como la última entrada de la función, coleccionando todas las entradas desde ese punto en adelante (Mathworks, 2013). 5 Set de datos usados para la validación: Son los datos usados para validar un modelo, comparándolo con la salida

del modelo (model output) y aplicarle las pruebas de residuos (residual tests) (Mathworks, 2013).

30



1) Variable de conexión.

2) Variable que contiene el identificador del proceso.

3) Variable que contiene el identificador del lazo.

4) Variable que contiene los datos de validación.

5) El modelo del cual se pretende almacenar información.

Solo almacena modelos lineales paramétricos, de estructuras ARX, ARMAX, BJ

y OE.

Por el momento la función está diseñada para sistemas SISO (Single Input

Single Output).

2.2. Inicialización y puesta a punto

Como un primer paso para su uso y poder sacar mejor provecho de las bondades que

la función saveintodb proporciona es necesario haber instalado los softwares en los que

va a ser usada y configurarlos.

2.2.1. Requerimientos para el uso de la función saveintodb

1) Se requiere tener instalado el software MATLAB. La función ha sido probada en la

versión 7.10.0.499 (R2010a) (win32) de este software.

2) Se precisa de un servidor MySQL. La función ha sido probada en la versión de

servidor: 5.5.14 MySQL Community Server (GPL).

3) Con el objetivo de establecer una comunicación entre MATLAB y dicho servidor es

indispensable instalar un controlador (driver) ODBC o JDBC. Driver probado:

MySQL Connector/ODBC 5.1.

4) Tipos de datos.

La función saveintodb está diseñada para que maneje los siguientes tipos de datos:

Database: Correspondiente a la variable de conexión. La clase database provee

una interfaz de comunicación con los archivos donde está almacenada la

información con respecto a la conexión. Esta clase contiene propiedades y

métodos para obtener información almacenada en la base de datos, relacionada

con la definición de mensajes y señales (Mathworks, 2013)

Char: Cadenas de caracteres correspondientes al identificador del lazo y del

proceso.

31



Iddata: Correspondiente con los datos de validación. Un objeto iddata representa

datos de tiempo-dominio o frecuencia-dominio. Además, estos proveen una

manera estándar de manejar datos en el Toolbox de Identificación de Sistemas

(Mathworks, 2013).

Los siguientes corresponden con los modelos:

Idmodel es una superclase para modelos lineales, es un objeto con el que no se

trata directamente, pues contiene las propiedades comunes de los objetos

modelos idarx, idgrey, idproc, idss e idpoly (Mathworks, 2013), siendo este último

de interés en la investigación, el resto no serán tratados.

Idpoly modelos lineales polinomiales de entrada-salida. Crea un objeto modelo

conteniendo parámetros que describen de forma general estructuras de múltiple-

entrada simple-salida (Mathworks, 2013). De interés estructuras ARX, ARMAX,

BJ y OE.

2.2.2. Configurando el entorno

1) Ejecutar la función que se encuentra programada en un fichero .m de MATLAB.

2) Como cualquier función de MATLAB los datos que va a usar saveintodb deben

estar en el workspace (espacio de trabajo). Si los modelos a exportar son

generados a través de los comandos de MATLAB, estos se encuentran en el

workspace por defecto. Si los modelos fueron generados en la herramienta de

Identificación de Sistemas GUI, estos, y los datos de validación deben ser

exportados al workspace, debido a que no están automáticamente disponibles

en el workspace. Cada modelo se selecciona y por separado se pueden arrastrar

al rectángulo To Workspace en la herramienta de Identificación de Sistemas

GUI. Rápidamente el modelo aparece en el workspace. Ver Figura 2.1.

32



Figura 2.1 Exportar a workspace desde el GUI del Toolbox de Identificación de Sistemas

3) Por último, después de haber importado los modelos y los datos de validación al

workspace, se realiza la conexión con la base de datos a través del comando:

a) Para el uso con ODBC: conn = database('datasourcename', 'username',

'password')

b) Para el uso con JDBC: conn = database('databasename', 'username', 'password',

'driver', 'databaseurl')

En ambos casos el primer argumento es la fuente de datos, abordada

posteriormente, el segundo y el tercer argumento son el usuario y/o contraseña

requeridos para conectarse a la base de datos.

En el segundo caso el cuarto argumento es el tipo de controlador: JDBC, y el quinto

es la estructura del JDBC URL.

Luego de especificados cada argumento, en cada caso, la estructura de la conexión

queda almacenada en la variable conn.

Se recomienda usar la función logintimeout antes de usar el comando database,

para especificar el tiempo máximo en la que se trata de establecer la conexión con

la base de datos.

33



Nota: Si se usa un controlador JDBC, no se necesita configurar una fuente de datos

(data source). Solo se provee el controlador JDBC con la información necesaria sobre

la localización de la base de datos, cuando MATLAB se conecta a la base de datos

usando el comando database.

Para utilizar el Toolbox de Base de Datos con la base de datos y un controlador ODBC,

se debe configurar una fuente de datos. Esta consiste en: “Los datos a los que el

Toolbox de Base de Datos se requiere que acceda, e información acerca de cómo

encontrar estos datos, dígase un controlador, directorio, servidor, o nombres de redes”

(MathWorks, 1998).

En la configuración de la fuente de datos se asigna un nombre a cada base de datos.

Pueden configurarse fuentes de datos locales, para bases de datos que residen en la

PC donde se esté trabajando, o fuentes de datos remotas para bases de datos, que

residen en sistemas conectados en red con la PC en que se está trabajando. Los

procedimientos para configurar fuente de datos locales y remotas no difieren

prácticamente. Para usar las instrucciones apropiadas en la configuración de la fuente

de datos para el uso con controladores ODBC ver Anexo 7 y con controladores JDBC

ver Anexo 8.

2.3. Diseño de diagrama EER6

El diagrama EER es diseñado a partir de interrogantes como: ¿Qué datos se van a

almacenar? ¿De qué forma están estructurados? y ¿Cómo se va a acceder a ellos? En

este sentido son analizados a profundidad cada uno de los elementos descritos en el

subepígrafe: Fase 2. Definición y obtención de la información a almacenar de cada

modelo Con el objetivo de definir las entidades y atributos, y establecer las relaciones

entre dichas entidades.

Teniendo en cuenta tales demandas, se asumen las siguientes entidades y atributos

para el diseño del diagrama EER, ver Tabla 2.1.

6 Diagrama EER: Diagrama del Esquema Relacional del inglés Enhanced Entity Relationships diagram.

34



Tabla 2.1 Entidades-Atributos

Para cada una las entidades se crea una tabla con motor de almacenamiento (engine)

InnoDB7. Sus atributos se convierten en campos de dichas tablas, ver Figura 2.2

Diagrama EER de la base de datos MATLAB_DATA. Por otra parte, con el propósito de

especificar el tipo de datos de cada campo, se analiza el tipo de estructura de cada

atributo, por ejemplo: El atributo nombre es una cadena de caracteres, por lo que se

especifica en el campo name el tipo de datos (varchar), ver Figura 2.2.

2.3.1. Relaciones

El empleo de una base de datos relacional donde se almacenan los datos en tablas

separadas, tiene como característica que estas están relacionadas por un campo

común, lo cual permite velocidad y flexibilidad en el proceso. Para lograr que el lazo

que une a estas tablas relacionales (campo común) pase a la otra tabla como llave

foránea, se crean relaciones entre dichas tablas, con el objetivo de garantizar una

integridad referencial. A partir de esta condición se proponen las siguientes relaciones

entre las tablas creadas:

1- Entre la tabla model y la tabla vector se establece una relación obligatoria uno a

varios (1:V), pues para cada modelo almacenado en la tabla model, existe un vector A,

B, C, D, F, dA, dB, dC, dD y dF, y cada uno de estos vectores puede o no tener varios

7 InnoDB: Es el motor de almacenamiento más popular, diseñado para el procesamiento de transacciones,

específicamente procesamiento de transacciones cortas, la cuales usualmente se completan (Schwartz et al., 2012).

35



valores (los cuales se almacenan en el mismo campo: val). O sea, para cada instancia

de model le corresponden varias instancias de vector. Ver Anexo 6. De esta manera se

maneja también la relación entre la tabla model y la tabla zeros_poles, a cada modelo

le corresponden uno o varios ceros y/o polos en la tabla zeros_poles. Ver Figura 3.14.

2- Entre la tabla model y la tabla step_response se establece una relación obligatoria

(1:V). Para cada modelo de la tabla model existen varios registros de esta segunda

tabla, por ejemplo: los pares de puntos que conforman la curva de la gráfica de

respuesta al paso de un modelo, están almacenados en la tabla step_response. Sin

embargo, todos estos registros pertenecen a un único modelo que está almacenado en

la tabla model. Ver Anexo 1.

3- Existe el mismo tipo de relación entre la tabla model y el resto de las tablas. Tanto la

tabla step_response como el resto de las tablas almacenan pares de puntos que

conforman las curvas de las gráficas: respuesta de frecuencia, análisis de residuos

correlacional, análisis de residuos correlacional-cruzado y espectro de ruido de un

modelo. Aunque se observa una relación entre la tabla model y el resto de las tablas,

estas últimas no se relacionan entre sí. Ver Figura 2.2.

Es importante señalar que el campo común que relaciona la tabla model con las demás

tablas es el id (identificador) de cada modelo, el cual es abordado con mayor

profundidad a continuación.

2.3.2. Índices

Cada tabla creada tiene el mismo comportamiento en materia de índices y los procesa

de la misma forma. Se utilizan llaves primarias (un índice único que no puede contener

valores nulos) e índices ordinarios (que pueden contener duplicados).

La tabla model contiene cinco índices:

id_model: Es del tipo llave primaria, es de Auto Incremento (AI), creado con el objetivo

de proporcionar a cada modelo un identificador único.

id_process: Es un índice ordinario que especifica el proceso al que pertenece cada

modelo.

36



id_loop: Es un índice ordinario, que posee una estrecha relación con el índice explicado

anteriormente, pues id_loop especifica el lazo dentro del proceso al que pertenece cada

modelo.

date: Es un índice ordinario, posibilita acceder a los datos por la fecha en que fueron

creados.

structure: Es un índice ordinario que permite acceder a los modelos según su tipo de

estructura: ARX, ARMAX, BJ u OE .

La tabla step_response contiene dos índices:

id_st_resp: Llave primaria, es de Auto Incremento (AI), creado con el objetivo de cada

registro pueda ser accedido de forma independiente.

id_m: Es una llave foránea referenciada a la tabla model, específicamente al campo

id_model. Creado con el objetivo de identificar todos los registros que pertenecen a un

mismo modelo.

Las demás tablas funcionan del mismo modo, solo que cambia el nombre de la llave

primaria en cada caso, pues dicho nombre coincide con el de la tabla a que

corresponde. Las tablas vector y zeros_poles presentan una particularidad, además del

funcionamiento antes descrito, se agrega otro índice, en la primera (índice v_type), para

especificar el tipo de vector (A, B, C, D, F, dA, dB, dC, dD, dF) al que pertenece cada

valor del campo val, en la segunda (índice z_or_p), para especificar si los valores de los

campos real_part e imag_part (los cuales, en su conjunto, pudieran conformar un

número imaginario) son ceros o polos.

Después de haber establecido las entidades, atributos y haber propuesto las relaciones,

e índices. Se utiliza el software MySQL Workbench versión 5.2.31 CE, para diseñar el

diagrama EER, ver Figura 2.2.

37



Figura 2.2 Diagrama EER de la base de datos MATLAB_DATA

2.4. Diagrama de actividades. Explicación de la programación de la función

saveintodb por fases

El diagrama de actividades fue concebido en cuatro fases, en cada de una de ellas

fueron agrupadas las tareas de la función de acuerdo a su orden lógico.

Nota: Durante la programación de la función se utilizó como planta a modelar el

Secador de pelo (Dryer) encontrado dentro de los demos del propio MATLAB y su

juego de datos de entrada-salida.

38



Figura 2.3 Diagrama de actividades de la función saveintodb

2.4.1. Fase 1: Validación de los argumentos de entrada pasados a la

función saveintodb

En la primera línea de código ejecutable se declara la función saveintodb:

saveintodb(conn,'proc','loop',val_data, varargin)

El primer argumento de entrada (conn) debe coincidir con la variable de conexión

mencionada anteriormente. El segundo y tercer argumento debe corresponder con el

proceso y el lazo al que pertenecen los modelos a exportar en una inserción. El cuarto

argumento de entrada (val_data) debe corresponderse con la variable que contiene los

datos de validación. El quinto argumento, varagin, permite la entrada de múltiples

modelos.

Para el correcto funcionamiento de la función saveintodb se garantiza que los

argumentos de entrada sean lo más fiable posible por lo que se lleva a cabo el

siguiente proceso de validación de los datos.

1- Validación del primer, segundo, tercer y cuarto argumento.

Primero se comprueba que hayan más de cuatro entradas, de lo contrario, el programa

emite un error explicando que no son suficientes entradas. Si hay más de cuatro

39



entradas, se calculan la cantidad de modelos introducidos, y luego se verifica cada

entrada para validarlas según sea su clasificación.

Se comprueba que la primera entrada (variable de conexión) sea del tipo "database" y

que la conexión exista. Posteriormente se chequea la segunda y tercera entrada: deben

ser del tipo "char", pues contienen el proceso y el lazo al que pertenecen el grupo de

modelos a exportar respectivamente. Luego se verifica la cuarta entrada (variable que

contiene el set datos usados para la validación del modelo) que debe ser del tipo

"iddata". Si alguna de las entradas no son del tipo especificado, el programa emite un

error. Si las entradas son del tipo requerido, el programa sigue su curso.

2- Validación de los demás argumentos. (Dependerá de la cantidad de modelos

introducidos).

Se realiza un ciclo for a partir de la cantidad de modelos introducidos que fue calculada.

Esto ocurre con el objetivo de verificar el tipo de datos de cada supuesto modelo. Si el

supuesto modelo no presenta una de las estructuras especificada por las

características de la función, este no es exportado a la base de datos. Cuando cuenta

con la estructura especificada, el modelo sí es exportado. O sea, dentro del ciclo for se

valida o no un modelo, de no ocurrir la validación, se emite un alerta (warning)

reportando el modelo que no fue validado. De ocurrir la validación, este modelo se

convierte en "modelo actual". Para el trabajo con este modelo actual, se crea una

variable temporal a la cual, él es asignado, denominada current_model.

2.4.2. Fase 2. Definición y obtención de la información a almacenar de cada

modelo

Cuando se emplea el término guardar, o almacenar un modelo, se refiere a exportar a

la base de datos cierta información de ese modelo que es imprescindible para análisis

posteriores. O sea, con esta información se crean experiencias que pueden ser usadas

por otros programas en un futuro para comparar dichos modelos, análisis estadísticos,

toma de decisiones, etc.

La información que se exporta a la base de datos está conformada por los siguientes

elementos:

40



El identificador del proceso al que pertenecen los modelos. Es introducido por el

usuario como argumento de la función.

El identificador del lazo dentro del proceso: Es pasado por el usuario como

argumento de la función.

La fecha en que es guardado el modelo: El servidor facilita una fecha y un

formato de fecha global para sus usuarios, lo cual permite eliminar confusiones,

pues las PCs de los diferentes usuarios pudieran tener establecidos diferentes

fechas y/o formato de fechas. De esta forma MATLAB obtiene la fecha que

proporciona el servidor mediante la sintaxis fetch(conn, 'SELECT curdate()').

Donde el primer argumento es la variable de conexión y el segundo es una

consulta de SQL que devuelve la fecha actual.

Tipo de estructura: Se obtiene mediante un algoritmo que verifica si difiere o no

de cero cada coeficiente na, nb, nc, nd, nf, nk (coeficientes que son explicados

posteriormente). Cada estructura ARX, ARMAX, BJ y OE tiene una configuración

distinta respecto a sus coeficientes, por ejemplo: Un modelo de estructura ARX

presenta los coeficientes na, nb y nk, por otro lado uno de estructura BJ

presenta los coeficientes nb, nc, nd, nf y nk.

Nombre: Se obtiene a través del uso del caracter “.” que asociado a una variable

permite acceder a sus propiedades, por ejemplo: current_model.name

FIT: Se obtiene mediante la función:

[YH,FIT,X0]=compare(val_data,current_model), FIT constituye una salida de la

función compare.

Los coeficientes na, nb, nc, nd, nf, nk constituyen órdenes y retrasos de los

polinomios, los cuales se encuentran especificados como enteros. Cada uno de

estos coeficientes se obtiene a través del uso del caracter “.” por ejemplo:

current_model.na

Vectores:

o A, C, D polinomios especificados como fila de vectores.

o B, F polinomios especificados como fila de vectores para entrada simple o

matrices múltiple-filas para múltiples entrada. Esta última condición no es

41



admitida por la función saveintodb, pues dicha función es diseñada hasta el

momento para sistemas SISO.

o dA, dB, dC, dD, dF. Desviaciones estándar estimadas de los polinomios.

Cada uno de estos vectores se obtienen mediante [A,B,C,D,F,dA,dB,dC,dD,dF]=

polydata(current_model), como se observa los vectores constituyen salidas de la

función polydata.

Los ceros (raíces del numerador) y los polos (raíces del denominador) del

modelo. Los cuales se obtienen a través de [z,p,k] = zpkdata(current_model), las

salidas z y p de la función refieren a los ceros y los polos respectivamente.

La información sobre la respuesta al paso (step response), respuesta de

frecuencia (frequency response), análisis de residuos (residual analysis) y

análisis del espectro de ruido (noise spectrum) de un modelo, es de gran interés

en la pesquisa. Dicha información se obtiene mediante las gráficas generadas

por las funciones step, bode, resid. Para recopilar estos datos basta con acceder

a los registros donde MATLAB los almacena. Esto es viable a través de los

handles (manejadores de cada figura), con el objetivo final de obtener los pares

de puntos, que conforman cada una de las curvas representadas en las gráficas.

A manera de ejemplo, se explicará las líneas de código que en su conjunto tienen la

función de extraer del MATLAB la información mencionada anteriormente:

La figura Step Response generada mediante la función step, está compuesta sólo por

una única gráfica: abscisa (x_step) y ordenada (y_step).

43 – step(current_model);

44 – h=gcf;

45 – h1 = get(h,'children');

46 – h11 = get(h1,'children');

47 – x_step = get(h11(1),'XData')';

48 – y_step= get(h11(1),'YData')';

49 – close(gcf);

42



Como se observa en la línea 43 se grafica step response, con el objetivo de obtener los

pares de puntos mencionados previamente.

En la línea 44 se obtiene el handle de la figura actual (step response), para acceder a

los registros donde MATLAB almacena los datos graficados en dicha figura. Con el

empleo de este handle:

o Se obtienen los hijos (children) de la figura (línea 45): en este caso es una única

gráfica la que constituye a step response.

o Se obtienen los hijos de esta gráfica (línea 46) que son los que permiten acceder

a los vectores que conforman cada uno de sus ejes. Estos vectores: XData y

YData, se crean en MATLAB por defecto y contienen los valores de la abscisa y

la ordenada respectivamente. Asimismo, la información que contienen XData y

YData se le asigna a las variables x_step y y_step respectivamente, para luego

exportarla a la base de datos (líneas 47 y 48).

Por último en la línea 49, se cierra la figura actual (step response).

La figura Noise Spectrum generada mediante la función bode, está compuesta sólo

por una única gráfica: abscisa (x_noise) y ordenada (y_noise), el algoritmo para la

obtención de los valores de sus ejes es prácticamente igual al de la figura de Step

Response.

La figura Frequency Response generada por la función bode, se conforma por dos

gráficas: en la primera es computada la magnitud y en la segunda la fase de la

respuesta de frecuencia de un modelo. Ambas se componen por la abscisa

(x_frequency) y las ordenadas (y1_frequency) y (y2_frequency) de la primera y

segunda gráfica respectivamente.

53 – bode(current_model)

54 – h=gcf;


56 – h11 = get(h1(1),'children');

57 – x_frequency = get(h11(1),'XData')';

43



58 – y1_frequency= get(h11(1),'YData')';

59 – h12 = get(h1(2),'children');

60 – y2_frequency = get(h12,'YData')';

61 – close(gcf);

El algoritmo funciona de forma similar al explicado anteriormente con la figura step

response, con la diferencia de que ahora la figura actual es frequency response y que

se obtienen dos gráficas en vez de una.

Cuando se obtienen los hijos de esta figura (línea 55), se obtienen las dos gráficas

mencionadas con anterioridad.

Primero se obtienen los hijos de la primera gráfica (línea 56) para tener acceso a sus

vectores XData y YData y así asignar la información a x_frequency y y1_frequency

respectivamente (líneas 57 y 58).

Luego se obtienen los hijos de la segunda gráfica (línea 59) para tener acceso al vector

YData y asignar la información a y2_frequency (línea 60). No es necesario acceder al

vector XData, pues coincide con el obtenido en la primera gráfica.

La figura Residual Analysis generada por la función resid, se compone por dos

gráficas: correlational residual analysis (análisis de residuos correlacional) y cross

correlational residual analysis (análisis de residuos correlacional-cruzado). Cada una de

ellas está constituida por una abscisa y una ordenada: (x1_resid, y1_resid) y (x2_resid,

y2_resid).

65 – resid(current_model,val_data)

66 – h=gcf;


68 – h11 = get(h1(1),'children');

69 – x2_resid = get(h11(2),'XData')'; %residual_analysis_cross_correlation

70 – y2_resid= get(h11(2),'YData')';

%--------------------------------------

44



72 – h12 = get(h1(2),'children');

73 – y1_resid = get(h12(2),'YData')'; %residual_analysis_correlation

74 – x1_resid = get(h12(2),'XData')';

75 – close(gcf);

Se sigue la misma metodología del caso anterior, con la diferencia de que es ahora

Residual Analysis la figura actual (línea 66). Además en las gráficas que componen

dicha figura no coinciden las abscisas, por lo que se accede a XData de ambas

gráficas. Por último, a cada una de las variables x1_resid, x2_resid, y1_resid y y2_resid

se le hace corresponder con su XData y YData (líneas 74, 69, 73 y 70).

2.4.3. Fase 3. Creación de base de datos y tablas desde MATLAB

Luego de diseñado el diagrama EER en Workbench, se genera el código en el lenguaje

SQL, que recrea cada uno de los elementos y características de dicho diagrama. Como

se pretende que la creación de la base de datos sea transparente al usuario, se incluye

dentro del código de la función saveintodb las sintaxis de SQL generadas por el

Workbench. Esto es viable a través del uso de la función exec de MATLAB. Dicha

función permite ejecutar sintaxis de SQL en un servidor MySQL desde MATLAB.

Aunque pareciera que cada vez que se ejecuta la función saveintodb se crea la base de

datos MATLAB_DATA y cada una de sus tablas, es necesario aclarar que esto no

sucede. Dentro del código SQL se especifica que las tablas se crean si no existen con

anterioridad, por ejemplo: 'create table if not exists MATLAB_DATA.model'.

2.4.4. Fase 4. Procedimiento para el almacenamiento de datos a las tablas

Es importante garantizar que el proceso de inserción en las tablas ocurra con fiabilidad;

pues es imperativo dar la garantía de que se hayan almacenado todos los datos de un

modelo, y no, que se almacenen a medias. Por ejemplo: No es práctico almacenar la

mitad de los pares de puntos de una de las curvas, pues para un correcto análisis

posterior, se necesitan todos los pares de puntos de dicha curva de lo contrario no

sería efectivo dicho análisis. Esta condición conduce, a que se necesita concluir un

grupo de sentencias que logren consumarse todas, o fallar como una unidad.

45



Para lograr lo planteado anteriormente se usa un algoritmo llamado transacción. El cual

se puede definir como: “Un grupo de consultas (queries) que son tratadas

atómicamente8, como una sola unidad de trabajo. Si el DBMS puede aplicar el grupo

entero de consultas a la base de datos, lo hace, pero si no puede aplicar alguna de

ellas, por un choque (crash) u otra razón, ninguna de ellas es aplicada. Es todo o nada”

(Schwartz et al., 2012).

En consecuencia de lo explicado anteriormente, para el diseño de la base de datos se

concibieron motores de almacenamiento InnoDB, como fue mencionado en la sección

2.3. Este motor de almacenamiento constituye la opción probada más estable y mejor

integrada, hasta el momento (Schwartz et al., 2012), lo cual nos brinda transacciones

seguras.

Según DuBois (2002) una transacción se puede lograr manipulando el modo auto-

comprometer (auto-commit) de MySQL, para permitir transacciones de múltiples

sintaxis y luego consumarlas o no mediante commit o rollback en cada caso; estos

términos y su filosofía de trabajo se explican a continuación. (DuBois, 2002)

En MATLAB esto es posible mediante el uso de las sentencias try-catch y las APIs

commit y rollback, si la ejecución de try emite algún error se ejecuta catch. Por ejemplo:

Se asume que todo el proceso de exportación debe funcionar como una transacción.

Primero se inicia el algoritmo con la sentencia try (línea 155), luego se pone en off la

bandera auto-commit (línea 156), de esta forma queda marcado el inicio de la

transacción. Si se logra exportar todos los datos de un modelo se consuma la inserción

mediante la API commit (la cual marca el final de la transacción en la línea 302). Si

alguno de estos datos no es exportado, se ejecuta la sentencia catch (línea 304), la

cual permite desechar los datos que sí fueron exportados a la base de datos, mediante

la API rollback (línea 308). Si esto último ocurre se le notifica al usuario a través de una

alerta (línea 305).

155- try

8 Atomicidad: Una transacción tiene que funcionar como una simple e indivisible unidad de trabajo. La transacción

completa es aplicada (commit) o no (rolled back). Cuando una transacción es atómica no existe algo como: Una transacción parcialmente completada (es todo o nada). (Schwartz et al., 2012).

46



156- set(conn, 'AutoCommit', 'off');

.

.

Cuerpo de la transacción

.

.

302- commit(conn);

304- catch exception

305- warning('model in position %d was not saved\n Unexpected error

ocurred',ks+stdargin);

308- rollback(conn);

312- end

En el cuerpo de la transacción se ejecuta el procedimiento para el almacenamiento de

datos a las tablas, el cual es descrito en los siguientes subepígrafes para cada tabla.

2.4.4-1. Tabla model

El procedimiento para exportar a la tabla model se basa en la función insert (línea 157),

el primer argumento de esta función es la variable de conexión, el segundo especifica

la tabla en la que se va a almacenar, el tercero: la variable que contiene la relación de

campos y el cuarto los datos a exportar. Previamente se almacena en la variable

exdata (línea 153), la información referida a los datos que se desean exportar y en la

variable colnames (línea 154), cada campo que almacena esta información.

153 – exdata = {proc, loop, datestr(now,26), structure ,current_model.name, FIT,

current_model.na, current_model.nb, current_model.nc , current_model.nd,

current_model.nf , current_model.nk};

154 –. colnames = {'id_process', 'id_loop','date', 'structure' ,'name', 'FIT', 'na', 'nb', 'nc',

'nd', 'nf','nk'};

47



157 – insert(conn, 'model', colnames , exdata);

Como se observa en la Tabla 3.1, una vez que se exporta un modelo a esta tabla, solo

es almacenada la información en un registro, distribuida en sus diferentes campos.

Partiendo de la estructura de la tabla model, es necesario retomar observaciones ya

referidas, en cuanto a que la columna id_model es llave primaria de esta tabla. Por

tanto, después de insertado un modelo en la tabla model, es decir, luego de insertado

un registro se obtiene el id de este modelo. Esto último se logra mediante la función

fetch(conn, 'SELECT MAX(id_model) from model'), el primer argumento es la variable

de conexión y el segundo es una consulta de SQL que devuelve el mayor valor del

campo id_model, o sea accede al id del modelo que acaba de ser insertado. De esta

forma queda almacenado en la variable last_id el valor del id del modelo actual, así

este valor se inserta en las demás tablas, especificando qué información pertenece a

un mismo modelo, lo cual demuestra las relaciones antes explicadas.

2.4.4-2. Tabla step_response

Para esta tabla se usa un algoritmo similar al de la tabla model, sin embargo, difieren

en que al exportar a la tabla step_response, se insertan múltiples registros en una

inserción. En este sentido el número de registros se corresponde con el número de

pares de puntos de la gráfica respuesta al paso. Ver Anexo 1.

Con la finalidad de exportar los datos a la tabla step_response, se hace coincidir el

vector x_step y y_step con el campo del mismo nombre en la tabla. Para especificar

que todos estos datos pertenecen a un mismo modelo se crea la variable

current_id_model (línea 164). Esta es igualada al vector x_step, con el objetivo de que

current_id_model, ahora vector, cuente exactamente con la misma longitud de x_step y

y_step . Cada uno de los valores de current_id _model, es remplazado por el contenido

de la variable last_id (línea 167), la cual contiene el id del modelo al que pertenecen

estos datos. Ver Anexo 1.

164 – current_id_model=x_step;

165 – elements = length(current_id_model);

166 – for n=1:elements

48



167 – current_id_model(n)=last_id;

168 – end

169 – pre_exdata = {current_id_model , x_step , y_step};

170 – exdata = cell2mat(pre_exdata);

Al emplear la función insert, se hace coincidir el vector current_id_model con el campo

id_m, pues la tabla model está relacionada con la tabla step_response como se explica

en el diagrama EER. El campo mencionado anteriormente está relacionado con el

campo id_model de la tabla model, pues este segundo es llave foránea del primero, lo

que justifica que funcione como índice en la tabla step_response.

Al igual que cuando se insertan datos en la tabla model, se usa exdata como variable

de datos, pero como es explicado anteriormente, en este caso se introducen de una

vez múltiples registros: tres vectores en forma de columnas (línea 169). Estos vectores

antes de ser insertados, son convertidos a una matriz mediante la función cell2mat

(línea 170), así lo requiere la función insert para insertar múltiples registros a la vez.

2.4.4-3. Tabla noise_spectrum

Se usa el mismo procedimiento del caso anterior, solo que current_id_model es

igualado a x_noise, además se hace coincidir las variables x_noise y y_noise con los

campos que llevan el mismo nombre. Ver Anexo 5.

2.4.4-4. Tabla frequency_ response

Se usa la misma metodología del caso anterior, solo que current_id_model es igualado

a x_frequency, además se hace coincidir las variables x_frequency, y1_frequency y

y2_frequency con los campos que llevan el mismo nombre. Ver Anexo 2.

2.4.4-5. Tablas correlational_residual_analysis y

cross_correlational_residual_ analysis

Para insertar los datos en estos gráficos, se sigue la metodología usada en los casos

previos. Se reevalúa current_id_model para cada caso y se hacen coincidir las

variables x1_resid, y1_resid (para la primera tabla) x2_resid, y2_resid (para la segunda

tabla) con las columnas con el mismo nombre. Ver Anexo 3 y Anexo 4.

49



2.4.4-6. Tabla zeros_poles

Se utiliza el procedimiento expuesto en los casos anteriores referido a la forma de

insertar la información. Solo que antes de obtener la matriz final que posee los datos a

exportar se crean dos matrices previas, la primera contiene los ceros y la segunda

contiene los polos. Para especificar si el registro contiene datos de un cero (se inserta

un 0) o si contiene datos de un polo (se inserta un 1) es usado el índice z_or_p. Ver

Figura 3.14.

2.4.4-7. Tabla vector

En esta tabla la metodología cambia en cuanto a la forma de insertar la información,

pues los campos no tienen el mismo tipo de datos. Específicamente el campo v_type es

usado para almacenar cadenas de caracteres (siendo estas el nombre de los vectores

que devuelve la función polydata), mientras que los demás campos son enteros o

decimales. Esto significa que no se puede crear una matriz con los datos a almacenar,

como se hace en los casos anteriores.

En lugar de insertar una matriz con los datos, se inserta un registro a la vez, por

ejemplo: el primer valor del vector A, el nombre del tipo de vector al que pertenece ('A')

y el id del modelo al que pertenece. Luego el segundo valor de este mismo vector con

los restantes campos, y así sucesivamente, hasta que se almacenen todos los valores

de este vector para comenzar con el siguiente, en tanto se almacene el último valor del

último vector. Ver Anexo 6.

Todo este mecanismo de inserción en las tablas ocurre dentro de la última fase del

diagrama de actividades. A partir del cual, al final de esta cuarta fase ocurre una

bifurcación, pues si no han sido almacenados todos los modelos, se retorna a la

primera fase. Esto es resultado del ciclo for mencionado en la fase uno, el cual se

realiza a partir de la cantidad de modelos introducidos que fue calculada. Es decir,

hasta que no se almacene el último modelo introducido como argumento en la función

saveintodb, dicha función no llega a su estado final, en el cual se concluye la

comunicación entre MATLAB y la base de datos MATLAB_DATA.

50



2.5. Consideraciones finales del capítulo

La estructura de la base de datos (reflejada en el diagrama EER) es simple y no

admite valores nulos dentro de las tablas, lo cual garantiza en gran medida la

integridad de los datos.

El uso de las transacciones, a la hora de exportar los datos, asegura que se

almacene toda la información de interés de un modelo y no a medias.

La función prevé los errores más comunes que pudiera cometer el usuario y advierte

mediante un grupo de alertas, que le indican la naturaleza de dichos errores en cada

caso.

51

Capítulo 3 Ejemplificación de la función. Aspectos económicos

Capítulo 3. Ejemplificación de la función. Aspectos económicos

3.1. Ejemplificación de la función

o Naturaleza de los datos

Con el objetivo de realizar pruebas a la función “saveintodb” y comprobar su correcto

funcionamiento, se pretende utilizar un juego de datos diferentes al que se utilizó

durante el proceso de creación de dicha función. Para ello se escogió un juego de

datos procedentes del proceso de floculación de una planta de tratamiento de

residuales de la refinería “Camilo Cienfuegos”. La muestra consta de 165 valores de

pares de entrada salida, donde la salida es el flujo de recirculación a flotadores y la

entrada su valor deseado (señal PRBS).

El proceso de floculación de dispersiones de petróleo en agua puede lograrse

añadiendo un agente floculante, como es el caso de los iones de metal relativamente

grandes.

En este proceso puede reducirse la carga electrostática de la superficie de las

partículas coloidales y con ello su efecto repelente. Las partículas coloidales con igual

carga pueden ser atraídas y adsorbidas al mismo tiempo por agentes floculantes, como

productos hidrolíticos de sales metálicas con una alta carga.

La floculación, y con ella la desestabilización del coloide, puede lograrse adicionando

medios floculantes como polímeros polares o iónicos de moléculas grandes, que unen

el potencial Zeta en aglomerados mayores, al formar una red de partículas coloidales.

3.1.1. Procedimiento para el uso de la función

Luego de identificado los modelos, estos se deben exportar al workspace de MATLAB.

Posteriormente, mediante el uso de la función saveintodb pueden ser guardados en la

base de datos. Lo descrito anteriormente se logra a través de los siguientes pasos:

Paso 1. Cargando los datos a exportar en el workspace de MATLAB.

Si el proceso de identificación fue llevado a cabo a través de los comandos de

MATLAB, los modelos y los datos de validación se encuentran en el workspace por

defecto.

52


Si los modelos fueron generados en la herramienta de Identificación de Sistemas GUI,

los mismos y los datos de validación deben ser importados al workspace.

Nota: Para más información, ver subepígrafe 2.2.2.

Paso 2. Creando la conexión con la base de datos.

Mediante el comando database se crea la conexión con la base de datos.

Nota: Para más información, ver subepígrafe 2.2.2.

Paso 3. Llamando la función.

Se invoca la función mediante su sintaxis. En este paso se le introducen todos los

argumentos requeridos y los modelos que se deseen guardar.

Nota: Para más información ver característica número ocho del subepígrafe 2.1.1.

3.1.2. Ejemplo del uso de la función y comprobación de los datos

insertados

Se importa a la herramienta de Identificación de Sistemas GUI el juego de datos

entrada-salida provenientes de un lazo dentro del proceso de floculación, perteneciente

a la planta de tratamiento de residuales de la refinería de Cienfuegos. Luego de tratado

este juego de datos, el cual es nombrado flocdata, se estiman cuatro modelos, como se

muestra en la Figura 3.1. Posteriormente se exportan al workspace (ver Figura 3.2.) y

se crea la conexión con el fin de utilizar la función saveintodb.

Figura 3.1 Modelos estimados a partir del juego de datos flocdata.

Figura 3.2 Workspace de MATLAB.

53


A continuación se muestra el uso de la función, a la cual se le introducen la variable de

conexión (conn), los identificadores del proceso y el lazo (proc y loop respectivamente),

también los datos de validación (flocdata) y los cuatro modelos identificados (arx541,

oe321, amx2221, n4s4). En relación a estos modelos: el primero es de estructura ARX,

el segundo OE, el tercero ARMAX y el cuarto está representado en el espacio-estado.

Figura 3.3 Uso de la función saveintodb en la ventana de comandos de MATLAB.

Como se puede apreciar (en la Figura 3.3) el intento de insertar el cuarto modelo (n4s4)

falla y la función emite una alerta, pues como muestra la Figura 3.4 este es un modelo

lineal de espacio estado, para el cual la función no está diseñada.

Figura 3.4 Modelo n4s4: modelo lineal de espacio-estado.

Figura 3.5 Modelo arx541 de estructura ARX.

También se observa en la Figura 3.3 que los demás modelos sí fueron exportados

“supuestamente”, y que la conexión fue cerrada. El resto de los modelos sí presentan

estructuras admitidas por la función.

Por otra parte, para comprobar que la inserción de los modelos fue un éxito, se

compara la tabla model (tomada del MySQL Workbench y mostrada en la Tabla 3.1

Tabla model tomada de MySQL Workbench.), con la Figura 3.3. Se puede arribar a la

conclusión que los tres modelos, que presentan estructuras admitidas por la función,

fueron almacenados correctamente.

54


Tabla 3.1 Tabla model tomada de MySQL Workbench.

Para corroborar que los datos insertados en la tabla model y el resto de las tablas,

coinciden con los datos reales del modelo, se toma como ejemplo el modelo arx541.

Del mismo, se extraen sus datos de interés, mediante comandos específicos de

MATLAB en la ventana de comandos de dicho software y se comparan con los

registros correspondientes a cada dato en cada una de las tablas.

Nota: Es importante detallar que el campo id_model constituye el identificador del

modelo arx541 y es inicializado en uno. El valor de este campo es heredado por las

demás tablas para especificar que los registros que lo posean pertenecen a dicho

modelo arx541.

Analizando la Figura 3.2 (ver variables proc y loop) y Tabla 3.1 (ver campos id_process

e id_loop) se puede observar que coincide el identificador del proceso y el lazo al que

pertenecen los modelos. En la Figura 3.5 se comprueba que el modelo presenta una

estructura ARX, la cual fue almacenada en el campo structure de la Tabla 3.1. La

Figura 3.6 y la Figura 3.7 muestran el mismo FIT, nombre y coefecientes, que fueron

almacenados en el primer registro de la Tabla 3.1, dicha tupla pertenece al modelo

arx541.

Figura 3.6 FIT del modelo arx541. Figura 3.7 Órdenes y retrasos de los polinomios, nombre del modelo arx541.

Con el propósito de verificar que los pares de puntos que conforman las curvas de las

gráficas: Respuesta al paso, respuesta de frecuencia, espectro de ruido y análisis de

residuos, coinciden con sus tablas correspondientes, se grafica cada uno de estas

gráficas en MATLAB, usando los comandos del Toolbox de Identificación de Sistemas

55


como muestra la Figura 3.8. Se toman algunos puntos de ejemplo en cada curva y

se muestran los registros correspondientes a cada uno de esos puntos.

Figura 3.8 Funciones del Toolbox de Identificación de Sistemas que generan las gráficas de interés.

Como se puede observar en el campo id_m de la Tabla 3.2 está almacenado el valor

“uno” lo cual indica que estos valores pertenecen al modelo arx541. También se puede

apreciar, en esa misma tabla, que los puntos coinciden con los mostrados.

Tabla 3.2 Segmento de la tabla step_response de la base de datos perteneciente al modelo arx541.

Figura 3.9 Gráfica de respuesta al paso del modelo arx541.

Los análisis que pueden realizarse con respecto al resto de las gráficas y sus tablas

correspondientes, demuestran que para estas ocurre lo mismo que en el caso

presentado anteriormente. A partir de estas conclusiones sólo se muestran a

continuación.

56


Tabla 3.3 Segmento de la tabla frequency_response.

Figura 3.10 Gráfica de respuesta de frecuencia del modelo arx541.

Tabla 3.4 Segmentos de las tablas correlational_residual_analysis (superior) y cross_correlational_residual_analysis (inferior).

Figura 3.11 Gráfica de análisis de residuos del modelo arx541.

57


Tabla 3.5 Segmento de la tabla noise_spectrum.

Figura 3.12 Gráfica de espectro de ruido.

Para comprobar los vectores se utilizó el comando de MATLAB especificado en la

Figura 3.13, sus resultados se pueden comparar con la Tabla 3.6.

Tabla 3.6 Segmento de la tabla vector.

Figura 3.13 Ventana de comandos mostrando los resultados de la función polydata.

58


Los ceros y polos del modelo se comprueban mediante el comando zpkdata de

MATLAB como se muestra en la Figura 3.14, y los resultados se comparan con la Tabla

3.7.

Nota: El campo z_or_p de la Tabla 3.7, es llenado con ceros, señalando que el

registro posee datos de un cero del modelo, o con unos, indicando que el registro

posee datos de un polo del modelo.

Tabla 3.7 Segmento de la tabla zeros_poles perteneciente al modelo arx541.

Figura 3.14 Resultados de la función zpkdata.

3.2. Análisis económico

Los principales elementos de gastos en los que se ha incurrido en el desarrollo de la

presente investigación son aquellos relacionados con los gastos por concepto de

salario, energía y transportación; los mismos comprendidos en los meses de enero a

mayo, cinco meses en el período ( ), del presente año. El resto de los elementos de

gastos, tales como materias primas y materiales auxiliares, amortización y otros gastos

monetarios se consideran despreciables, aun cuando deban ser tenidos en cuenta en la

fase de implementación de esta herramienta. (Portuondo Pichardo, 1985)

Las principales consideraciones y cálculos relacionados a los gastos de salario son los

siguientes:

59


Se asume que el tiempo de atención directa y de investigación del tutor es de 6

para un total de 120 , con un fondo de tiempo del tutor de 900

. Lo anterior representa un 13.33% del salario total del tutor, el cual es de

899.18

(que incluye 9.09% de vacaciones y el 5% de aporte a la seguridad

social).

El estipendio devengado al estudiante es de 100 para un total de 500

.

El consumo de energía estuvo dado por:

Se emplea una laptop marca SAMSUMG modelo NP300E4A que consume 60 .

Se asumen 8 de trabajo de lunes a viernes y una tarifa eléctrica de 0.09

.

Los gastos asociados a la transportación del diplomante para el desarrollo de la

investigación son:

De 35 que incluye la ida y el regreso desde su lugar de residencia.

Todo lo cual se resume en la Tabla 3.8.

Tabla 3.8 Gastos del desarrollo de la investigación.

El anterior gasto total debe ser el considerado en la posterior implementación del

Sistema Multi-Agente.

60

Conclusiones

Conclusiones

La función saveintodb permite almacenar de forma segura los datos

provenientes del proceso de identificación paramétrica de MATLAB en la base

de datos MATLAB_DATA.

El sistema gestor de base de datos MySQL 5.5 proporciona confiabilidad,

flexibilidad, y buen desempeño en el proceso de almacenamiento de datos.

La estructura definida para la base de datos permite el rápido almacenamiento y

la fácil utilización de los datos por otras aplicaciones para análisis posteriores.

Las variables consideradas para ser almacenadas, reflejan plenamente el

comportamiento de los sistemas de control que se identifiquen, debido a que

provienen de las gráficas que mejor representan e ilustran las respuestas de los

sistemas.

61

Recomendaciones

Recomendaciones

Reestructurar el esquema de la base de datos con el objetivo de incorporar la

identificación no paramétrica, modelos no lineales, los sistemas MIMO (Multiple

Input Multiple Output), así como las demás estructuras no admitidas en la

función. Incorporar al código de la función dichos cambios e implementar nuevos

algoritmos de inserción para la nueva estructura de la base de datos.

Si se utilizan versiones de MATLAB y MySQL distintas a las usadas en la

programación de la función, actualizar el código de la misma, si es necesario,

para eliminar problemas de compatibilidad entre estos softwares y la función.

62

Referencias bibliográficas


1. AGUADO BEHAR, A. 2000. Temas de Identificación y Control Adaptable, La

Habana, Instituto de Cibernética, Matemática y Física.

2. CARBALLO, C. R. 2011. Interfaz gráfica para la identificación para la plataforma

de 2 grados de libertad. PhD, Universidad Central “Marta Abreu”de Las Villas.

3. CORONEL, C., MORRIS, S. & ROB, P. 2012. Database systems: design,

implementation, and management, Course Technology Ptr.

4. DONKELAAR, E. T. 2000. Improvement of efficiency in identification and model

predictive control of industrial processes. A flexible linear parametrization

approach. Tesis de doctorado, Technische Universiteit Delft.

5. DUBOIS, P. 2002. MySQL Cookbook, O'Reilly.

6. GARCÍA, A. A., MARTÍNEZ, H. S., LABORI, L., MARTÍNEZ, M. P. &

HERNÁNDEZ, L. G. 2007. Determinación de diapasones de potencia necesarios

para el control de frecuencia en el sistema eléctrico cubano; Determination of

Necessary Ranges of Power for the Frecuency Control in Cuban Electric System.

Ingeniería Energética 28, no. 1 (2007): 38-a.

7. GEIGER, K. 1995. Inside ODBC, Chicago, Microsoft Press.

8. GILFILLAN, I. 2003. La Biblia de MySQL.

9. KLYSUBUN, P. & NETSAI, C. 2009. Development of MATLAB-based Data

Logging System at the Siam Photon Source. EPAC [Online], 6. Available:

http://accelconf.web.cern.ch/AccelConf/e06/PAPERS/THPCH127.PDF.

10. KRUPA, J., PROCHÁZKA, A., HANTA, V. & HÁVA, R. 2009. Technical

Computing Using Sybase Database for Biomedical Signal Analysis. Proceedings

of the Conference on Technical Computing [Online]. Available:

http://www.mobilnews.cz/honza/dnload/publications/SybaseMATLAB_Poster.pdf.

11. LJUNG, L. 1999. System Identification. Theory for the User, New Jersey,

Prentice Hall Ptr.

12. LJUNG, L. 2007. System Identification Toolbox 7. User’s Guide.

13. LÓPEZ, M. E. 2000. Identificación de Sistemas. Aplicación al modelado de un

motor de continua. Available:

http://www.depeca.uah.es/depeca/repositorio/asignaturas/32328/Tema6.pdf.

http://www.mobilnews.cz/honza/dnload/publications/SybaseMATLAB_Poster.pdf

http://www.depeca.uah.es/depeca/repositorio/asignaturas/32328/Tema6.pdf

63


14. MATHWORKS. 2013. Support. Documentation center [Online]. Available:

http://www.mathworks.fr/fr/help/index.html.

15. MATHWORKS, I. 1998. Database Toolbox. For Use with MATLAB.

16. MICROSOFT. 2012. Ayuda y soporte técnico [Online]. Available:

www.microsoft.com/spain/support/.

17. MIKLES, J. & FIKAR, M. 2007. Process Modelling. Identification and Control,

Springer.

18. ORACLE, C. 2012. MySQL 5.5 Reference Manual: Including MySQL Cluster

NDB 7.2 Reference Guide.

19. PINTELON, R. & SCHOUKENS, J. 2001. System Identification. A Frequency

Domain Approach., New York, IEEE Press.

20. PORTUONDO PICHARDO, F. M. 1985. Economía de Empresas Industriales, La

Habana, Editorial Félix Varela.

21. SADOSKI, D. 1997. Client/Server Software Arquitecture. An overview, Software

Technology Roadmap.

22. SCHWARTZ, B., ZAITSEV, P., TKANCHENKO, V., ZAWODNY, J., LENTZ, A. &

DEREK, B. 2012. High Performance MySQL: Optimization, Backups, and

Replication, O'Reilly Media.

23. STOJANOVIC, I. & BOGDANOV, M. 2006. Pixel-Based Searching of Images

Stored in a Database. International Scientific Conference on Information,

Communication and Energy Systems and Technology [Online]. Available:

http://eprints.ugd.edu.mk/872/1/Conf5_ICEST2006_IgorStojanovic.pdf.

24. VALDIVIA, A. A. 2012. Interfaz para la identificación y ajuste de los controladores

de un simulador de conducción. Tesis de grado, Universidad Central “Marta

Abreu” de Las Villas.

25. WHITE, S. 1999. JDBC API tutorial and reference: Universal data access for the

Java 2 platform, Chicago, Addison-Wesley Longman Publishing Co., Inc.

http://www.mathworks.fr/fr/help/index.html

http://www.microsoft.com/spain/support/

http://eprints.ugd.edu.mk/872/1/Conf5_ICEST2006_IgorStojanovic.pdf

I

Anexos

Anexo 1 : Segmento completo de la tabla step_response correspondiente al

modelo arx541.

II

Anexos

Anexo 2 : Segmento completo de la tabla frequency_response

correspondiente al modelo arx541.

III

Anexos

Anexo 3 : Segmento completo de la tabla correlational_residual_analysis

correspondiente al modelo arx541.

IV

Anexos

Anexo 4 : Segmento completo de la tabla

cross_correlational_residual_analysis correspondiente al modelo arx541.

V

Anexos

Anexo 5 : Segmento completo de la tabla noise_spectrum correspondiente al

modelo arx541.

VI

Anexos

Anexo 6 : Segmento completo de la tabla vector correspondiente al modelo

arx541.

VII

Anexos

Anexo 7 : Configuración de fuentes de datos para su uso con controladores

ODBC

En este anexo se describe cómo configurar un origen de datos cuya base de datos

se encuentra en un PC con el sistema operativo Windows, o en otro sistema al que

está conectado en red del PC, para su uso con un controlador ODBC. Estas

instrucciones utilizan el ODBC MySQL Connector/ODBC 5.1. Si tiene una

configuración diferente, es posible que tenga que modificar estas instrucciones.

1. Cerrar bases de datos abiertas en el programa de base de datos.

2. Abra el cuadro de diálogo Windows Data Source para definir el origen de datos

ODBC:

a. Inicie el constructor de consultas visual (Visual Query Builder)

introduciendo el comando querybuilder en el prompt de MATLAB.

b. En Visual Query Builder, seleccione Query > Define ODBC Data Source.

3. Aparecerá el cuadro de diálogo Administrador de orígenes de datos ODBC

(ODBC Data Source Administrator), enumerando las fuentes de datos

existentes.

VIII

Anexos

4. Haga clic en la ficha User DSN.

5. Seleccione MS Access Database y haga clic en Add.

6. Una lista de los controladores ODBC instalados aparece en el cuadro de

diálogo ODBC Data Source Administrator. Seleccione MS Access Driver y

haga clic en Finish.

IX

Anexos

7. Aparecerá el cuadro de diálogo ODBC Microsoft Access Setup. Este cuadro de

diálogo para su controlador puede ser diferente del siguiente.

8. Rellene los campos de Source Name y Description.

9. Seleccione la base de datos para esta fuente de datos a utilizar. Para algunos

controladores, puede saltarse este paso.

a. En el cuadro de diálogo ODBC Microsoft Access Setup, haga clic en

Select.

Aparecerá el cuadro de diálogo Select Database.

X

Anexos

b. Especifique la base de datos que desea utilizar.

c. Si su base de datos en un sistema al que está conectado su PC:

I. Haga clic en Network. Aparecerá el cuadro de diálogo Map

Network Drive.

II. Especifique la carpeta que contiene la base de datos que desea

utilizar.

III. Haga clic en Finish.

d. Haga clic en Ok para cerrar el cuadro de diálogo Select Database.

10. En el cuadro de diálogo ODBC Microsoft Access Setup, haga clic en Ok.

XI

Anexos

Anexo 8 : Configuración de fuentes de datos para su uso con los

controladores JDBC.

Para configurar orígenes de datos para su uso con los controladores JDBC:

1. Busque el nombre del archivo que contiene los controladores JDBC.

2. Especifique la ubicación del archivo de controladores en the MATLAB Sun Java

classpath añadiendo la ruta de este archivo al archivo:

matlabroot/toolbox/local/classpath.txt.

Por ejemplo, use la siguiente sintaxis para agregar una referencia a un archivo de

controladores MySQL® JDBC archivo: D:/mysql/mysql-connector-java-3.0-

bin.jar, a classpath.txt:

D:/mysql/mysql-connector-java-3.0-bin.jar

Reinicie la sesión del software MATLAB antes de acceder a la base de datos.

Si el archivo de controladores no se encuentra en classpath.txt indica, que no aparecen

errores, pero MATLAB no establece la conexión con la base de datos.

3. Haga lo siguiente para configurar los drivers JDBC para usar con Visual Query

Builder:

a. Inicie el constructor de consultas visual (Visual Query Builder) introduciendo el

comando querybuilder en el prompt de MATLAB.

b. En Visual Query Builder, seleccione Query > Define JDBC Data Source.

El cuadro de diálogo Define JDBC Data Sources aparece.

XII

Anexos

En la siguiente tabla se describen los campos que se utilizan para definir el origen de datos JDBC.

c. En el cuadro de diálogo Define JDBC data sources, haga clic en Create New File.

d. Aparece el nuevo cuadro de diálogo Specify new JDBC data source MAT-file. Utilice

este cuadro de diálogo para crear un MATLAB MAT-file que guarda la información de

origen de datos especificado para las futuras sesiones de Visual Query Builder.

Navegue a la carpeta donde desea colocar el archivo MAT, especifique un nombre para

él, que incluye una extensión .mat, y haga clic Save.

e. En el cuadro de diálogo Define JDBC Data Sources, ingrese la información de la fuente

de datos JDBC en los campos: nombre, controlador y URL, como se describe en la

tabla del paso 3b.

f. Pruebe la conexión haciendo clic en Test.

XIII

Anexos

Si su base de datos requiere un nombre de usuario y contraseña, aparecerá un cuadro

de diálogo que le pide que proporcione ellos. Introduzca los valores en estos campos y

haga clic en Ok.

Aparecerá un cuadro de diálogo de confirmación indica que la conexión de base de

datos se ha realizado correctamente.

g. En el cuadro de diálogo Define JDBC Data Sources, haga clic en Agregar / actualizar.

El origen de datos aparece ahora en la lista Origen de datos.

h. Para agregar más fuentes de datos, repita los pasos del c al g para cada nueva

fuente de datos. Usted puede agregar más fuentes de datos en el futuro mediante la

edición del archivo-MAT que contiene la información del origen de datos.

Nota: Puede crear otro MAT-file para añadir nuevas fuentes de datos, pero Visual

Query Builder sólo puede acceder a fuentes de datos de un MAT-archivo a la vez.

Incluye múltiples fuentes de datos en un único archivo MAT-para facilitar el acceso.

i. Haga clic en Aceptar para cerrar el cuadro de diálogo Definir datos JDBC fuentes.

La fuente de datos recién agregado aparece ahora en la lista Origen de datos VQB.

La fuente de datos JDBC definido sólo es válida para la sesión actual del software

MATLAB.

título: función para la obtención de datos de

Documents