ARQUITECTURA PARA LA INTEROPERABILIDAD DE UNIDADES DE SIMULACION´ BASADAS EN FMU Proyecto Fin de Carrera Ingenier´ıaInform´atica 16/02/2015 Autora: Tutores: S´anchez Medrano, Mar´ıadel Carmen Hern´andezCabrera, Jos´eJuan Evora´ G´omez,Jos´e Hern´andezTejera, Francisco M. Escuela de Ingenier´ıaInform´atica.Universidad de Las Palmas de G.C. Proyecto fin de carrera Proyecto fin de carrera de la Escuela de Ingenier´ıaInform´atica de la Universidad de Las Palmas de Gran Canaria presentado por la alumna: Apellidos y nombre de la alumna: S´anchez Medrano, Mar´ıadel Carmen T´ıtulo: Arquitectura para la interoperabilidad de unidades de simulaci´onbasadas en FMU Fecha: Febrero de 2015 Tutores: Hern´andezCabrera, Jos´eJuan Evora´ G´omez,Jos´e Hern´andezTejera, Francisco M. Escuela de Ingenier´ıaInform´atica.Universidad de Las Palmas de G.C. Dedicatoria A MI MADRE Y A MI PADRE Escuela de Ingenier´ıaInform´atica.Universidad de Las Palmas de G.C. Agradecimientos A mis tutores. A Jos´eJuan Hern´andezCabrera por su direcci´ony orientaci´onen este proyecto. Por ser un excelente mentor que ha permitido iniciarme en la l´ıneade investi- gadora y en el aprendizaje de otras filosof´ıasde programaci´on.A Jos´e Evora´ G´omezpor sus explicaciones y ayuda incondicional durante todo el desarrollo. A Francisco Mario Hern´andezpor darme la oportunidad de integrarme en este excelente equipo. A todo el grupo de profesores que me han instruido durante todos estos a~nosper- miti´endomeconseguir el objetivo deseado: ser ingeniera inform´atica. A todos mis compa~neros y amigos de carrera, en especial a Alberto y Dani. Con ellos he compartido estos ´ultimosa~nos de carrera llenos de vivencias y an´ecdotas.Gracias a todos por estar ah´ıya que sin ustedes este camino no hubiera podido ser tan f´acil y divertido. He conocido a grandes amigos en estos a~noscon los que espero seguir haciendo proyectos juntos y poderlos ayudar cuando lo necesiten. A Edu por aguantarme en la carrera, en los momentos buenos y malos, teniendo en ´elun apoyo incondicional en todo momento. Y en especial a mi familia, sobretodo a mis padres. Ellos han sido un gran apoyo, no s´oloa nivel econ´omico.Han sido el verdadero sost´enmoral y an´ımicodel cual yo he salido fortalecida siempre, en cualquiera de las condiciones que me encontrase, viendo en ellos la mayor de las ayudas. Siempre han estado ah´ıcuando los he necesitado alegr´andose cuando he conseguido mis metas y apoy´andomea conseguirlas. S´eque para ellos es un orgullo que haya llegado hasta aqu´ısobretodo por todo el esfuerzo que hay detr´as. Nunca podr´eagradec´erselolo suficiente. Un recuerdo muy, muy, muy especial a mi madre que esperaba este momento con ilusi´ony que desgraciadamente no ha podido ver. Me gustar´ıafinalizar este documento dici´endolesa todos ustedes de todo coraz´on <Muchas gracias! Escuela de Ingenier´ıaInform´atica.Universidad de Las Palmas de G.C. ´Indice general Lista de figuras IX 1. Motivaci´ony objetivos iniciales 1 2. Antecedentes y contextualizaci´on 5 2.1. Functional Mock-up Interface . .5 2.2. Estado del arte . .7 2.2.1. JFMI . .7 2.2.2. Herramientas para la ejecuci´ondistribuida de FMUs . .7 3. Resultados 13 3.1. Arquitectura . 14 3.1.1. El Remote Builder . 15 3.1.2. El Container . 16 3.1.3. Publication Protocol . 17 3.1.4. Mirror o FMU espejo . 18 3.1.5. Skeleton . 18 V ´INDICE GENERAL 3.1.6. Execution Protocol . 19 3.2. JavaFMI . 20 3.3. Manual de Usuario . 20 3.3.1. Lanzamiento del servidor . 21 3.3.2. Generar la FMU espejo . 21 3.3.3. Utilizaci´onde las FMUs . 22 3.4. Dise~noModular . 24 3.4.1. Fmu Remote Builder . 25 3.4.2. Repositorio de las librer´ıasdin´amicas . 26 3.4.3. Container . 28 3.4.4. Skeleton . 29 4. Proceso de desarrollo 33 4.1. Metodolog´ıade desarrollo . 33 4.2. Primera etapa: Familiarizaci´oncon herramientas y metodolog´ıasde desa- rrollo . 33 4.3. Segunda etapa: Creaci´onde las librer´ıasdin´amicas. 35 4.3.1. Elecci´onlibrer´ıaspara manejo sockets . 35 4.3.2. Programaci´onorientada a objetos en C . 36 4.3.3. Definici´ondel protocolo de comunicaci´on. 38 4.4. Tercera Etapa. Creaci´ondel Remote Builder . 39 4.4.1. Empaquetado de la FMU . 40 VI ´INDICE GENERAL 4.4.2. Obtenci´ondel puerto y env´ıode la FMU . 40 4.4.3. Modificaci´onde ficheros binarios . 41 4.5. Cuarta etapa. Migraci´ona la versi´ondel est´andarFMI v2 RC1 . 42 4.6. Quinta Etapa. Creaci´ondel Skeleton y Container . 43 4.6.1. Creaci´ondel Skeleton . 43 4.6.2. Creaci´ondel Container . 43 4.7. Temporizaci´on. 44 5. Herramientas Utilizadas 47 5.1. Recursos Hardware . 47 5.2. Recursos Software . 48 6. Conclusiones y trabajo futuro 51 6.1. Conclusiones . 51 6.2. Trabajo Futuro . 53 A. Functional Mock-up Interface 55 B. Git flow 59 C. Principios de la orientaci´ona objetos 61 D. Licencia LGPL 63 Bibliograf´ıa 69 VII ´INDICE GENERAL VIII ´Indice de figuras 3.1. Estructura del Remotifier . 15 3.2. Publication Protocol . 17 3.3. Protocolo Comunicaci´onentre la FMU espejo y la FMU en remoto . 19 3.4. Dise~noModular del Remotifier . 24 3.5. Diagrama de Clases del Fmu Remote Builder . 26 3.6. Diagrama de Clases del Container . 28 3.7. Diagrama de Clases del Skeleton . 30 4.1. Comparativa ejecuci´onLibCurl frente a las librerias de sistema . 36 4.2. Porcentajes temporizaci´on . 45 A.1. Estructura interna de una FMU . 58 B.1. Modelo de ramas Git Flow . 60 IX Facultad de Inform´atica.Universidad de Las Palmas de G.C. Cap´ıtulo1 Motivaci´ony objetivos iniciales En diversos sectores de la industria, como puede ser la el´ectricao la automovil´ıstica, la simulaci´ones una parte fundamental del dise~noy fabricaci´onde los productos. Con ello, se intenta disminuir costes y asegurar que los productos sean lo m´asfiables posible. Para dar soporte a estas necesidades, en el mercado existen diversas herramientas de simulaci´on,cada una especializada en un determinado tipo de problema y con una orientaci´onconcreta al modelado del sistema: Anylogic, MatLab, Dymola... Puede suceder, por ejemplo en la industria automovil´ıstica,que un ingeniero reali- zando la simulaci´onde un motor, necesite utilizar la simulaci´onde una buj´ıaque ha sido realizada con otra herramienta. A´unm´as,el ingeniero que est´arealizando la simu- laci´ondel motor no tiene por qu´etener instalada la herramienta con la que se realiz´o la simulaci´onde dicha buj´ıa. Por tanto existe la necesidad tanto de poder integrar simulaciones realizadas con herramientas distintas, como de distribuir una simulaci´onen un formato ejecutable, es decir, que no requiera tener instalada la herramienta con la que se desarroll´o. En 2010, la fundaci´onModelisar present´oel est´andarFunctional Mock-up Interface (FMI) como una soluci´ona estas necesidades de interoperabilidad entre herramientas de simulaci´on.En FMI, se define una interfaz com´un(API) que permite la distribuci´on e interoperabilidad de simulaciones. As´ı, una simulaci´onpuede transformarse en un formato ejecutable para su distribuci´oncon una interfaz p´ublicaconocida. En este 1 CAP´ITULO 1. MOTIVACION´ Y OBJETIVOS INICIALES est´andar,una simulaci´onse empaqueta en un formato de fichero llamado Functional Mock-up Unit (FMU). Una simulaci´onen formato FMU se define como un fichero comprimido en formato zip. Este fichero, adem´asde incluir una descripci´onde la propia simulaci´on,incluye unas librer´ıasdin´amicasque permiten la ejecuci´onde la simulaci´on en m´ultiplessistemas operativos. Para ello, se incluyen los binarios compilados de unas librer´ıaspara: win32, win64, linux32, linux64 y Mac OS. No obstante, existen otro tipo de necesidades relacionadas con la interoperabilidad de simulaciones. En el caso de que se deseara simular el uso de la electricidad en las viviendas de una ciudad como Las Palmas de Gran Canaria, unas 200.000 aproxima- damente, habr´ıaque resolver la interoperabilidad en una ejecuci´ondistribuida. En este caso, dado que es una simulaci´onmuy grande, podr´ıaempaquetarse la simulaci´onde un edificio o un barrio en una FMU con el objetivo de repartirlas en una red de ordenadores. En general, cuando una simulaci´onrequiere muchos componentes que tienen que ser simulados, podemos encontrarnos con un problema de falta de recursos en el ordenador: por ejemplo insuficiente memoria RAM. Para resolver este problema, se plantea la posibilidad de realizar una ejecuci´ondistribuida de los componentes. Este problema, que se presenta habitualmente en simulaciones muy grandes, ha sido identificado por el Instituto Universitario SIANI de la Universidad de Las Palmas de Gran Canaria. Adem´asotros institutos de investigaci´oneuropeos y empresas, con los que tiene relaci´onel SIANI, tambi´endemandan soluciones de escalabilidad en simula- ciones. En este proyecto concretamente se aborda la interoperabilidad distribuida de simulaciones bajo el est´andarFMI. Objetivos iniciales El objetivo de este proyecto es el dar a los usuarios del est´andar FMI la posibilidad de poder ejecutar las unidades de simulaci´on(FMUs) de forma distribuida. Para conseguir el objetivo principal del proyecto se han desglosado los siguientes subobjetivos: Estudiar el est´andarFMI. Definici´onde una arquitectura. La definici´onde la arquitectura es una parte fundamental en el desarrollo de software ya que define a grandes rasgos los m´odu- los que van a formar parte en el proceso. A lo largo de las diversas iteraciones del 2 CAP´ITULO 1. MOTIVACION´ Y OBJETIVOS INICIALES desarrollo esta arquitectura ha sufrido cambios significativos guiando el desarrollo y redefiniendo los subobjetivos del mismo.