Future Work

Para dar soporte al controlador de domótica ErosXD fue necesario realizar un estudio sobre su estructura interna y la relación entre cada uno de los componentes del sistema. A partir del código fuente y el mecanismo de compilación se identificaron las dependencias de software del controlador de domótica. Las dependencias identificadas que aún no tienen soporte en el framework de desarrollo fueron las APIs Qt 4.8.4, Boost 1.59.0 y WebToolkit 3.3.5.

Una vez identificadas las dependencias se propuso el diseño del sistema general, como se muestra en la Figura 5.3, donde se toma como base XEOS y se le incorporan los componentes relacionados al controlador de domótica.

Para dar soporte a las dependencias de software y al controlador de domótica fue necesario el estudio de la guía de soporte «Genode Porting Guide»1 _que

provee el framework. En las secciones siguientes se describe el soporte dado a las dependencias y al controlador de domótica ErosXD.

1_{La guía se puede acceder en: <direcotrio-genodeos>/doc/porting-guide.txt}

Capítulo 5. Caso de estudio: Controlador de domótica ErosXD

Figura 5.3.:Estructura del sistema XEOS-ErosXD

5.3.1.

Dependencias de

software

La primera dependencia a la que se dio soporte fue al API de Qt, ya que fue el API empleado para el desarrollo de controlador de domótica en su totalidad. El framework de desarrollo GenodeOS tuvo soporte para Qt 4.8.4 hasta la versión 14.08, a partir de la cual se descontinuó su soporte y fue removido de la distribución del framework.

Para satisfacer esta dependencia fue necesario reincorporar el soporte de Qt 4.8.4 a la versión 15.11 del framework. Durante este proceso fue necesario reajustar la integración de Qt con GenodeOS, fundamentalmente en el trabajo directo con los hilos de ejecución del sistema, así como la integración con los componentes gráfico Nitpicker y Framebuffer de GenodeOS para el manejo de las interfaces visuales. También fue necesario adaptar los componentes de Qt al nuevo API del framework y al mecanismo de compilación.

Aunque el controlador de domótica no emplea interfaces visuales, hace uso de algunas funcionalidades que brinda el componente gráfico de Qt. A continuación se muestran los componentes de Qt a los cuales se le dio soporte en elframework de desarrollo:

Qt Core, Qt GUI, Qt Widgets, Qt QPA Integration, Qt Network, Qt Websockets, Qt SQL, Qt XML

Capítulo 5. Caso de estudio: Controlador de domótica ErosXD estas bibliotecas en una computadora de escritorio con el fin de identificar sus dependencias de otras bibliotecas. Se identificó que el API WebToolkit tiene como dependencia al propio Boost, por lo que fue necesario dar soporte en un primer momento a Boost. También se identificaron un conjunto de dependencias comunes: librt.so.1,libstdc++.so.6, libm.so.6, libgcc_s.so.1,

libpthread.so.0 y libc.so.6.

La bibliotecalibrtes una extensión para tiempo real en los sistemas GNU/Linux. En el caso de XEOS, esta dependencia en GenodeOS debe omitirse. La biblioteca

libstdc++ hace referencia al estándar de C++, el cual está implementado en GenodeOS por la biblioteca stdcxx.

El estándar de C libgcc_s y libc están implementadas en GenodeOS por la propia biblioteca libc. Las bibliotecas libm y libpthread, para el trabajo con funciones matemáticas y el trabajo con hilos de concurrencia, están implementadas en GenodeOS por libm y pthread, respectivamente. En este último caso la biblioteca pthreadno es de uso obligatorio si no se va a compilar los componentes de Boost con soporte multithreading.

El API Boost está dividido en componentes o bibliotecas internas, por lo que no fue necesario la incorporación de todo el API. Solo se incorporaron las bibliotecas de las cuales depende WebToolkit y el controlador de domótica. A continuación se listan las bibliotecas de Boost a las que se le dio soporte en GenodeOS:

Date Time, Exception, Filesystem, Program Options, Random, Regex, Signals, System, Thread

Una vez incorporadas las dependencias al API de Boost se procedió al soporte del WebToolkit. Para identificar los archivos de código fuente compilados para el API, en función de la configuración empleada, fue necesario realizar una revisión del archivo build.log generado durante el proceso de compilación.

Durante el proceso de incorporar WebToolkit al framework de desarrollo se identificó que el API está desarrollado en C++ y nombra sus archivos de código fuente con extensión .c. Esto debe tenerse en cuenta ya que el mecanismo de compilación del framework identifica los archivos de extensión .c como archivos de código fuente de C y los compila con un compilador de C y no C++, lo cual produce errores en el proceso de compilación.

Para validar el soporte de las dependencias de software durante el proceso de desarrollo se emplearon dos mecanismos de prueba. El primer mecanismo de prueba es empleado para verificar la compilación de las bibliotecas y la integración

Capítulo 5. Caso de estudio: Controlador de domótica ErosXD con sus dependencias. Para cada una de las bibliotecas incorporadas se creó una aplicación dummy con solo dependencia de compilación a esa biblioteca. Al compilar esta aplicación se compila la biblioteca y se verifica que ésta enlace correctamente sin quedar referencias indefinidas.

El segundo mecanismo de prueba empleado fue dar soporte a los ejemplos de prueba que proveen cada una de las API soportadas. En el caso de Qt y Boost se emplearon ejemplos por cada uno de los componentes soportados en elframework y ejemplos que integraban varios de estos componentes.

5.3.2.

Controlador de domótica

Con todas las dependencias de software incorporadas alframework de desarrollo se procedió a incorporar el controlador de domótica al propio framework. El controlador de domótica fue descompuesto según los componentes mostrados en la Figura 5.1. Cada uno de estos componentes fue compilado de forma independiente como bibliotecas dinámicas. En la Tabla 5.1 se relacionan cada uno de los componentes y la respectiva biblioteca generada.

Tabla 5.1.: Relación entre los componentes de ErosXD y las bibliotecas agregadas al

framework Componente Biblioteca Common eros_xd4_common.lib.so Scheduler eros_xd4_scheduler.lib.so Collector eros_xd4_collector.lib.so Amqp eros_xd4_amqp.lib.so WebService/Rest/AtCoreRest eros_xd4_srv_core_rest.lib.so WebService/Rest/AtSensorRest eros_xd4_srv_sensor_rest.lib.so Drivers/OPC eros_xd4_drv_opc.lib.so Drivers/Modbus eros_xd4_drv_modbus.lib.so Drivers/Vaisala eros_xd4_drv_vaisala.lib.so Drivers/N1 eros_xd4_drv_n1.lib.so Drivers/ICR eros_xd4_drv_icr.lib.so

Para probar la compilación e integración de cada uno de los componentes de ErosXD durante el proceso de soporte en XEOS se empleó el mecanismo de aplicaciones dummies descrito en la sección anterior. Una vez incorporados todos los componentes de ErosXD, se incorporó la aplicación del controlador de domótica. Para generar el escenario de prueba del controlador se generó unscript de ejecución que compila los componentes necesarios. Para preparar el escenario

Capítulo 5. Caso de estudio: Controlador de domótica ErosXD de prueba de ErosXD se ejecuta la siguiente línea de comando desde el directorio de compilación:

make run/eros_xd

Una vez finalizado el soporte del controlador de domótica ErosXD en XEOS se hizo un estudio para determinar cómo se comportaba elfootprint del sistema una vez cargado éste en memoria. Para ello se calculó el footprint por componentes del sistema a partir de los archivos objetos generados durante la compilación. La Figura 5.4 muestra los resultados obtenidos para cada uno de los componentes.

Figura 5.4.: Memory footprint de ErosXD de un total de 33029803 bytes

Como se puede observar, el microkernel Fiasco.OC, componente crítico para la seguridad y estabilidad del sistema, solo ocupa el 2 % de este footprint, ocupando la mayor parte de éste el API de Qt y WebToolkit con 38 % y 31 %, respectivamente. El componente «Otros componentes» incluye los controladores de dispositivos, el API estándar de C/C++, el API LWIP, entre otros.

5.4.

Pruebas del controlador de domótica en